What are the Most Common Customizations you Make to the BI Apps?

[Mark Rittman]

Hi All

I'm doing a bit of research into what are the most common
customizations that are applied to an out-of-the box installation of
BI Apps.

Could anyone with experience in this area perhaps reply back with two
or three customizations that you always end up doing, and let me know

- the purpose of the customization
- why it needs to be performed
- what tools you use (INFA? RPD etc)

For example

- add budget data to the GL subject area
- because it's not present before 7.9.5 for EBS sources
- we use INFA to map in additional columns, then expose those through
the RPD and catalog.

I'm gathering this for a meeting with one of the ODI Oracle PMs next
week so it'd be great to get some ideas from this group.

thanks

Mark

[Gerard Braat]

Hi Mark, Here are my three cents:

 

Apart from Adding new tables and columns as a result of customizations in sources (especially when source is Siebel ranked 1st and EBS ranked 2nd), impacting everything (ETL, DAC, BAW, RPD, WEBCAT) to reflect the table extensions or new facts/dimensions:

 

1. Integrating multiple sources,especially EBS with Siebel or EBS with SFDC (including building new adapters for that).

• Main challenge here is the common dimensions to be sourced from an MDM (if at all present in the landscape) enriched with source specific attributes from CRM, ERP or SCM systems
• Other challenges: the missing 3NF foundation layer (missing in in BI Apps, but present in the Oracle DW ref architecture)

2. Create Cross-Functional Dashboards, mainly impacting the catalog since these dashboards do not exist out of the box:

• Mgt Dashboards for country managers, sales and service directors
• CxO KPI dashboards for Sales, Service, Finance, Stock, Order portfolio, Headcount etc. (Management Excellence KPI's)
• Account managers who require a complete view of there customers across all business processes (from manufacturing, via order, contracts to delivery and service mgt)
• At Siebel Systems (good old times) we had the nice Executive Analytics dashboards for those who remember.

3. Localization requirements

• Adding functionality for regulatory compliance, especially in the areas of HR and Finance (laws in Netherlands are different from France, Germany etc.) 
• Enterprise companies in multiple countries in europe have local KPIs (slightly) different than those of other countries.
• Impact: ETL, DAC, BAW, RPD, WEBCAT

Hope this helps

 

Gerard Braat

 

 

 

 

 

 

--
You received this message because you are subscribed to the Google
Groups "OBIEE Enterprise Methodology Group" group.
To post to this group, send email to
obiee-enterpri...@googlegroups.com
To unsubscribe from this group, send email to
obiee-enterprise-met...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/obiee-enterprise-methodology?hl=en

All content to the OBIEE EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the OBIEE EMG with a link to the Google Group (http://groups.google.com/group/obiee-enterprise-methodology).

[Mark Rittman]

Hi Gerard

That's great. It'd be good to hear from anyone else on this topic as
well.

regards

Mark

On Sep 10, 12:34 pm, Gerard Braat <gbr...@gmail.com> wrote:
> Hi Mark, Here are my three cents:
>
> Apart from Adding new tables and columns as a result of customizations in
> sources (especially when source is Siebel ranked 1st and EBS ranked 2nd),
> impacting everything (ETL, DAC, BAW, RPD, WEBCAT) to reflect the table
> extensions or new facts/dimensions:
>
> 1. Integrating multiple sources,especially EBS with Siebel or EBS with SFDC
> (including building new adapters for that).
>

>    - Main challenge here is the common dimensions to be sourced from an MDM

>    (if at all present in the landscape) enriched with source specific
>    attributes from CRM, ERP or SCM systems

>    - Other challenges: the missing 3NF foundation layer (missing in in BI

>    Apps, but present in the Oracle DW ref architecture)
>
> 2. Create Cross-Functional Dashboards, mainly impacting the catalog since
> these dashboards do not exist out of the box:
>

>    - Mgt Dashboards for country managers, sales and service directors
>    - CxO KPI dashboards for Sales, Service, Finance, Stock, Order portfolio,

>    Headcount etc. (Management Excellence KPI's)

>    - Account managers who require a complete view of there customers across

>    all business processes (from manufacturing, via order, contracts to delivery
>    and service mgt)

>    - At Siebel Systems (good old times) we had the nice Executive Analytics

>    dashboards for those who remember.
>
> 3. Localization requirements
>

>    - Adding functionality for regulatory compliance, especially in the areas

>    of HR and Finance (laws in Netherlands are different from France, Germany
>    etc.)

>    - Enterprise companies in multiple countries in europe have local KPIs

>    (slightly) different than those of other countries.

>    - Impact: ETL, DAC, BAW, RPD, WEBCAT

>
> Hope this helps
>
> Gerard Braat
>
> On Fri, Sep 9, 2011 at 11:25 PM, Mark Rittman

> <mark.ritt...@rittmanmead.com>wrote:

[Shyam Varan Nath]

On the localization and HR, I can add one more - pertinent to global implementations:

1. European Laws (as I understand) do not allow non-European managers to see the employee details even if they are direct reports to non-European manager, Hence in HR analytics, drill down should not allow say a US manager to see any European employee details. Impacts can be security model and action links instead of hierarchy driven drill down.
2. Likewise, I understand, a European manager is allowed to see only two level drill-down on reporting chain of employees.  So if a global company is implementing HR analytics, the myriad of scenarios call for heavy customization of HR Analytics.
3. Missing 3NF foundation is a major issue I find when customer wants a "full scale EDW"   - the dilemma remains whether to build the 3NF foundation and data marts in-house  and not go for BI apps or start with BI apps, roll out OBIEE, then build 3NF EDW and re-wire the data marts to 3NF so that historical trail of data in a true data warehouse fashion is available.

Mark, thanks for starting this trail....

Shyam

[Shyam Varan Nath]

The common customizations I have seen are:

1. Adding external sources of data in additional to main ERP, e.g. EBS R12 is used for Human Resource Management but a different system is used for performance rating, so bring in the performance rating data into DW as an external interface / flat file etc
2. Adding columns to existing dimensions and facts as X_Columns - bring them via ETL (make DAC metadata changes) and then add to RPD
3. Create new star schemas for areas are that not covered in BI apps today like OPM - Inventory for process manufacturing (in this case it touches all sub-systems data model, ETL, DAC, RPD, Answers
4. Budget v/s actual type of financial reports requirement bring in data from say Hyperion Planning system and actual transactions from ERP...

[Imran Shah]

1.  Adding Various Flex Fields (eg ATTRIBUTEX) fields from EBS into the Warehouse and OBI Model as required.  
  - They don't come in by default
 - Use Informatica  ETL  / DAC and Model Updates

2. Rename various Dimensions and Columns to what they are known as in the Source. Typically GL Segment Dimensions in Finance Analytics, but also things like Plant / Storage Location in Supply Chain and Order Management, Plus Product Dimension.
- As BI Apps is designed to sit over different sources, often the names are more generic, but in reality the sites we have implemented source from one place Eg EBS or Peoplesoft, and users prefer naming as per source system
- Requires OBIEE Model Logical and / or Presentation Column renames and associated Web Catalog modifications where columns / tables referenced.

3. Adding Summaries for GL and / or Joining to GL Facts directly to W_GL_SEGMENT_D for more acceptable performance for basic reporting
- Sometimes (not always), basic reporting on GL Facts is not acceptable out of the box , even in Pilot type scenarios, without some basic tweaking of the Model
- ETL / DAC and OBIEE Model Changes.

--
You received this message because you are subscribed to the Google
Groups "OBIEE Enterprise Methodology Group" group.
To post to this group, send email to
obiee-enterpri...@googlegroups.com
To unsubscribe from this group, send email to
obiee-enterprise-met...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/obiee-enterprise-methodology?hl=en

All content to the OBIEE EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the OBIEE EMG with a link to the Google Group (http://groups.google.com/group/obiee-enterprise-methodology).

--
Regards,
Imran Shah

[Christian Berg]

Hi all,

A definite +1 to Gerards initial comments on the Siebel and EBS
customizations with all their impact - with more focus on Siebel here
in central Europe since EBS isn't that much of a topic here in
comparison. Likewise for SFDC which gains more of a foothold as a
datasource.

Especially in situations with heavily customized Siebel and EBS
sources and the OBAWH evolving into a more prominent and central EDW a
recurring point of interest is the development of a data lineage /
data tracking model.
- Keeping track of the actual data flow from source systems through
the ETL layer(s) and the RPD
- Identifying data origins for multi-source subjecta areas through
all layers
- Support for maintenance and change processes instigated by source
system changes

Paper/word .doc documentations all get written at some point in time,
rarely get updated and are in many cases quite pointless since no one
reads through hundreds of pages of verbose ETL processes.

Unlike the Executive Anaytics dashboard not something we lost over
time but never got as a product from Oracle so far even though
demanded since the earliest days of the Siebel Analytics Applications.

Cheers,
Christian

On Sep 12, 7:48 am, Imran Shah <isha...@gmail.com> wrote:
> 1.  Adding Various Flex Fields (eg ATTRIBUTEX) fields from EBS into the
> Warehouse and OBI Model as required.
>   - They don't come in by default
>  - Use Informatica  ETL  / DAC and Model Updates
>
> 2. Rename various Dimensions and Columns to what they are known as in the
> Source. Typically GL Segment Dimensions in Finance Analytics, but also
> things like Plant / Storage Location in Supply Chain and Order Management,
> Plus Product Dimension.
> - As BI Apps is designed to sit over different sources, often the names are
> more generic, but in reality the sites we have implemented source from one
> place Eg EBS or Peoplesoft, and users prefer naming as per source system
> - Requires OBIEE Model Logical and / or Presentation Column renames and
> associated Web Catalog modifications where columns / tables referenced.
>
> 3. Adding Summaries for GL and / or Joining to GL Facts directly to
> W_GL_SEGMENT_D for more acceptable performance for basic reporting
> - Sometimes (not always), basic reporting on GL Facts is not acceptable out
> of the box , even in Pilot type scenarios, without some basic tweaking of
> the Model
> - ETL / DAC and OBIEE Model Changes.
>

[Kevin Baker]

1. Specific business rules - this required the addition of an aggregate layer in the HR module for turnover and retention calcs

2. Handling of performance issues in both HR and Finance (GL) modules - again adding in more aggregation tables and KPI MV's

3. GL Actuals + Budget reporting - custom fact aggregate required for this

4. Same as Gerard's bullets 1 and 2 for our environment.

Hope this helps.

Kevin

[Frank Davis]

Here are some notes and thoughts I have on the topic:

- majority of customizations are extension columns
- Easier and more flexible Multi-calendar W_MCAL support. It would be
great to have better and more flexible configuration and customization
of the w_mcal_day_d table. I have had clients with multiple calendars
other than fiscal calendars, such as sales, operations and so on in
their entire organization. Issue is that they do not have these
calendars entered in their source systems and they do not conform with
the 4-4-5 or 13-week pre-builts. The dream would be interface to
configure calendar and then the ETL to build it.

The one that I have been asked for by multiple clients is the
following:

- reporting on invoice line item level detail and its corresponding
AP/GL details together in one report without guided navigation. This
is possible via guided navigation; but, the business tends on forcing
the issue of having it all in one report (table view). Now the issue
mostly I see is that in Procure and Spend the different subject areas
are at different grains and some like w_purch_rcpts_f do not join to
w_gl_account_d. Which after you understand the design and try to tell
the business they just want their cookies and eat them too. So I
would have to come up with a customization to piece it together.
Further information is that purch_rcpts are at the line item level
whereas purch_order_lines and w_ap_inv_dist_lines_f are both at the
distribution line level which is one level below the PO lines.

Good to haves:
- Design and setup for Peoplesoft to truely perform incrementals.
From my past experiences, peoplesoft tables do not have audit columns
(ie. create_date, last_upd_date cols) so incremental ETL seems to be
overkill with extracting everything. It would be great if they built
in a design to improve this and also be acceptable to the source
system DBAs so that the source system will not be effected performance
wise.


-Frank

[Mark Rittman]

Hi All

Thanks everyone for this.

Whilst we're on the subject, what (if any) concerns might you have if
you had to do these types of customizations with ODI, as the product
stands now?

regards

Mark

[Adrian Ward]

In addition to the points already made by Frank and Gerard I would be looking for one simple(sic) thing.

Full flexibility around:

Slowly changing dimensions, 

Updating attributes (e.g. a business unit managers name), 

Updating inherited dimensions (e.g. an Organisations' cost centre) and, 

Multi attribute lists (e.g. Lists of doctors specialities at a particular hospital),

Ghost Records

Siebel Apps had it's way of dealing with each of the above challenges, and it seems that different parts of the current BI Apps deal with SCDs etc in different ways.  Some use current snapshot, some have historical view only and the odd one has full flexibility to do both.

Another example of the issues faced here are with Hierarchies, where structures and parents change over time.  There needs to be a way of efficiently going back in time.

A part of this challenge can lay with the ability to represent what is in the source system, and this is often blocked by source system people not allowing triggers.  A common work around needs to be developed to identify the gaps (deleted records, updates without system field impact, etc) 

Oh and one last thing, lets get the BI Apps to stick with the rule that if a WID exists in the fact, then it should exist in a joining dimension (something that gets broken in OOTB)

Adrian

[Mark Rittman]

Thanks Adrian,

Mark

On Sep 12, 10:34 pm, Adrian Ward <adrian.w...@majendi.com> wrote:
> In addition to the points already made by Frank and Gerard I would be looking for one simple(sic) thing.
>
> Full flexibility around:
>         Slowly changing dimensions,
>         Updating attributes (e.g. a business unit managers name),
>         Updating inherited dimensions (e.g. an Organisations' cost centre) and,
>         Multi attribute lists (e.g. Lists of doctors specialities at a particular hospital),
>         Ghost Records
>
> Siebel Apps had it's way of dealing with each of the above challenges, and it seems that different parts of the current BI Apps deal with SCDs etc in different ways.  Some use current snapshot, some have historical view only and the odd one has full flexibility to do both.
>
> Another example of the issues faced here are with Hierarchies, where structures and parents change over time.  There needs to be a way of efficiently going back in time.
>
> A part of this challenge can lay with the ability to represent what is in the source system, and this is often blocked by source system people not allowing triggers.  A common work around needs to be developed to identify the gaps (deleted records, updates without system field impact, etc)
>
> Oh and one last thing, lets get the BI Apps to stick with the rule that if a WID exists in the fact, then it should exist in a joining dimension (something that gets broken in OOTB)
>
> Adrian
>
> On 12 Sep 2011, at 15:51, Kevin Baker wrote:
>
>
>
>
>
>
>
> > 1. Specific business rules - this required the addition of an aggregate layer in the HR module for turnover and retention calcs
>
> > 2. Handling of performance issues in both HR and Finance (GL) modules - again adding in more aggregation tables and KPI MV's
>
> > 3. GL Actuals + Budget reporting - custom fact aggregate required for this
>
> > 4. Same as Gerard's bullets 1 and 2 for our environment.
>
> > Hope this helps.
>
> > Kevin
>

[Christian Berg]

One other thing on which I'd also be interested to hear your input
(not necessarily a OBIA customization per-se, but was part of Siebel
Analytics Apps, so bear with me):

The usage of OBIEE as a operational reporting engine through the usage
of busines models directly derived from the OLTP data sources - e.g.
the "Real-Time XYZ" business models for Siebel datasources in the
vanilla OracleBIAnalyticsApps.rpd.

I see this being considered and as an extension of (and in some cases
replacement for) BIP Publisher functionality and Oracle is pitching it
to clients as well.

Cheers,
Christian

On Sep 12, 11:34 pm, Adrian Ward <adrian.w...@majendi.com> wrote:
> In addition to the points already made by Frank and Gerard I would be looking for one simple(sic) thing.
>
> Full flexibility around:
>         Slowly changing dimensions,
>         Updating attributes (e.g. a business unit managers name),
>         Updating inherited dimensions (e.g. an Organisations' cost centre) and,
>         Multi attribute lists (e.g. Lists of doctors specialities at a particular hospital),
>         Ghost Records
>
> Siebel Apps had it's way of dealing with each of the above challenges, and it seems that different parts of the current BI Apps deal with SCDs etc in different ways.  Some use current snapshot, some have historical view only and the odd one has full flexibility to do both.
>
> Another example of the issues faced here are with Hierarchies, where structures and parents change over time.  There needs to be a way of efficiently going back in time.
>
> A part of this challenge can lay with the ability to represent what is in the source system, and this is often blocked by source system people not allowing triggers.  A common work around needs to be developed to identify the gaps (deleted records, updates without system field impact, etc)
>
> Oh and one last thing, lets get the BI Apps to stick with the rule that if a WID exists in the fact, then it should exist in a joining dimension (something that gets broken in OOTB)
>
> Adrian
>
> On 12 Sep 2011, at 15:51, Kevin Baker wrote:
>
>
>
>
>
>
>
> > 1. Specific business rules - this required the addition of an aggregate layer in the HR module for turnover and retention calcs
>
> > 2. Handling of performance issues in both HR and Finance (GL) modules - again adding in more aggregation tables and KPI MV's
>
> > 3. GL Actuals + Budget reporting - custom fact aggregate required for this
>
> > 4. Same as Gerard's bullets 1 and 2 for our environment.
>
> > Hope this helps.
>
> > Kevin
>

[Kimmo Kantojärvi]

Hi Mark and others,

Typical customization scenarios I've faced in eBS source system
related environments:
1. Additional flexfields from source system
- descriptive flexfields are not included in the OOTB and often this
data is much needed

2. Incorrect/different KPI logic
- e.g. supplier on time delivery calculation in OOTB is just
comparison of promised date and actual receipt date whereas in real
life there are various components to be taken into account (lead
times, partial deliveries, etc.)

3. Limited hierarchies available
- e.g. GL accounts are mapped to high-level account structure that is
used in OOTB reports (e.g. sales costs contains multiple GL accounts).
Typically this is not enough and one should be able to combine
accounts and cost centers into the report like you can do in FSG
reports (basically any accounting segments can be combined). For
example same GL account (e.g. salaries) can be used in different cost
centers (e.g. sales and general administration) and when only account
is used in the OOTB reports you can't separate sales and general
administration costs in the report.

4.Custom reports.
- OOTB reports are really in high-level and typically managers at
least in Europe prefer more detailed views on data

Regards,
Kimmo

[browns_fan]

Mark:



I will respond in a somewhat generalized manner. The reason we do
customizations in our BI Apps instance is because we customized
Oracle during the implementation so it doesn’t always work with the
“OOTB” Oracle adaptor or we don’t have that process available in
Oracle. One specific example of this is prior to doing the OBIEE
install for Procurement and Spend Analyzer we did not keep track of
UNUSPC (product) code because we didn’t necessarily need them set up
to get products ordered in purchasing module of eBiz. When we started
doing the reporting we felt is was vital to be able to group via
UNUSPC code so we starting putting them in for current products and
PO’s but there was no data for historical PO’s or discontinued
products so we had to create spreadsheets and import the data to fill
the gaps for historical records or unspecified products.


Tools necessary to complete: ETL, DAC, OBAW, RPD, WEBCAT



The second reason we do customization is because in BIApps ‘OOTB” a
particular field was not used in the dashboards so the designers did
not include it in the workflow. An example of this is the field
“Requestor Name” which is only used in one of the subject areas and is
pulled through the workflow to populate the data warehouse field for
that subject area but in the other fact tables it was not pulled
through. Users wanted to build requests and ad hoc reports with this
field in the other subject areas we needed to do a customization to
bring the field through to those fact tables


Tools necessary to complete: ETL, OBAW, RPD, WEBCAT



Hope this helps

Mark Whitlock

On Sep 9, 5:25 pm, Mark Rittman <mark.ritt...@rittmanmead.com> wrote:

[Mark Rittman]

Hi All

Thanks to everyone for helping out with this. I've collated the
answers and tried to summarize them in a Google Docs spreadsheet,
which I have published for public viewing:

https://docs.google.com/a/rittmanmead.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0Alsb7uc3oet7dHNTWHNNWTB3TURiczVwMV9FWHBYTWc&output=html

I'm passing on this information to the data integration product team
within Oracle, who were looking at the common customization scenarios
for the BI Apps, with a view (I guess) to making sure whatever
complements/replaces INFA some point in the future can anticipate
these.

thanks again

Mark

[Dila]

I know you compiled the list already Mark, and some of mine might be
repetitions but here we go in any case: (mostly around EBS Financials)

1) Add many more Group Account numbers to the config spreadsheet and
have to create multiple iterations of measures in the BM layer to
various fact tables for Financial Analytics
- WHY: Most clients do their financial statement at different line
items then what is provided OOB for Group Account numbers
- TOOL: Many RPD BMM layer custom measure additions in multiple facts

2) Create prior year measures for GL
- WHY: Most financial reporting looks at comparisons. I do not know
why this is not available OOB.
- TOOL: Create new aliases in RPD Physical layer to support prior year
measures, plus create corresponding measures in BMM and Presentation
layer

3) Bring in planning data for GL
- WHY: Analysis is done as actuals to budget and forecast for
financials.
- TOOL: Utilize Informatica to create ETLs to process raw files from
Hyperion Planning and load the data utilizing Universal adapters.
Customize DAC for universal adapter loads so EBS data is not
overwritten.

4) Add a lot of Descriptive Flexfields and actual AP/AR/GL fields into
BIApps tables.
- WHY: The value client are looking for in BIApps is to be able to
drill into all operational detail from let's say GL Balances. Not all
columns are available for reporting though these may be available in
the BIApps Staging tables. Also, there are quite a few DFFs users
create in EBS that need to be reported on.
- TOOL: Combination of Informatica and RPD customizations.

5) Support for creating financial statement lines from multiple
segments.
- WHY: Most clients do not build their financial statements just from
the Account segment. They utilize Department and Product as well or
any other segments.
- TOOL: RPD layer customizations to create new measures relying on
multiple segment hierarchies

6) Operational drilldown links
- WHY: There is requirement to tie and drilldown to operational data
at each client. It would be nice if there was an operational rpd
available for these drilldown needs or real-time report needs.
-TOOL: Added missing fields via Informatica, updated RPD layer with
new columns, created new reports and linked them for drilldown
purposes.

And a few of the most obvious ones such as adjusting OOB KPIs and
Reports to fit client environment. If I come up with more, will let
you know. Thank you for compiling this.

Dila Cil

On Sep 15, 7:45 am, Mark Rittman <mark.ritt...@rittmanmead.com> wrote:
> Hi All
>

> Thanks to everyone for helping out with this. I've collated the
> answers and tried to summarize them in a Google Docs spreadsheet,
> which I have published for public viewing:
>

> https://docs.google.com/a/rittmanmead.com/spreadsheet/pub?hl=en_US&hl...

> > > Mark- Hide quoted text -
>
> - Show quoted text -

[Jit Dutta]

To second what Dila wrote for Item 5, banks (also other industries) need regulatory report hierarchy that does sub-totals at the intersection of multiple GL segments. To achieve this one needs to create new measures with Filter statement involving multiple segments and the base measure from W_GL_BALANCE_FACT. However such RPD measures results in poor report performance due to multiple layers of Filter statement in the SQL.

To circumvent above issues with RPD measures some clients do build non-ERP regulatory report hierarchy in in OBAW using a flat file or a UI in EBS or PS EGL as the source. Such custom reporting hierarchy take into account the various intersections to derive the parent-child relations.

In addition I think Oracle is working on providing the ability to set Group Account Number with multiple segments as opposed to current design based solely on natural account.

Jit

> Date: Thu, 15 Sep 2011 08:26:33 -0700
> Subject: [OBIEE EMG] Re: What are the Most Common Customizations you Make to the BI Apps?
> From: dila...@gmail.com
> To: obiee-enterpri...@googlegroups.com

[Jit Dutta]

Hi Mark,

Thanks for compiling the list. Would you please include the issue with the current Group_account_Num design that OOTB incorporates only natural account whereas in reality clients require intersection of multiple segments. Also, the issue of having to load non-EBS regulatory report etc hierarchies that are needed for reporting but not required to conduct EBS transactions.

Most large clients hardly use only natural account to specify a BS measure such as Operating Expense etc and creating an RPD derived measure with complex Filter criteria makes the reports unwieldy in OBIEE 11g. Of course I understand this can be done much easier in Essbase.

Thanks!

> Date: Thu, 15 Sep 2011 05:45:49 -0700

> Subject: [OBIEE EMG] Re: What are the Most Common Customizations you Make to the BI Apps?

> From: mark.r...@rittmanmead.com
> To: obiee-enterpri...@googlegroups.com

[Dev Obiee]

Hi Mark ,

The below can sound like too technical ...

There are scenarios where OOTB ETLS in informatica have shared objects
(like sequence generators transformation)across multiple mappings ,
if we customize one among the mapping copying it to a custom folder
(and not having a shortcut to the seq generator in the custom
folder) , leaving the rest mapings to the OOTB (SILOS folder) , this
will create load issues .

As a standard practise , before a ETL customization , check for shared
objects , if exist , better have the all relevant mappings involving
the sharedobject to teh custom informatica folder , and do the
relevant DAC changes (refering the tasks to the custom folder)

Thanks
kumar.

On Sep 15, 3:52 pm, Jit Dutta <jdutta...@hotmail.com> wrote:
> Hi Mark,
>
> Thanks for compiling the list. Would you please include the issue with the current Group_account_Num design that OOTB incorporates only natural account whereas in reality clients require intersection of multiple segments. Also, the issue of having to load non-EBS regulatory report etc hierarchies that are needed for reporting but not required to conduct EBS transactions.
>
> Most large clients hardly use only natural account to specify a BS measure such as Operating Expense etc and creating an RPD derived measure with complex Filter criteria makes the reports unwieldy in OBIEE 11g. Of course I understand this can be done much easier in Essbase.
>
> Thanks!
>
>
>
> > Date: Thu, 15 Sep 2011 05:45:49 -0700
> > Subject: [OBIEE EMG] Re: What are the Most Common Customizations you Make to the BI Apps?

> > From: mark.ritt...@rittmanmead.com

> > To: obiee-enterpri...@googlegroups.com
>
> > Hi All
>
> > Thanks to everyone for helping out with this. I've collated the
> > answers and tried to summarize them in a Google Docs spreadsheet,
> > which I have published for public viewing:
>

> >https://docs.google.com/a/rittmanmead.com/spreadsheet/pub?hl=en_US&hl...

> > All content to the OBIEE EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the OBIEE EMG with a link to the Google Group (http://groups.google.com/group/obiee-enterprise-methodology).- Hide quoted text -

[Ramke Ramakrishnan]

Jit,

For this, Oracle has given a Code Fix that includes changes to the template CSV as well as selective Informatica SDE mapping changes.  Refer to Bug # 9202898.

• Related Bug Number: 9202898

• Product: Oracle BI Applications, Financial Analytics

• Issue: The current architecture of Group Account Numbers supports mapping only the Natural Account segment values to a Group Account Number. It doesn’t support mapping multiple charts of accounts (COA) segments to Group Account Number.

Thanks,

ramke

[Jit Dutta]

Ramke,

Thanks for the info.
Does this support unlimited number of segments or is there a limit how many segments can be part of the mapping?
Can we have a mixed mapping, for instance, a Group Account Number such as AP would map to only natural account segment, whereas something like Operating Expense may map to multiple segments. Does this fix allow the Group Account Numbers mapped to different combinations and number of segments?

Jit

---

Date: Sun, 18 Sep 2011 00:53:25 -0400
Subject: Re: [OBIEE EMG] Re: What are the Most Common Customizations you Make to the BI Apps?
From: ramke.ram...@gmail.com
To: obiee-enterpri...@googlegroups.com

[Prakash Jhunjhunwala]

Hi,

Typical customizations that I have faced (similar to others)
1. Additional Columns (DFFs, Attributes - Products, Customers that are
not part of OOTB)
2. Category Sets: Defining category hierarchy, levels, hiding columns
3. Additional Data Sets: Item Catalog, Item X-Refs.
4. KPI Customization: OOTB KPI definition not aligning with business
requirement
5. Additional Level Measures: Sales - Invoice, Bookings require new
measures - prior time periods, ytd etc.

Thanks,
Prakash

[Jit Dutta]

Hi Ramke,

I checked with Oracle Support on this issue. They appear to state that there is no general solution yet. Engineering would work with specific client situation to resolve any related issues. In other words it doesn't seem that we would have the ability to map multiple segments to the Group Account Number in OOTB OBIA yet.

Thanks.

---

Date: Sun, 18 Sep 2011 00:53:25 -0400

Subject: Re: [OBIEE EMG] Re: What are the Most Common Customizations you Make to the BI Apps?
From: ramke.ram...@gmail.com
To: obiee-enterpri...@googlegroups.com

[Ramke Ramakrishnan]

Jit,

That is incorrect. I have a published document provided by Oracle on how to map multiple segment to Group Accounts. This will require simple change to the group account template CSV file and corresponding Informatica mapping change that is documented in detail. i don't want to blast it to the group but look for my email to your hotmail account.

Thanks,

ramke