Global Cell Fixing in a Planning Application (Back End) 

Use

Global cell fixing in a planning application is particularly suitable if a Web template contains multiple queries on multiple tab pages in the planning application, and these queries are closely linked but are used for different aspects of the planning application.

Goods planning in the retail environment is generally performed by planning multiple key figures in a certain logical sequence. This means for example that sales could be planned first, followed by price markdowns, goods receipt and finally the gross result. From the point of view of planning, these planning key figures are normally grouped in a logical sequence by corresponding query views on tab pages in the planning application, for example with query views for sales, price markdowns, goods receipt and the gross result. In most cases, the planned values for sales should be retained during planning on all tab pages, while the other key figures are calculated and changed. If the user is satisfied with his/her sales planning, s/he will then fix these values and plan other key figure values. These fixed sales values must remain unchanged if the user navigates between tab pages (in other words between queries) in the planning application.

To guarantee that the system does this, cell fixings must be managed by the back-end system, since all objects involved in the definition of a cell need to be considered. Global cell fixing in a planning application allows more navigation steps in a query while retaining the cells fixings as local cell fixing on the front end and retaining the fixing for a cell in multiple queries in a planning application.

Defining Cell Fixings

Cell fixings are created for the current user session and are not persisted. When the planning application is restarted, no cells are fixed any more.

Depending on the position of the cursor, a user can fix a cell, a row or a column. Only input-ready cells can be fixed. Once they have been fixed, they cannot be changed manually any more. Cells that contain aggregated values are not fixed automatically if only fixed cells have gone into them.

You can fix all cells that contribute to a subtotal for example, but the system does not automatically fix the subtotal. Manually changing this subtotal will produce an error during the next server roundtrip however.

If cells have been fixed or if cell fixings have been deleted using the corresponding option in the context menu, the next server roundtrip transports this information to the back-end system. In the back-end system, the system translates the fixings into a format that is independent of the query, thus making it possible for cells with exactly the same definition to be fixed in other queries as well. Certain other properties of the query also need to be comparable, for example the filter used and certain characteristic properties.

Criteria for Matching the Fixing Context of the Query Views

Fixed cells are managed on the back end in accordance with their fixing context. A fixing context consists of the following information:

...

       1.      The query’s effective filter, in other words the intersection of the filter in the query definition and the dynamic filter

       2.      The sequence of characteristics on the query’s axes, and the following settings:

                            a.      Result display: always, never, with more than one value.

                            b.      Using the BW hierarchy; setting for whether or not the hierarchy display is active.

We refer to these properties as the list geometry.

This basically means that the back-end server creates a fixing context when a cell is fixed. This fixing context contains the effective filter and the list geometry of the current query view. To be able to contain cell fixings of their own, all query views in a planning application must be compatible with this fixing context. If any query views in the planning application do not match – even just one - the system deletes all cell fixings.

Criteria for Matching Structure Elements of Queries

A further condition is that the definition of structure elements of queries that are based on a fixed cell must match.

The following input-ready structure elements of a query can form the basis of a fixed cell:

●      A basic key figure

●      A restricted key figure

●      A formula

Two structure elements match if all of the following properties are identical:

●      If the structure elements are basic or restricted key figures, the following properties must match:

○       The key figures must be the same.

○       The input-readiness setting must be set for both key figures.

○       The restrictions made for the key figure must be identical.

○       The disaggregation settings must be identical.

●      If the structure element is a formula, the formula definition must be identical, meaning that the formula expression edited in Query Designer is the same in terms of the operands, brackets, data functions, variables, exception aggregation used, and in terms of the sequence of operands in the formula.

Managing Cell Fixings

As explained above, the back-end system manages the fixed cells in terms of their fixing context. A cell fixing based on a basic key figure or restricted key figure is also always assigned to a real-time enabled InfoCube via the aggregation level used in the input-ready fixed cell.

A fixed cell on an input-ready formula is assigned to the InfoProvider that was used in the query definition. The fixed cells on an input-ready formula can therefore only be used in other queries if these queries were defined on the same InfoProvider.

If the user performs any of the following activities, cell fixings are retained:

●      Display the properties of the characteristics (like Key or Text)

●      Display attributes of the characteristics

●      Sort the result set by characteristic values, texts or key figures

●      Switch the row axis and the column axis

●      Expand or collapse nodes in BW hierarchies or universal display hierarchies

●      Activate and deactivate a universal display hierarchy

●      Hide/show structure elements (filter structure elements for example)

●      Drill down in a characteristic to the lowest point on the right in the rows and the furthest point inside in the columns

●      Remove a characteristic in the drilldown: at the lowest point on the right in the rows and the furthest point inside in the columns

Note that some of the operations listed above hide fixed cells. This does not undo the cell fixings however. These “hidden” cell fixings also remain active and are taken into account by the system when calculating inverse formulas and during disaggregation.

If the user performs any of the following activities, all cell fixings are deleted:

●      Change the order of the characteristics included in a cell fixing

●      Change the axis of the characteristic included in a cell fixing

●      Change the Display Result setting of the characteristic included in a cell fixing

●      Change the settings for BW hierarchies (on/off) for characteristics included in a cell fixing,

●      Change the query’s dynamic filter (by restricting the variable values without restarting the query, using the filter dialog for a characteristic from context menu option Keep Filter Value for example)

●      Change the filter using the variable screen

●      Perform a planning function or planning sequence

What this all basically means is that any query view changes that are not compatible with the cell fixing context will result in all cell fixings being lost. The system displays a list of messages with information about the incompatible settings.

Any incompatibility as described above will result in the deletion of all cell fixings in the planning application query where it occurs.

Modeling Recommendations

To make effective use of use global cell fixings in a planning application with more than one query, queries should be modeled in such a way that the cell fixings for a query are not deleted in other queries at runtime due to incompatibilities in other queries.

Accordingly, the fixing context and the filters of all input-ready queries in the Web template should match.

In a compatibility check of the fixing context, the system uses the effective filter of the other queries to calculate the intersection of the static and dynamic filters of the queries used in the Web template. For performance reasons, note that the back-end system does not check whether various definitions express the same thing. We therefore recommend always using the same modeling type.

Filters should use the same type of restrictions (a value list for example) in all queries.

If a BW hierarchy is used as a display hierarchy in a query, the same BW hierarchy should be used as the selection hierarchy in the query’s filter.

Activities

To activate the global cell fixing on the back end, you need to set a parameter in table RSADMIN. You can use program SAP_RSADMIN_MAINTAIN to do this. Set the following parameter:

OBJECT = RSPLS_PQ_BACKEND_CELL_LOCKING

VALUE = X

Once you have activated the global cell fixing on the back end, the local cell fixing will not work any more on the front end.

More Information

For more information about cell fixing, see Cell Fixing and Local Cell Fixing in a Query (Front End).