I'm configuring GL segment configuration file in financial analytics...it's src file file_glacct_segment_config_source_system .csv we have only one COA id and 7 segments with value set id's. I configured a single row with COA id and segment with value set id's
Pre configured file of BI APPS installation of above contrails a row last in the file with AGGREGATE Y,Y,Y,Y,Y,Y up to six segment value..below are my queries
- as we have only one COA id we have one row..do we need to still use that AGGREGATE ROW below COA row
-if it has to be used till how many segment values we need to keep as Y, till 6 segments as it was pre configured or depending upon our segments?
please suggest..thanks in advance...
Thanks veera, so you mean that AGGREGATE row should be there in the config even if we have one COA id..
we have 7 segments but it configured default for 6 segments as Y do I need to add Y to other segment as well or should I leave...
You might be specifying the segment codes in the sheet right, there you need to enter the codes and then flag.
For any info check this
Pls mark correct/helpful
You should leave the aggregate row in the config file and configure it as required. You can specify up to 6 segments that can be aggregated.
The aggregate row is used to specify the granularity of aggregate fact table W_GL_BALANCE_A, which is created for performance reasons. The fact table W_GL_BALANCE_F contains measures at the granularity of each segment of your CoA (effectivey code combination level). Most of the time companies will only be interested in reporting on, say, three segments for the majroty of queries (e.g. Cost/Profit Centre, Natural Account, Company). So, if we flag these segments as AGGREGATE, the aggregate fact table is built by the ETL which will aggregate measures by just these segments and ignore the other segments. This results in an aggregate fact table with much fewer records, which will improve query performance. The more segments you specify to be included in the aggregate, then the less performance benefit you will get from the aggregate (as it will tend towards having the same grain as the base fact table).
Aggregates and base facts are modelled in BI as separate logical table sources, so if you drill down in a report from the aggregate level to the detail level, the query switches to pull data back from the base fact instead of the aggregate.
Please mark if helpful/answered,
Thanks@Andy for your valuable information... You should leave the aggregate row in the config file and configure it as required in the sense I should leave it with out row or should I configure it as required.
Also wanted to know if we change Y flag in the row does it affects any pre built dashboards data? or it is used for only ad hoc reports...like if y flags are for 6 segments.the dashboard/report data differs when y flag are for 2 segments?
thanks in advance...
You need to leave the row in the file, but then set up to six segments to be aggregated (as required, based on my explanation above).
Changing the flags to Y / NULL will only affect how the aggregate is populated, not the base fact, so it will therefor only potentially affect performance as described above. All out of the box content will still run.
Hope that clears it up for you. Please mark if helpful/correct,