Incorrect Behavior Of UNIQUE_ACCT_NO_T With Respect To UNIQUENESS_T (Doc ID 2038243.1)

Last updated on AUGUST 25, 2015

Applies to:

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

Symptoms

On 7.5.0.8.0, Account Migration Manager

In a multi schema environment, the movement of accounts is resulting in incorrect values in UNIQUE_ACCT_NO_T table. This is not in sync with the behavior of values wrt to UNIQUENESS_T table. Consider the below scenario,

Moved one account ACCOUNT_NO '1234' from Schema 1 to Schema 2.
Account has moved from schema1 to schema 2.
But UNIQUE_ACCT_NO_T is behaving differently with respect to UNIQUENESS_T.
In UNIQUENESS_T the /account Obj and /service Obj DB got update to DB 2.
But /uniqueness object is still in schema 1 ( poid_db = 1) which is correct.

But in case of UNIQUE_ACCT_NO_T
/unique_account_no Obj DB got updated to NULL in schema 1 and created another entry in Schema 2 (DB 2).
This is not consistent with UNIQUENESS_T and causing problems.

Referring UNIQUE_ACCT_NO_T in Schema 1 to get the account details and DB details.

Impact :
All the payment (Belonging to the all schema) is posted via custom MTA application which uses master_cm (Only configured in Primary BRM Server). The flow internally calls OOB PCM_OP_PYMT_COLLECT.

Referring UNIQUE_ACCT_NO_T to get the account DB.
So payments are getting suspended as it’s not able to find ACCOUNT by referring UNIQUE_ACCT_NO_T in Schema 1.

Cause

Sign In with your My Oracle Support account

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

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms