My Oracle Support Banner

Release of Oracle Communications Billing and Revenue Management 7.4 Patch Set 21 (Doc ID 1684623.1)

Last updated on NOVEMBER 14, 2019

Applies to:

Oracle Communications Billing and Revenue Management - Version to [Release 7.4.0]
Information in this document applies to any platform.


Oracle Communications Billing and Revenue Management 7.4 Patch Set 21 is released on 30 June 2014.

This announcement lists the fixes and enhancements in various components delivered in Oracle Communications Billing and Revenue Management (BRM) 7.4 Patch Set 21.

NOTE: BRM Maintenance Patch Set 1 is a pre-requisite for this patch, for server components including optional managers and also for client applications.

NOTE: BRM 7.4 Patch Set 21 is cumulative from BRM 7.4 Patch Set 12 and includes all the changes introduced from Patch Set 12 onwards.

Patch ID: <Patch 18716360>

Summary of fixes to customer-reported tickets delivered in Patch Set 21:

SR Number

Bug Number


Not applicable


When a discount was purchased or cancelled, events pertaining to non-relevant discounts (discounts that do not act together with the discount being purchased or cancelled) with a net 0 balance impact were generated during sequential discounting. These extra events were getting displayed in the invoice, which was not desirable.

This has been fixed. A new drop_extra_seq_disc_events invoicing business parameter is introduced to indicate whether to drop these unwanted events from the invoice or not. The business parameter takes the following values:

n        1 to drop the non-relevant sequential discounting events.

n        0 to not drop the non-relevant sequential discounting events. This is the default.



In Pricing Center, the transition tab for a deal was not displaying all the possible transitions because the transitions for the Deals were not retrieved properly from the database.

This has been fixed.

Not applicable


In the previous releases, the billing time taxation was not considering rerated events, which led to less tax being computed.

This has been fixed.



In the previous releases, the Collections Center GUI was not displaying the Bill Unit ID correctly for the accounts that had been manually exempted from Collections. The GUI always displayed the Bill Unit ID of the last listed account.

This has been fixed.



If Vertex was used as the tax engine and a product was purchased while Vertex Data Manager (dm_vertex) is down, the transaction succeeded but no tax was applied, which led to revenue loss.

This has been fixed. If Vertex DM is down, the transaction will now be aborted.



The quality-of-service (QoS) statistics is collected at the end of the Connection Manager (CM) connection session for all the opcodes configured in the CM’s pin.conf file and written to the CM log. This reporting is not useful.

With this release, the QoS statistics is collected for only the opcodes that are configured for QoS measurement in the CM's pin.conf file and are actually called in the current CM connection.



In the previous releases, if a Monthly Cycle Arrear product was cancelled after DOM and before billing had run for this account, the non-currency resource sub-balance valid_to date was set to the date of cancellation of this product through the configured discount, even though this was not the product that granted the resource.

This has been fixed.



In the previous releases, if a payment is suspended and the unallocated payment was removed from Payment Suspense Center, the next time a search was issued, the removed payment was not displayed.

This has been fixed. The unallocated payment is now displayed with a specific icon.



In the previous releases, the BRM general ledger reports consider revenue to be billed based on the end time of the corresponding bill period. For example, if the bill period is Jan 1 - Feb 1, but the actual bill run is on Feb 3, the revenue is considered billed on Feb 1.

With this release, you can now set the new UseActualBilledTimeForGLReport billing business parameter to consider the revenue billed to be on the actual bill run date.



In the previous releases, the customer service representatives (CSRs) accounts created using Permissioning Center were also considered for billing because of which unwanted data was generated.

This has been fixed. For the /billinfo objects of the CSR accounts created using Permissioning Center, the PIN_FLD_BILLING_STATUS is set to 1, making it a suspended account and as a result this is excluded from billing.



In the previous releases, for an account with write off items, reprocessing the suspended payments was not possible.

This has been fixed.



In the previous releases, when rerating was run for a second service after running rerating for a service, the adjustment event related to the first service was getting reapplied.

This has been fixed. The search query now picks up events relevant only to the second service.



In the previous releases, if a database connection attempt failed, the failure status was logged in the ERROR log level. However, the success status during a database reconnection attempt was logged in the DEBUG log level.

This has been fixed. The success and failure statuses are now logged in the same ERROR log level.



In the previous releases, running pin_rerate -g was throwing an error.

This has been fixed.



In the previous releases, during trial billing, the tax entries were being logged to the Vertex database, which was not desired.

This has been fixed. In case of trial billing, the CALC_ONLY flag is passed to the Data Manager (DM) to skip recording the tax entries.



In the previous releases, when the script was run with the -set option to grant administrative privileges to Pipeline Manager users, the script was failing.

This has been fixed.



In the previous releases, any attempt to transfer negative bill balance via Customer Center was resulting in an error.

This has been fixed. BRM now includes the required checks while transferring negative bill balance.



In the previous releases, if an account was in an inactive status and a deal/product configured for monthly cycle_forward_arrear charging was purchased for the account and sometime later the account is reactivated, the charges for the inactive period were applied for newly purchased deal.

This has been fixed. In case of an account reactivation, when the change_start_time_on_activation parameter is set to 0, the cycle_beg will now be updated as the time of reactivation .



In the previous releases, invoking a custom opcode through BRM Web Service was failing. This was because the :customeFields package was not accessible due to invalid path to the file.

This has been fixed.



In the previous releases, migration process was reporting errors after migrating 79,000 accounts due to a memory leak.

This has been fixed.



In the previous releases, if there were old cycle forward arrear events with no balance impacts (primarily for mid cycle discount purchase), the cancellation of deal was failing.

This has been fixed. The old cycle forward arrear events with no balance impacts will be ignored during deal cancellation.



In the previous releases, the pin_bill_accts utility process was resulting in core dump.

This has been fixed. Changes were made in the code to reset the cookie and to operate on a copy of the flist to avoid memory corruption during billing.



When a bill level adjustment is applied, BRM distributes and applies the bill level adjustment amount to the individual charge items under a given bill. In certain scenarios, while rounding the individual charges, the tax amount was over calculated and was left unallocated.

This has been fixed. When there is a difference between the rounded tax amounts and the calculated adjustment tax amount, a new tax_event with the difference amount is created.



In the previous releases, for a resource whose validity is set based on first usage, an attempt to update the validity of the Balance Group was resulting in an exception.

This has been fixed.



In the previous releases, cancelling a purchase product was failing if the underlying service was inactivated and reactivated. This was because, after service inactivation and reactivation, the cycle start date of the product was updated to the service reactivate date.

This has been fixed.



In the previous releases, the memory allocated in a function was not destroyed resulting in a memory leak.

This has been fixed.



In the previous releases, core dump was encountered while fetching item level products using the PCM_OP_SUBSCRIPTION_READ_ACCT_PRODUCTS opcode.

This has been fixed.



In the previous releases, if there are more than one deferred purchase product with a different cycle_start_t per /billinfo object, the cycle forward charges was getting created with an incorrect end_t.

This has been fixed.



In the previous releases, if the rate plan of a product is changed from rate plan selector to a single rate plan, when you try to perform a backdated cancellation of the product, BRM rating was throwing an error. This was because the details of the rate plan change was captured in the audit table which was not being checked.

This has been fixed.



In Customer Center, if a bill having an accounts receivable items with $0 amount was queried, an error was displayed instead of showing the bill details.

This has been fixed. The unnecessary checks are now removed.



In the previous releases, if the parent billing was suppressed, the effective_t of the child items were set during the next billing cycle of the child.

This has been fixed. The effective_t of the child will now be set only after parent comes out of suppression and the bill gets finalized.



In the previous releases, during billing, products with deferred purchase start were being considered for the wrong period.

This has been fixed. The condition to pick up products with deferred purchase start during billing has been modified to consider only END_T.



In the previous releases, even after the configured idle time limit, the JCA connections that were above the "Minimum JCA connection limit" and idle were not getting removed.

With this patch, after the configured idle time limit, the idle connections are removed.



When a tailormade product was cancelled, the scale calculation was not correct, which resulted in an incorrect refund.

This has been fixed.



In the previous releases, when a product was reactivated after its cycle end date, the cycle start date of the product was being set to the current date. This resulted in the cycle start date to be set after the cycle end date leading to a negative scale calculation and incorrect rates.

This has been fixed. If the reactivation date is after cycle end date of the product, instead of setting the cycle start date to the current date, it is now set to cycle end date, so that the scale calculation will not be negative.



In the previous releases, Customer Center was not displaying Resources, Amount, Allocated, and Unallocated for failed payments (soft decline). This was because the database query was not picking up events with resource ID.

This has been fixed.



Patch Set 21) In the previous releases, an account level Extended Rating Attribute (ERA) was created, followed by the creation of a profile sharing group at the account level, and addition of a member. When the member account was billed, it resulted in errors. This was because OP_RATE_GET_ERAS assumes that the sharing profile is of type /profile/serv_extrating.

This is now fixed. The account profile is now retrieved differently from service profile.



In the previous releases, CM went into an infinite loop when an error was returned from the PCM_OP_CUST_POL_PREP_BILLINFO opcode.

This has been fixed.



In the previous releases, a resource configured for initialization with first usage was not getting initialized when authorization was triggered for a usage event.

This has been fixed.



In the previous releases, the Cycle Arrear Product charges were getting refunded during backdated cancellation though prorate on purchase and cancel is set to charge for the full month.

This has been fixed.



In the previous releases, transactions were failing when subscriptions were added to the subscription group where ordered balance group was created or updated.

This has been fixed.



In the previous releases, if billing DOM of an account was changed after the account creation and the backdated purchase of a deal was done, an error was reported.

This has been fixed.



In the previous releases, when creating or modifying an account, if there is no service object present, instead of impacting the existing item from the item POID list of the account object, a new item is created for the events. This leads to creation of an additional item.

This has been fixed.



After each successful login into BRM from a client application, the MOD_T date field in the /service/admin_client object or the /service/pcm_client object was updated. This update of the date value was not necessary and was impacting the performance.

This has been fixed. After a successful login, the number of login attempts is reset to 0 only if the previous value is more than 0.



In the previous releases, when the PCM_OP_PRICE_COMMIT_TRANSITION opcode was called directly, it was not recognized as a valid opcode.

This has been fixed.



In the previous releases, the rollover feature was not working correctly on February for customers with billing  day of month (DOM) on February 29, February 30, and February 31. This was because the next accounting cycle was not being correctly calculated when the billing DOM is greater than February 28.

This has been fixed.



In the previous releases, purchasing an annual product on 29, 30 or 31st day of month created events with incorrect amounts. This was caused by wrong proration calculations.

This has been fixed.

Key Enhancements in BRM 7.4 Patch Set 21

For more details about these changes and enhancements, please refer to BRM Patch Set 21 documentation.

Certification Enhancements

With this patch, BRM is now certified with PERL 5.18.2 and RDA 8.03 (Linux and Solaris)


Known Issues:

In BRM 7.4 Patch Set 21: An attempt to display Unresolved Disputes via Customer Center is resulting in Core Dump. This has been taken care in Patch Set 22.


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.