Require assistance :
I want to store price for a group of products. Instead of entering price for individual level, I want it to be stored at group level. For this, I created a key figure, with no aggregation type 'N'. As I don't want data to be visible at individual material level. In
interactive plng, I tried entering data at group level, but system gives message saying it stored, and then the price vanishes from the bucket. 
1) Is there anyway, I could save data at higher levels. 
2) A macros for performing calculation at the higher level.
 

By setting the key figure to N, you have basically told it to only store details at the lowest level. And by doing this, you can only enter or calculate values at the lowest level. I know what you need to do, but need an APO system in front of me to tell you exact settings.

I will verify this when I get in front of system, but here are the specifics as I remember them.

Set Calculation type to Average,
Set Time Based Disag type to L or N.

See if this does it for you and let me know.

Enter the number in at the higher level, and it will be the same at the lower levels as well. Just modify it consistantly at one
level.
 

The reqmt is - 
1) I store a % for every group of material, and this level is represented as characteristic /info-object. 
The key figure that stores this % need not disaggregate this value to lowest level. Infact, we do not need it to disaggregate upto lowest level. 
2) There is a cost key figure, and a macros need to be executed at this poduct group level.

I hope this clarifies. Also, in our server sizing, SAP said that data can be stored at intermediate levels in key figures, which shall reduce database size. Hence, I am trying to find a wayt to stre data in key figures at intermediate level.

Here is the way to accomplish your desired result. Set KF to N and create an aggregate at the product group level in the POS. The % number will show up at this level, but not at lower levels in this case.

We can create aggregates. But, when we use the Plng Object Structure with aggregates, all the key figures in the plng area have aggregates. We need to store only few key figures at aggregate levels.
I guess this facility should have been available at key figure level, so that we could use it only for few key figures.

Other than extra data storage, the aggregate should not be that big a deal.
I am not trying to minimize the data storage issue, but that is the main draw back. I normally try and stay away from aggregates unless I really need them.

Anyway, hope you can figure out a solution that works for you.
 

We had similar requirements to yours for selected price and percent key figures from a couple of past projects.  The  approach we took was basically consistent with the suggestion (Calc Type = A; Time-based disagg type = N).  In addition, we solved concerns on storage and display at lower levels as follows (note especially the exception handling item in 5 below):

1.  The basic requirement really is to force data entry/input/upload/use and display for selected KFs only at a given aggregate level of the hierarchy.
If this can be done, storage at lowest level does not really matter.  In fact, there is no way to prevent storage at lowest disaggregated level AFAIK even if aggregates are in place. 

2.  So the bottom line is to force data entry/input/upload/use and display at a specific aggregate level.  We did this using macros that control what can be seen/done depending on the drill-down level.  We set up macros so that:
 a.  If a user interactively drills down to a lower level, the aggregate-only KF disappears from the view (while the other KFs remain visible).
 b.  In some cases, we allowed visibility at lower levels but prevented editing at those levels.
 c.  If needed, we also structured the macros so that online (interactive) execution of macro calculations (e.g., revenue calc.)
involving the aggregate-only KFs are executed online at the required aggregate level even if the current user drill-down is at a different level.

3.  Mass uploads (from cube to LC) of the KF values are also done only at aggregate level.  The LC storage would of course disaggregate this to the lower levels using the A-type disaggregation but the important thing is that when viewed and used at the aggregate level, the value will be what was uploaded from the cube.  Other mass processing jobs using the KF are done
only at the required level as well.

4.  We used calc. type = A because in addition:
  a. we needed the lower level values to be equal to the specified aggregate level (e.g., the price at model-country where there are multiple product options (e.g. color) per model and multiple locations per country should be the same as the price for the diff. option-location combos for the given model-country); and
  b. When rolled-up at higher region level, the price should become a region average of the countries.

5.  Special case: what happens when new CVCs are added when the calculation type is A?
Note that the A-calc. type becomes tricky to manage when adding new CVCs belonging to an existing higher level (e.g., adding a color to a model or a location to a country for the next planning cycle).  The KF value of the new CVC will default to 0 so if you're not careful, this may mess up the averaging (aggregation) or the disaggregation when the KF value is reloaded
in the next cycle.  For example, 
Current cycle: Country C1 price uploaded = 100.  Resulting price at lower level locations L1 and L2 (in the same country C1) is also 100 at each location.
Next cycle: Add location L3 in country C1.  Upload C1 price = 100. 
What are the resulting prices for L1, L2, L3.  Answer: not 100 at each location because the disaggregation logic uses the previous values of 
L1=100, L2=100, and L3=0---the result (due to Calc. Type = A-verage) becomes
L1=150, L2=150, L3=0 with the average at C1 level = 100 = (150+150+0)/3 = the average of L1+L2+L3.  Note that this is very counter-intuitive from the usual proportional disaggregation of regular additive-calc. type (S,P,I) key figures.

To solve this problem, the KF values should be zeroed-out just before the job that uploads the new KF values.  If you don't care about the lower level values (i.e., you don't care if L1=150, L2=150, L3=0 as long as C1=100), you don't have zero-out as the bottom-line (top-line?) is just the aggregate C1 level value of 100.  However, you have to make sure that the aggregate average level value of 100 is maintained even after adding the new lower level CVC, especially if the KF is maintained only interactively and not by batch.  I've forgotten how our testing scenario resulted in this case but we
always refresh the KF in the beginning of the cycle (after CVC generation) so for us it was OK.  I don't know how A-type KFs will behave in this scenario when aggregates are in place so you have to test that out too.

If you impose rules so that calculations, data entry, and display at interactive and batch modes are always at a given fixed hierarchy level, then perhaps calc. type A is not necessary---just use one of the additive calculation types.  In this case you don't have to watch out for the "strange" A-type aggregation/disaggregation scenario above.  Note that aggregation to higher level will be additive though and that might not be what you want if it is a percent KF scenario.
 

Best regards,
SAP Basis, ABAP Programming and Other IMG Stuff
http://www.sap-img.com