Excluding Shared members from calculations

Hi,How can I exclude shared members from calculations so that shared members are not calculated twice?Regards

Hi Mayank,
Try *SELECT
*SELECT(%H%,"[ID]",HR_ACCOUNT,"[ID]<>Shift,Education_Assist")
*XDIM_MEMBERSET HR_ACCOUNT=%H%
Vadim
P.S. Or:
*SELECT(%H%,"[ID]",HR_ACCOUNT,"[ID]<>Shift AND [ID]<>Education_Assist")
Both will work
Message was edited by: Vadim Kalinin - P.S. Added

Similar Messages

Excluding members from calculation

I am trying to get this calculation to not include 2001 & 2002 members from the time dimension. I have tried adding this to the IF statements:AND (@CURRMBR(TIME) <> (@IDESCENDANTS(YR2001))) AND (@CURRMBR(TIME) <> (@IDESCENDANTS(YR2002))))It's not working. Please Help me.FIX(&CURRDAY, @UDA(TIME, "LastDay"), @UDA(TIME, "HistMthEnd"), @LEVMBRS(Entity, 0), @LEVMBRS(Accounts, 0)) ACTYTD_LOAD( IF ((@CURRMBR(TIME) <> #MISSING) AND (@ISUDA(TIME, "HistMthEnd"))) @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); ELSEIF (@ISUDA(TIME, "HistMthEnd")) @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; ELSEIF ((@CURRMBR(TIME) <> #MISSING) AND (@ISUDA(TIME, "LastDay")) AND (NOT (@ISISIBLING(&CURRDAY)))) @ANCEST(TIME, 4) = @CURRMBR(TIME); @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); ELSEIF ((@ISUDA(TIME, "LastDay")) AND (NOT (@ISISIBLING(&CURRDAY)))) @ANCEST(TIME, 4) = #MISSING; @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; ELSEIF ((@CURRMBR(TIME) <> #MISSING) AND (@ISMBR(&CURRDAY))) @ANCEST(TIME, 4) = @CURRMBR(TIME); @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); ELSEIF (@ISMBR(&CURRDAY)) @ANCEST(TIME, 4) = #MISSING; @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; ENDIF);

Could This Work ?/****************************//* Set &CurYear == "YR2003" *//****************************/If(@IsMbr(&CurYear)) {Your Code Here }else/* do nothing */endif;/* refactored but then maybe not */If (@curMbr("TIME") <> #Missing) then If (@isUda("TIME","HistMthEnd") then @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); Else If (@isUda("TIME","LastDay") then If (NOT (@IsSib(&CurDay)) then @ANCEST(TIME,4) = @CURRMBR(TIME); @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); Endif; Else If (@IsMbr(&CurDay)) then @ANCEST(TIME,4) = @CURRMBR(TIME); @ANCEST(TIME,3) = @CURRMBR(TIME); @ANCEST(TIME,2) = @CURRMBR(TIME); Endif; Endif; Endif;Else If(@isUda("TIME","HistMthEnd") then @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; Else If (@isUda("TIME","LastDay") then If (NOT (@IsSib(&CurDay)) then @ANCEST(TIME,4) = #MISSING; @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; Endif; Else If (@IsMbr(&CurDay)) then @ANCEST(TIME,4) = #MISSING; @ANCEST(TIME,3) = #MISSING; @ANCEST(TIME,2) = #MISSING; Endif; Endif; Endif;Endif;

Loading shared members from interface tables

Hi,
I am loading data to Hyp. Planning via interface tables. I need to load shared members. Where can i tell him that this is a shared member?
thank you very much
lubos

Will not it cause probles when loading shared members first before the original ones?
I thought that DataStorage only accpet values like StoreData, NeverShare etc.
I will try it out.
Thank you very much for your help
lubos

Exclude members from a dynamic calc - how ?

I've got a YTD figure as a dynamic calc in a 'YTD'member under the Time dimension. However users want to exclude certain members from the accounts dimension when the YTD dynamic figure is created.EGAccount dimension has members: Summary P&L Balance Sheet Want Balance Sheet not to be in YTD calcs.

Thanks for the advice.Did try this, and believe I've set it up correctly, but it's still creating a YTD figure for the Balance Sheet members.Time dimension has YTD fig, example member below: P3 YTD(2Pass,Dynamic calc)=P01+P02+P03Account dimension has below example members under Balance Sheet,which I've set to be 'Time Balance Last': Fixed Assets Stock Trade & Other Debtors Group Debtors Cash Trade Creditors What I want it to do for only P03 data to display for the Bal Sheet memebers.Have I missed something ?

Shared Members on interface changes of Entity or account hierarchy

Hello,
Is there any scripted way to remove 'Shared Members' from the Account and Entity hierarchy, or if not, is there any means of finding them on mass, as we have set up a database interface to maintain account and entities, but the problem is after accounts or entity change parent they leave a 'Shared Member' on the original parent, which is not desired functionality as it throws totals out on forms / reports.
thanks for your input, no blogs please as our security prohibits me seeing them.
Robert.

Thanks John, can I ask you a follow on also...
If a member had never share as its property and you used the hierarchy interface to assign it to a new would would it; -
a. Prevent update of its parent hierarchy via the interface
b. Move it to whatever new parent you deemed and remove it from its original
thanks for your input,
Robert.

ODI - Delete Shared Members?

Hello,
I load a node in a Planning dimension with Shared Members using an ODI Interface. We have a need to remove all of these Shared Members before we perform the load. Is it then possible to remove all Shared Members from specific locations using ODI? I know that we can run the Delete Shared Members utility from the server where Planning is installed, but that is not possible for admin users who do not have admin rights to the server. Version 11.1.1.2, ODI version 10.1.3.
Thanks in advance,
Steve

John,
Thanks for the reply. The dimension is in a Planning Application/database. I have a parent/child/Alias txt file that I used to load the dimension node with. Are you saying that it is possible to create an ODI interface that can "Delete Level 0" members? Below is a sample of the dimension via planning/dimensions. In this example, I would want to remove all members under the "COGS" node....or all "Shared Members". Below is also a sample of the file used to load the Shared Members.
Thanks again,
Steve
DEPT_SEC All Departments Depts Store View 4
     COGS Cost of Sales Depts Store 4
          D00400(Shared) Management Buffer - COGS (D00400) Shared 4
          D10013(Shared) ELE Las Vegas - COGS (D10013) Shared 4
          D10020(Shared) IT Infrastructure Eng COGS-SJC (D10020) Shared 4
          D10030(Shared) CCV Call Ctr-Customer Service (D10030) Shared 4
Parent     Child     Description     Status
Entities     DEPT_SEC     All Departments
DEPT_SEC     COGS     Cost of Sales
DEPT_SEC     G&A     G&A
DEPT_SEC     NO_DEPTID     No DeptID
DEPT_SEC     R&D     R&D
DEPT_SEC     S&M     S&M
COGS     00400     Management Buffer - COGS     A
COGS     10013     ELE Las Vegas - COGS     A

Shared Members in ASO

All - I am migrating outlines from 6.5(BSO) to 7.1.2 (ASO).When Imigrate I am unable to migrate shared members from BSO to ASO evenafter assigning the DIMENSION as Multiple Hierarchies Enabled. For Ex: DIM 1 (Multiple Hierarchy Enabled)..... Member 1(Dynamic Hierarchy) Child1 Child2 Child3 Child4 Member 2(Stored Hierarchy) Child3 (Shrared Member) Child4(Shared Member) I get an Error message as ASO does not support Shared Membersbut I have read that if you enable a dimension as MultipleHierarchy Enabled you can assing members of a Stored hierarchy asshared members.Please help with any inputs.Thanks in advance. Jeeva 

Had similar problem. Solved it doing these: in BSO outline, temporarily rename your shared members - just so the Conversion wizard can work. Change Dimension to Dynamic Calc. Once converted, change Dimension to Dynamic Hierarchy. Restore shared members to original names.

Access on Shared Members not working in reports

In our entity dimensions, we have all of our base members listed in under a parent folder, with permission assigned to each base member to allow access (not at the folder level).
We then have another parent folder which includes Regions, and then the base members are included under the appropriate region as a shared members. On the Region folders, we have iDescendants access setup for all the shared members.
When running reports, if a user who has access to the Region folders selects the Region folder, then they can see a consolidated report for all the shared members, but if they click on a specific shared member, they cannot see any numbers.
It looks like those shared members are not inheriting permissions from the parent folder. This was working before, and recently stopped.
Does anyone know what needs to be done to get the permission to start inheriting from the parent folder to the shared members?

Did a Refresh on Shared Members from Planning > Administration > Manage Database and this solved this issue.

Excluding Members from EPMA application - performance issues?

We are building a new application using dimensions from our Shared Library and I had a question about excluding some members.
For one dimension, I was able to use the "Add to App View" functionality, which was able to bring in only the one tree of members I wanted, without having to exclude anything, which seems to be the best way of doing this.
For another dimension, I need to pick and choose members from within the hierarchy, so I will need to add almost all parents, and then go through and exclude some members. Will this cause any performance issues having excluded members? Will the excluded members get deployed to planning or do they just sit in EPMA?
Any help would be appreciated.

Hi,
Excluded members are not deployed to Planning, therefore would not impact performance negatively.
Cheers,
Alp

Excluding detail and suppressed records from calculations in crystal xi

Is there anyway to exclude records from calculations in crystal xi
The report design contain group level A, group level B and group level C
In Group level C - the sorting order ensures that the most recent (and in this scenario relevant record) is displayed first - this is the record which is required for the calculations. This record is then moved into Group Level C header - thus only displaying the first record in this group. However any calculations which take place take into account all the detail records in Group Level C, and as a result the calculations are incorrect.
Running Totals are not an option as also on this report - in certain scenarios Group Level C may be suppressed altogether - is there anyway to exclude suppressed records from the calculations?
It is necessary to carry out the following calculations, using only the (unsuppressed) value from Group Header Leve C: Sum, Mean, Median
Thank you in advance

if i understand correctly you need to calcuate values based upon your group c
and the details of the group are in the details section
the only way you can accuratley calc this is MANUAL RUNNING TOTALS.
RESET
The reset formula is placed in a group header report header to reset the summary to zero for each unique record it groups by.
whileprintingrecords;
Numbervar X := 0;
CALCULATION
The calculation is placed adjacent to the field or formula that is being calculated.
(if there are duplicate values; create a group on the field that is being calculated on. If there are not duplicate records, the detail section is used.
whileprintingrecords;
Numbervar X := x + ; ( or formula)
DISPLAY
The display is the sum of what is being calculated. This is placed in a group, page or report footer. (generally placed in the group footer of the group header where the reset is placed.)
whileprintingrecords;
Numbervar X;
X

Exclude a version from the calculation

Hello,
In our model we have a version used uniquely to upload data. When the system starts to calculate, it includes this version. We have tried to lock the version,but it still included in the calculation.
We would like to know if is possible to exclude this version from the calculation in order to optimize the calculation.
Thanks in advance,
Best regards

First of all, thanks for your responses.
We would like to develop option 1 from Michaels' solutions, because we have too much LineItems (about 2000) for the option two. So we think, option 1 will be easier.
The version we are going to exclude is "Initial Charge". Are you suggesting we should make next rule?
       Function CellValue
          RestrictDimension("Versions","Initial Charge")
          CellValue=0
      End Function
In case of excluding a single period from that version, next rule would be correct?
      Function CellValue
         RestrictDimension("Versions","Initial Charge")
         RestrictDimension("Periods","January")
         CellValue=0
      End Function
Thanks again
Best regards!

Excluding material from calculation

Hi,
I would like to exclude some material indexes from calculation. They shouldn't be removed from BOM, but their prices shouldn't be included in the calculated standard price of Finished Good.
Is there a simple way of achieving this goal? I thought about marking the TAB "do not cost" in material Master data in Costing1 tab.
Hope somebody can help me,
Kind regards,
K

Hi Karol
You are at the right node please go ahead.
Do Not Cost
Controls whether a cost estimate or a procurement alternative can be created for a material.
Use
If you select this indicator, you cannot create any of the following for this material:
Material cost estimate (with or without quantity structure)
Sales order cost estimate
Procurement alternative
The material is excluded from selection and BOM explosion, so that no cost component split will be created by the costing process. If the material is included in another cost estimate as a component to be valuated, the valuation price is determined through the valuation variant if no cost estimate with the same key exists for the material.
Good Luck
Hari

Excluding task(s) from SPI or CPI Calculations

Is there a mechanism to exclude task(s) from being included in the SPI/CPI calculations?
The reason why I am asking this is we want to exclude a couple level of effort tasks from counting for or against the SPI/CPI.
Thanks,
Cheryl

Thank you Prasanna and Guillaume for your input.
Prasanna,
Removing the baselines on the particular task(s) does seem to exclude some of the data from being included in SPI/CPI; however the baseline initially rolled up to the level 0 summary task, so with this approach either the SPI/CPI should be not
be evaluated at the level 0 summary task level. Instead the values should be viewed for the section of baselined tasks, assuming that the schedule was arranged to isolate the level of effort (LOEs) tasks to not include in SPI/CPI. To avoid
this issue, at the initial onset of schedule development ensure the LOEs are isolated and NEVER include these in the baseline, even in the initial baseline that way their values are excluded. The ACWP will continue to get impacted, so CPI will always
be impacted even at Level 0 summary task. But we have some options, your suggestion allowed us to dig in these. Thank you.
Guillaume,
We may take a look at this approach, however we rely on the task updates from actuals, so yes does sound like a bit more work. But thank you for the suggestion.
Cheryl

Shared members and dynamic calc

I am trying to replicate a new cube from current GL cube and wish to remove unused shared members if they have any impact on essbase.
2/3 of my accounts (dense) member is stored with the remainder being shared members. Shared members do not add to block size. But having so many of them, does it impact on calc scripts or retrievals or any other impacts?
Secondly, in accounts and divisions, we have four levels. except for level 0, the remaining levels are all dynamic calc. Division is sparse member. Its not advisable to have dynamic calc on dense dimension. What about sparse dimension like division? Will it be better to change level 2&3 to dynamic and change level 1 to store as well?
We have also been advised by our consultant to change accounts to sparse dimension considering the number of times we need to update outline for new members (stored and shared).
Dimension          Type          Stored     Shared
Measure               Dense     1378     796     rest
Time               Dense     106     13     rest
Year               Dense     9     8
Currency          Sparse     12     9
Scenario          Sparse     41     38
Market               Sparse     20     12
Division          Sparse     490     302     rest
Product               Sparse     635     308
Reportcode          Sparse     327     299

Hi,
Having shared members in dense hierarchy will not have much of impact on Cube size or retrieval performance.
but its always advisable to avoid unnecessary hierarchies (shared or stored or dynamic).
Having top level dense members as dynamic lines is a good design but having sparse dynamic calc will impact retrieval performance.
its not at all advisable to make sparse members as dynamic calc but if needed we can make sparse members with very few children as dynamic calc (or dynamic calc & store). yet again its not advisable to have a dynamic calc children to a sparse stored parent as this will affect the batch calculation while aggregating parent sparse member.
And as suggested by your consultant it is feasible to make the dimension getting modified more often, as a sparse dimension as this will reduce the restructuring time (sparse restructure will take less time compared to dens restructure).
But that alone cannot be considered as factor as there are many other factors to be considered for making a dimension sparse.
- Krish

Defnining Shared members

Hi All,
I believe we cannot have a shared member above the original/base member in the dimension hierarchy but an information in the below link confused me. please refer to Figure 122 it talks about Forward Calculation References showing P100-20, P200-20 and P300-20 shared members as an example but they are defined above the base member.
http://docs.oracle.com/cd/E12825_01/epm.111/esb_dbag/frameset.htm?dcaoptcs.htm
Any help would be apprecaite...

No, there is nothing to stop you creating an outline in which the 'share' precedes the 'prototype' (though it produces a validation warning). From 11.1.2 EAS gives an option to automatically fix these for you.

Excluding Shared members from calculations

Similar Messages

Maybe you are looking for