Is It Possible to Add a Custom / User Defined Dimension (Leaf) to A Single Management Ledger and Transaction Table? (Doc ID 2949521.1)

Last updated on OCTOBER 02, 2024

Applies to:

Goal

Question 1: Currently have multiple management ledger tables for different purposes.
Would like to add a New Custom processing dimension(Leaf) to "one of the management ledger" and "One of the Transaction table" only.
Is that possible to do this and not add this new dimension to all other "Transaction and Instrument" tables?
Based on Document 1165483.1 How to Add a Custom / User Defined Dimension (Leaf) in OFSAA, it seems like this is not feasible.

Have multiple management ledgers used for processing Actuals (current month-end), Plan (1 yr forward) and now a third one for processing tech cost related data. These are all heavily used with OFSAA allocations and any reporting extract/prepare the data into separate "outbound " tables for reporting tools to pickup. Now have a use case for a new dimension that is only applicable to one of the Management Ledger and subset of the transactions tables. This new dimension is not applicable to Actuals or Plan ledgers nor the Actuals or Plan instrument and transaction tables.  Would prefer if this new processing dimension could be added to ONLY the related management ledger and transactions tables without impacting all the pre-existing / other Actuals and Plan management ledger, transaction and instrument tables.
  
The new dimension would be used in PFT allocations (hierarchy filters) on the source and driver as well as outputting debits/credits to this new dimension.
This new dimension would need to be a key leaf field in order to build rules/filter/etc as mentioned above.
 
Question 2:  Have created a new dimension on one Management Ledger table (not Actuals/Plan ledger) and all instrument/transactions.
Confirmed  that all existing instrument / transaction rules defaulted to and ran them WITHOUT saving and confirmed results.
Set the new user defined dimension to not null on the Management Ledger and Transactions Tables which use this new dimension.
Set new user defined dimension to NULLABLE on all other instrument and transaction tables.
It is understood that this setup is supported but not necessarily best practice.

However, after creating this new dimension, it was discovered that there is an object migration pre-requisite that key processing dimension key must match source and target.

Since this new dimension will go into Production much later in the year and is currently not planned to be put into production, is there any workaround to enable the business to migrate objects to/from environments where the new user defined dimension may exist in one environment but not the other?

Solution

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