My Oracle Support Banner

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

Last updated on MARCH 24, 2019

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.

Changes

 

Cause

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
Symptoms
Changes
Cause
Solution
References


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