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 18.104.22.168.0 to 22.214.171.124.0 [Release 7.5.0]
Information in this document applies to any platform.
On 126.96.36.199.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.
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.
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