IP: Filters, Conditions and NavAttributes in planning-functitons (copy)

[marco_simon2]

Hi experts,

maybe you can enlight me a little bit about the conclusions/difference of filters and characteristic-conditions for planning functions:

Let's say we've got a planning-function for copying actual-figures from the current year to the plan-year.

Furtheron the user should have the possibility to pass some kind of selection to the planning-function in order to define which actual data exactly should be copied (for example the user wants only to copy the actual-data for Comp_Code="GB" and only those records where the Material has the attribute 'IsPlanRelevant = "X" ' ).

So far we did this using the conditions-section in the planning-modeller. Is this the correct way?

Or should we define a (variable-based) filter which is to be used in an planning-sequence which only contains the filter and the copy-planning-function?

Unfortunatelly it seems not possible to use NavAttributes (like 'IsPlanRelevant') in the planning-function's conditions.

Thanks for your input and comments in advance,

kind regards,

Marco

[Former Member]

Hi.

As I know you can't use NavAttributes (like 'IsPlanRelevant') in the planning-function's conditions, but you can use NavAttr in the filters.

Restrict it in the filter by any variable and use data binding from the screen to pass the values to the planning sequence.

Regards.

[gregor_dieckmann]

Hi Marco,

first of all the documentation

http://help.sap.com/saphelp_nw73/helpdata/en/4c/acf4b354423b9fe10000000a42189b/frameset.htm

maybe helpful.

The filter will be used to read the data (in change mode) the planning functions needs. Depending on the parameterization of the function the system will also read reference data. These data records will be split into blocks of data records; a block is defined by constant 'block characteristics', i.e. field not to be changed in the functions. The planning function controller calls the algorithm of the planning function per block; in these calls the condition will be evaluated.

This shows that is is most efficient to put restrictions in the filter whenever logically possible. In your scenario this seems to be the case. On the other hand the system tries to 'factor' out restrictions from conditions to the filter used at run time in 'easy' cases, e.g. filter has no restriction but all conditions use the same single value; then the single value restriction can be used in the filter already.

You may use a filter with variables to run the planning function; the variables will we requested to be filled from the user when the function is executed, e.g. via button. But one can also link variables used in the query to variables used in the filter in WAD. Searching the IP how-to papers you will find some examples for these kind of techniques.

Regards,

Gregor

[marco_simon2]

Hi Gregor,

thanks for your helpful input.

You mentioned that the variables will we requested to be filled from the user when the function is executed, e.g. via button.

I tried to reproduce that but managed it only in the web-environment. Could it be that this "request for variable-values" does not exist for the BEx-Analyzer?

For some reasons we'd like to use the BEx (~Excel)-Frontend for the planning-application.

What is the best-practice-way in this case to pass the variable-values for the filter?

The usage of the "target area" might be an option, but has the disadvantage that there's no value helper.

Is the parameter 'DATA_PROVIDER_FILTER' an option in this case?

Kind regards,

Marco

[gregor_dieckmann]

Hi Marco,

the link migth be helpful

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0881371-78a1-2910-f0b8-af3e18492...

also note 1121654 might be interesting (explains how variable values can be transfered to planning functions and sequences).

The F4 help can simulated using a drop-down box, the values can then be picked using a command range, cf. the link

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d0cb1cf2-6e84-2a10-c189-aafa2f04a...

for an example (section 3.3).

Other how-to papers can be found here:

/docs/DOC-7993#section39

Regards,

Gregor

[marco_simon2]

Hi Gregor,

You mentioned:

The filter will be used to read the data (in change mode) the planning functions needs.

Is that really correct? In the case of a copy function where figures from 2011 shall be copied to 2012, will it be sufficient to have only 2011 in the filter? Or will I need a filter that covers the "from" AND "to" conditions?

Kind regards,

Marco

Btw: Thanks for your greate replies!

[Former Member]

Hi.

A filter should cover only "TO" restriction.

Regards.

[marco_simon2]

Hi Andrey,

A filter should cover only "TO" restriction.

this would be contradictory to the information from Gregor:

The filter will be used to read the data (in change mode) the planning functions needs.

But your explaination fits to my evaluations.

So, if I understood things right now, the filter is used to restrict the planning-area (and is used for determining the needed planning-locks as well). Correct?

So, in my copy-szenario: How can I define filters for the source-data?

Can this only be done using conditions (as described in my initial post)?

Since conditions do not support NavAttributes this would mean that the system would read and process a lot of data from the source (=cube with actual data) before it discards records in the writing-step (into the cube with the planning data) (where the filter allows the use of NavAttributes).

This does not sound very optimal regarding performance and runtimes, does it?

[Former Member]

Hi.

As I know a filter does 2 things:

1. reads the data

2. locks the data

If you want to copy from A to B, but you don't want to lock BOTH A and B slices, you can put in the filter only B (target restriction), so only B will be locked, and you can access in copy function to A as a reference data.

This is the simple scenario.

Your scenario is more complicated.

Since in condition you can't access to nav attributes you need to lock (restrict in the filter) the data by nav attribute in the filter.

Yes, it may lead to unwanted locks and also huge volume of the data.

Then you can access to nav attributes in FOX using, I think, ATTRV command.

Regards.

[gregor_dieckmann]

Hi Marco,

there is no contradiction with Andrey statement (which is correct).

The system takes the filter and the parameterization used of the planning function. The filter should only contain the objects you want to change. The system takes the filter and analyzes the parameterization of the function. In general this results in two DB reads, one in change mode and one not in change mode to read the reference data (in your case the source of the copy).

So the system creates two selection tables on the fly to read the needed data in change mode and the reference data; these selection will be created using the filter and the parameterization of the function. As a result you should make the filter as selective as possible to reduce the amout of data to be read and to lock only the data needed in change mode. The system determines automatically what is needed as reference data.

You confuse conditions with 'rules' of the planning function. E.g. you can say you want to copy from version 1 to version 2. You need no condition for this, the system knows that version 1 are needed as reference. A condition is not needed in this simple case. A condition is an additional restriction for 'rules', say you want to copy version 1 to version 2 only for period 001 - 006 and copy version 3 to version 4 only for periods 007 - 012. Here the restrictions for period are conditions.

Regards,

Gregor

[marco_simon2]

Hi Andrey, hi Gregor,

and once more thanks for you explaination.

I do not think that I am mixing up conditions and rules. I'm aware that conditions are only used for a restriction of the relevant records - but not for the "will be changed" flagging. But characteristics that are flagges "to be changed" seem to work as a condition as well.

(which is the reason why only one of the two option is selectable at the same moment in time).

What I imho mixed up is the expression "filter" in the planning-environment with the filtering in 'normal' reporting:

If I define a (global) filter in a query, then only data that matches this filter is read. I cannot see or use any other data.

The filter for the data-reading seems to be effected by the conditions of the planning-function.

Hence it is not that absolute as it is in the above example of the query-defintion.

I had a look at the planning-function and its data-readings from the cube (for ref-data: method GET_REF_DATA_SEL):

It seems as if the filter is used for the reference-data as well - but it is modified:

If a characteristic is flagged as "to be changed" than it (the char.) is removed from the filter and reset from the rule-definition.

 LOOP AT l_t_char_usage INTO l_s_char_usage WHERE is_chng_char = rs_c_true.
    DELETE e_t_ref_charsel WHERE iobjnm = l_s_char_usage-charnm.
  ENDLOOP.

That means, that the planning-filter indeed needs to be configured for the real-time InfoProvider, and the data-slice that needs to be locked. This filter should fit the to-be-changed/written data as close as possible.

Furtheron this filter is used for the reading of reference-data, BUT ONLY for the characteristics not closer defined in the rulesets of the planning-function. The filter is modified by the chars defined to be changed in the ruleset.

In this way your statements about "Filter is relevant for reading for source-data" would be fitting - but the filter is not used as absolute as it was defined since it is modified by the ruleset.

Can you aggree with that?