Forecast, selection and aggregation level

Hi gourous,
I'm working on APO 4.1.
Forecast runs in background as following:
- Aggregation level: Sales organization / distribution channel / division / product size.
All these four characteristics are part of the characteristic combination.
- Selection ID is defined on: sales organisation / sales statut / standard - promo indicator / product size
Sales statut and standard - promo indicator are attributes of the characteristic material (sales view).
However there is forecasts on promo SKUs even if they aren't in the selection ID (standard - promo indicator as value egal to standard in the selection ID)
My question is: how is it possible? is there a conflict between the selection ID and the aggregation level?
I check the assignment of forecast profiles and there is no profil assigned on the ID selection.
Thank you for your return.
Sophie

Hi Datta,
Let me go further with my data model first.
Selection criteria:
Sales organisation = CZ01
Sales statut = active
Standard / promo = standard
Product size = A, B, C, D, E
Aggregation level:
Sales organisation
Distribution chanel
Division
Product size
What I understand of the 546079 OSS notes:
Distribution chanel and division are to be out of the aggregation level. Moreover in my case, there is only one value possible.
What I understand of the 374681 OSS notes:
The system searches for all the characteristics of the sales organisation * product size (of the aggregation level) that match the selection. At that step, APO should select only active and standard skus for CZ01 sales organisation and A, B, C, D, E product size. Afterwards the system searches for all the characteristics combinations that fit the chosen aggregation level and aggregates its values.
My question is: does APO disaggregate on the ID selection?
The characteristic combination I see in the job log are those defined on the aggregated level taking into account the sales organisation and product size restriction defined in the selection ID.
Thank you for your return.

Similar Messages

DP Disaggregation and Aggregation levels

Hi all,
I have a question regarding disaggregation and aggregation levels.
KFu2019s and disaggregation setup:
KF001:
Calculation type: I (not relevant)
Disag. Key Fig.: KF000 (not relevant)
Time-Based Disaggregation: K (not relevant)
Time-Based Disag. Key Figure: (not relevant)
KF002:
Calculation type: I
Disag. Key Fig.: Keyfigure001
Time-Based Disaggregation: P
We are now interested on the KF002. KF002u2019s disaggregation is based on KF001. I am trying to copy KF001 values to KF002 with a macro that is attached to a background job. Macro doesnu2019t do anything else than copy values from KF001 to KF002.
Background job setup:
Selection:
Sales organization: 2000AB
Location: 1000EF
Product: 1 to 2000 (consists 2000 products, including products that do not belong to above location)
Excluded values:
Customer group 1: 2500AB
Aggregation level:
Sales organization
Location
Product
Customer group 1
What I try to accomplish (through background job - mass processing):
I am trying to copy values with above setup so that the most detailed level which is Customer group 2 would have values through disaggregation. I have successfully copied values to product level, location level, sales organization level but the customer group 2 level values are not as KF001u2019s. Values are right in the SUM level, but not disaggregated right to customer group 2 level.
I get right results when I choose Customer group 2 to the aggregation level but this is not something we can do as it causes way too long runtimes. What I am also interested in is that how come the disaggregation does not work properly or does it? How can I get the disaggregation work so that I only have to select the aggregation levels which are defined in the selection and get proper results through disaggregation to customer group 2 level?
Thanks in advance,
Juha

Hello Juha,
You do not need another macro, just make the above change to your original one, and the macro should work.
Your aggregation level in the job should also be OK.
Since you mentioned that the values at detailed level are not the same as key figure 1, it sounds to me that the system did a pro rata disaggregation. Do you have the key figure 2 totally cleared out before copy? Since you're using disaggregation type 'I', it only disaggregates based on another key figure when the key figure value is initial.
So my suggestion is, you can try to change the key figure's disaggregation tyep to 'P' and check if the macro works.
Or if you have to use type 'I', you should add a step in the macro before the copy step, to initialize key figure 2 first.
To initialize a key figure, just put the row in the step, and for the 'Change Mode', select 'Initialization'.
Best Regards,
Ada

Fields in Input Ready Query and Aggregation Level

Hi All - New to IP. What if we dont include all the fields of Aggregation level in Input Ready Query.
Supose there are 4 fields in Aggregation level and we are including only two in Input Ready Query.

Hi Harry,
For a Keyfigure to be input ready, all the characteristics of the Aggregation should be filled with some values at the time of input.
The characteristics should be either in Static Filter, Dynamic Filter, Row, Column. New Selection.
If a characteristic is not there in any of the above area then it is considered to be null and query will not be input ready.
Regards,
Gopi R

Filter and aggregation level in bi 7.0

hi friends,
what is aggregation level and filters option in bi 7.0 reporting when i open reporting that options are there. i observed in filter we are creating some variables.
ple give me clarification
Thanking u
suneel.

aggregation level is for SEM IP - integrated planning and filters are same
https://www.sdn.sap.com/irj/sdn/bi?rid=/webcontent/uuid/e78a5148-0701-0010-7da9-a6c721c6112e
In the above link check for "query designer" Demo for better explaination and its use.
Hope it Helps
Chetan
@CP..

Input-ready query and aggregation level or multiprovider

Hi,
is it true that input-ready querys can only be created based on an aggregation level and not a multiprovider?
thanks.
regards
P.Rex

Hi,
Input Ready Queries can only be built on aggregation levels.
If you want to create an input ready query on a multiprovider, first create an aggreagtion level on top of this multiprovider and build your query on this aggregation level.
If you have any problems in getting the input readiness, you can always revert.
Regards,
Srinivas kamireddy.

Data storage and aggregation levels

Hi,
I want to know, in facts and dimensions, where is data stored? Is it on multiple levels of aggregation? Or it does not depend from aggregation and it is stored at the lowest level?
Thank you.

hi,
It is not stored as aggregations,the data is stored as de-normalised format and that data is picked up by BI server and process the data accordingly applying the conditions and coming to aggregations it will push down the functions applied on that to lower level.
hope it clears your doubt.
By,
KK

Selecting the Planning Level for Statistical Forecast in S&OP on HANA

Hello together,
we currently face an issue regarding the statistical forecast in S&OP on HANA:
The customer wants to implement an S&OP process containing the two steps statistical forecast (automatically calculated) and sales forecast (manually determined). The planning level of the statistical forecast should be higher than the planning level of the sales forecast, i.e. the statistical forecast is calculated on a higher planning level and then disaggregated to be an input for the manually determined sales forecast.
Since it doesn't seem to be possible to disaggregate any key figure below its base planning level we need to have the lower sales planning level as base planning level in all key figures, including the input and output key figures of the statistical forecast.
When running a statistical forecast with a defined forecasting profile, the planning level used for the forecast seems to be the base planning level of the input/output key figures defined in the forecasting profile.
However, we need to define a higher planning level for the statistical forecast in order to have a better data base for recognizing trends and sesonality. In APO DP it is possible to define the planning level for the forecast when running/scheduling the forecasting job. Is this also possible in S&OP on HANA? Can we define the planning level for the forecast in the forecasting profile or when running the forecast from the Excel AddIn? I tried to use the field "Filter" in the forecasting profile as it listed all the planning levels (as well as a lot of other things, we don't know where they come from), but the forecast was still carried out on the base planning level.
Do you have any other idea where to define the forecasting planning level that is different from the base planning level of the input/output key figures?
Thank you in advance,
Jonathan

Hi Bert,
thank you for your fast answer. I checked the forum again and found this post:
Question about Statistical Forecast
However, I don't really get how the disaggregation is meant to work; the suggestion seems to be to calculate a forecast on an aggregated level, i.e. with input and output key figure with an aggregated base planning level, and then disaggregate it "somehow".
Do you have any idea how this disaggregation might work and what other steps I have to consider?
It seems as if I'd have to define a whole bunch of new key figures and have more than one output key figure but no input key figure for the statistical forecast, which doesn't make sense in my eyes.
Actually I was looking for a solution where I can define my forecasting profile with both input and output key figure on the lower planning level and then insert the level I want the forecast to be done at either in the profile as well, or even more flexible when running or scheduling a forecast. Defining more key figures any time I need another forecasting level does not appear very comfortable. Is it meant to be like that or is there another way to reach the goal mentioned above?
Cheers,
Jonathan
Edit: The mentioned thread contains some valuable information on how to disaggregate key figures. However, the really tricky decision is how to define the disaggregation ratio.

Aggregation level transportation from dev to quality

Hi,
I have 2 aggregation levels in my mutiprovider. How can I transport these 2 aggregation levels from dev to Quality systems?

Hi,
you can collect the aggregation levels in transport connection (transaction rsa1 --> transport connection). There is a folder "Planning" and a type "Aggregation Level" (technical name: ALVL). Just select your aggregation levels and add them to a request. Please be aware that depending objects such as the multiprovider have to be transported to your quality system at same time if they are not already existing over there.
Brgds,
Marcel

CBF: Inconsistency with the forecast in charactetistics values level

Hi Guys:
I`m working with CBF, trying to make prototype, and the main problem than I have is when I release the forecast, and I check the forecast for each characteristics values, I've obtained the same forecast for different characteristics values.
EXAMPLE:
HISTORY
CH color:
V1    x
V2    y
FORECAST
CH color
V1    q
V2    q
So my question is how can I get a forecast in characteristics values level correctly?
What sould be wrong?
Thnx so much!!!
Rgds
Felipe
Edited by: felipe seydewitz on Jan 9, 2008 12:40 PM

Hi,
Have u put demand mannually at aggregated level? or Did u take forecast run at aggregated level?If u did forcast run at aggregated level,then u should have proportional factor to disaagregated at detailed level or u should take forecast run at V1, V2 level.So that u will find the difference in two Characteristic values.
Actully,currently i am working on same scenariao i.e. CBF for one STEEL PLANT.eventhough i through with CBF,means 95 % work is over,but 5 % left becz prob. with some characteristics.
Just go through following scenario...
Actually i have done the setting related to CBF in R/3 as well as in APO.We have one material having one class & some characteristic s with some dependancies.In that class i have added two more characteristic which is i have created.Eventhoug that 2 char. also having some dependencies.
Now,scenario is that whenever i am using my characteristic for CBF,then forecasting consumption is happening,but whenever i am using other characteristic for CBF,forecasting consumption not happenning.
So,have u done all CBF configuration & Do u know the solution for this issue? Kindly check this issue & let me know pls..I would really appreciate you regarding the same.
Thanks & Regards'
Sujay Joshi

Customer Exit in query on aggregation level

Hi,
I try to have variables filled with a customer exit.
The coding of the customer exit is correct, this have been tested in queries on multiproviders.
Unfortunately it is not working when these variables are used on level of aggregation levels.
What I would like to achieve:
We have some planning queries on aggregation levels. Different users can plan on the same query (and aggregation level), but not for the same set of data. Therefore the query should be restricted to the authorized values. Unfortunately we can not switch to the new authorization concept (analysis authorizations) yet, but we already need this functionality very soon.
The customer exits are the only possible option. Unfortunately it seems that the customer exits are not being executed when the variables are used in queries on aggregation levels.
The variables are not ready for input and should be filled in I_STEP = 2
Is this normal? If so, is there a work around?
Thanks in advance for quick replies!
Kind regards,
Bart

Hi,
You can debug your query by putting the break-point in your exit code and execute the query in RSRT. This way you will be able to find if your customer exit is actually being called or not. If it is being called then there can be some logical problem with your code due to which the variable values are not getting populated.
Regards,
Deepti

Aggregation Level & Selection ID in Demand Planing Background job

Folks
Whle creating a Demand Planning job in the background, we need to make few selection such as
            1. Choosing a Selection ID(One, Several & Select All) and
            2. Choosing an Aggregation level.
My question is : Doesn't the selection ID already have the aggregation level defined with in as selection ID is basically something defined or shown as Product by Location and then by Sales Org etc. Isn't this the same as the aggregation level ???
Why do we need to have Selection Id as well as Aggregation level in Background job ?
In the interactive planning do we need the aggregation Level ? If so where do we specify the same ?
TIA

The aggregation level can make a big difference to the forecast results. If you run the forecast on a high level (for example, at division level), the system aggregates the historical data (for example, the historical data of all products in a division) before it carries out the forecast. However, if you run the forecast on a low level (for example, for just one product), the system creates the forecast based on the historical data at this level, and then aggregates the forecast results in the planning screen at runtime.
The default level is the most detailed level.Here values will be disaggregated to the lowest detailed level and forecast will be executed in that level for each CVC.
say
PRD LOC     PRD_GRP
A       A1           PG1
B       A1           PG1
C       A1           PG1
A       B1           PG1
B       B1           PG1
C       B1           PG1
here forecast wil be carried out for 6 CVCs
However, in real time, as you have many CVCs, we dont follow this.
Say we specify the aggregation level as PRD_GRP and LOC.. Then system aggregates values at product group and location level..executes forecast and then disaggregates.
in this case forecst will be carried out for
PRD LOC     PRD_GRP
      A1           PG1
      B1           PG1.
Selection ID on the other hand will be used for specific selections.
Suppose if u want to execute one profile for PRDGRP PG1 at LOC A1 , you create a selection ID with this selection like in interactive planning..
How ever, if your selection is
PRD         *
PRDGRP *
LOC          *,
then , here ur aggregation level helps how to disaggregate values before running the forecast

Characteristic of selection not part of aggregation level

I am receiving the following message in my log after running a background job for my forecast. My selection profile has an exclusion so I did not add the Characteristic to the Aggregation Level. I want to run the forecast at the higher level of aggregation excluding these two criteria (Sales Regions). If I include it in the Aggregation Level it runs the forecast at the individual Sales Regions. Can an expert clarify this is ok and I am not running the forecast at the higher level including the two Sales Regions.
Thanks.

Thanks Guarav, please see my comment below.
Ok, I believe I have resolved the issue. I am going to summarize my previous process.
1.Created a Master Profile (forecast) for each Strategy I wanted to test. I would use the same Master Profile even if I changed the Parameters in the Univariate Profile.
2.Used the same forecast Activity, changing each time I changed the Strategy. Planning Job would remain the same.
3.By creating a New Activity & New Planning Job my forecast model appears to be running correctly. The only items I continue to select in the Planning Job Aggregation Level are SourceSystem and Product.
It Appears the best methodology is to set up a separate Master Profile/Univariate Profile for each Strategy & set of Parameters. A separate Activity & Planning Job should also be set up for each Strategy & set of Parameters. This would also have to be done in order to add to an overnight (monthly) Process Chain.

Cross-Aggregation-Level Selection Evaluation indicator

Hi,
Can any one explain me the meaning of the below statements in the two paragraphs. This is for "Cross-Aggregation-Level Selection Evaluation indicator" in alert monitor.
If the Cross-Aggregation-Level Selection Evaluation indicator has not been set in the SDP alert profile, only planning objects that exactly correspond to the aggregation level defined in the selection are taken into account. This means that the planning objects contain exactly the characteristics of the aggregation level. Planning objects that have additional characteristics are not taken into account.
If however, the Cross-Aggregation-Level Selection Evaluation indicator is not set in the SDP alert profile, the system takes into account not only planning objects that exactly correspond to the aggregation level of the selection but also those containing additional characteristics.
Example
If you use a selection with the aggregation level 'Product' in the SDP alert profile and set the Cross-Aggregation-Level Selection Evaluation indicator, alerts will be issued not only for this product but for the relevant location products.
Thank you.

Hi Datta,
Let me go further with my data model first.
Selection criteria:
Sales organisation = CZ01
Sales statut = active
Standard / promo = standard
Product size = A, B, C, D, E
Aggregation level:
Sales organisation
Distribution chanel
Division
Product size
What I understand of the 546079 OSS notes:
Distribution chanel and division are to be out of the aggregation level. Moreover in my case, there is only one value possible.
What I understand of the 374681 OSS notes:
The system searches for all the characteristics of the sales organisation * product size (of the aggregation level) that match the selection. At that step, APO should select only active and standard skus for CZ01 sales organisation and A, B, C, D, E product size. Afterwards the system searches for all the characteristics combinations that fit the chosen aggregation level and aggregates its values.
My question is: does APO disaggregate on the ID selection?
The characteristic combination I see in the job log are those defined on the aggregated level taking into account the sales organisation and product size restriction defined in the selection ID.
Thank you for your return.

Can a CR work only for one aggregation level and not other ?

Hi Experts,
I have a real time infocube (RTIC) over which there is a multiprovider, on top of which I have built 2 aggregation levels.
There are sequence of 2 characteristic relationships (CR's based on exit class) defined for the same RTIC.
Is it possible that the CR's be functional for one aggregation level and not in case of second aggregation level ?
Thanks and Regards,
Pankaj

Additionally let me explain the scenario in more detail:
The difference between 2 mentioned aggr levels is that of 0CALMONTH which is checked in second aggr level.
0CALMONTH is assigned as target char in first CR, hence both the CRu2019s work for input ready report built on first aggregation level and do not function with input ready report built over second aggregation level.
Therefore I wish to skip the complete execution of CRu2019s for I-R reports based on 2nd aggregation level.
As CR of type with derivation is functional only if the target char selected is not present in the aggregation level.
Please let me know if any more details are required.
Thanks,
Pankaj

Aggregation level ZFI_FINGL is locked by the Change and Transport Organizer

Dear,
After transport from a dev to prod system I get this message on the planning modeler :
"System is not set to changeable - objects are not changeable
Aggregation level ZFI_FINGL is locked by the Change and Transport Organizer"
Do you know how to fix it ?
Thanks in advance,
Thibaut

Hi,
By default the planning modeller configuration is added to the standard BEx transport (if it is not saved in $TMP). If there is not one set up then create one in the admin workbench transport connection.
If you don't use this, then you can add the objects you wish to change manually into a transport before you change them - this also works.
Cheers
Mark

Forecast, selection and aggregation level

Similar Messages

Maybe you are looking for