When a Noetix View Does not Exist

When a Noetix View exists and it is at right granularity that our user community requires, all is well. We can go in and modify the Noetix View to meet a new requirement very easily. What about when this is not the case?

Here is an example

We have implemented Oracle Applications Advanced Pricing (R12) and our main price list has a pricing context of item (very common implementation) but contrary to the standard configuration, we have set attribute two of pricing to the pricing category and our main price list is based on the pricing category of an item.

Main observation: No Noetix view exists that is similar. No custom view can be created which "piggy backs" off of a Noetix View.

Our main choices: a. Submit this requirement and sql that shows how we have set-up our price list to Noetix engineering. It might take some time before we see anything of value.

Pros: This is supported.

Cons: Unacceptable response time to user community.

b. Create a hook script (xu6) and create the view needed. We then will have to maintain a copy of the folder in Discoverer of the resulting view. The folder and business area will have to be maintained separately from Noetix tools. Specifically, the view will need to be in a custom business area so that it does not get blown away after an EUL generation.

Cons:While this is the accepted way to make this change, we are on our own in terms of Noetix and Oracle Applications upgrades. In addition to this, the end user experience would be more challenged in comparison to a standard Noetix View (e.g. no Noetix Help file or Noetix Search file).
Pros: We would receive a pat on the back from Noetix in terms of approaching our problem in the accepted way.

c. Create a hook script (xu2) which will result in the view being re-produced in all operating units and I will be able to have the Help file/Noetix Search document the nature of this view. I have created a package which allows for the generation of the DML associated with a seeded Noetix View. With this package, I can copy a seeded Noetix View and change the view label as needed. Next, additional changes are made (e.g. using the get_data_tmpl.sql script) until the view meets its requirements. Like approach b, we would be responsible for maintaining the view for all Noetix and Oracle upgrades. Views that are like this could be documented and identified to follow the seeded Noetix View that it is imitating. This would have a very similar maintenance cost to the company as approach b, except the end user experience would be better. All workbooks associated with views with this approach or approach b would be at an upgrade risk. It appears that the long term cost of views created by a xu6 would have a slightly higher maintenance cost than a xu2 approach.

Pros: Once the heavy lifting is done to create an xu2 script, all of the maintenance costs are at upgrade times.

Cons: Upgrade risk.

d. Similar to approach b, but create custom views built on Noetix views.

Pros: Use the work Noetix put into understanding Oracle Applications.

Cons: “Views on views” issue and all the problems identified with approach b.