Incorrect Behavior Of UNIQUE_ACCT_NO_T With Respect To UNIQUENESS_T
(Doc ID 2038243.1)
Last updated on APRIL 30, 2021
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 primary_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 |