CL_RSPLS_CR_EXIT_BASE~CHECK strange values in I_S_CHAS

[o_amon]

Hi experts!

We have a quite complex planning environment with an Aggregation Layer (AL) on top of a HCPR on top of 4 ADSO, one of them type direct update for planning: we implemented characteristic relationships with CHECK and CREATE methods by redefining superclass CL_RSPLS_CR_EXIT_BASE on that d.u. ADSO..

F4-help is working as expected. Furthermore in CREATE, additionally to E_TH_CHAS I fill a globally defined internal table for checking against it in CHECK.

Check also works fine, but…

… the planning query has two columns, one with plan data of last year (not input-ready) and one with current planning year and versions (FY/VERS e.g.: 2020/BC and 2021/BC. Checking refers to characteristics CharA and CharB in the rows.

The Problem: I_S_CHAS in method CHECK delivers characteristic pairs which don’t exist:

e.g.: Last year we planned 2020/BC+A+B, but the interface delivers (what it should not in any case), but delivers: 2021/BC+A+B and as A this year is not permitted, an error is thrown (as we definded it because this year, A+B ist not valid.

If I understand well, I don't expect new derivations from somewhere in the background in I_S_CHAS but only posted plan data or one contained in the buffer.

Any hint on what could be wrong is highly appreciated! Thank you for your help!

Kind regards, Otto

[o_amon]

HI,
thinking it over, I could imagine that SAP creates this forbiden combination in order to get a non-input-ready cell in the WB for the current planning period's column with characteristics A/B-row intersection.

I probably have a workaround for this by checking against all already existing current planning data in the ADSO in confilct with the rule, but I wonder if that is the "correct" way to proceed, i.e. only if our record
- does not show up in the check-table for permitted combinations (sign=I -> new error)
- or does show up in the check-table of already known errors (sign=E -> old error subject to correct)
I throw an error, otherwise, it is this "dummy-error"...

[gregor_dieckmann · Accepted solution]

Hi Otto,

the combinations to be checked in the CHECK method depend on the 'list geometry' of the result set, i.e. the characteristic drilled-down in rows and columns and the restricted key figures.

Assume the query is configured to show only posted data. The existing data records are read from DB, key figures values will be aggregated and then might lead to cells with non-empty values in the grid that represents the result set of the query. For some cells - empty or not - it is clear that they are not input-ready, e.g. if the corresponding structure element in the query is not input-ready. But assume a structure element is configured to be input-ready the system has to decide whether a corresponding cell in the result set - with or without an empty value - is really input-ready since all the master data and planning constraints may not allow a cell to be input-ready

- compound master data

- master data and navigation attribute relationships

- related time characteristics

- data slices

- characteristic relationships

This why e.g. for empty cells the system will call CHECK of a characteristic relationship to check whether input really is allowed. This really has nothing to do with posted data. Also posted data might not be consistent any more, e.g. if the rule of a characteristic relationship has changed.

So I the think the effect you observe is definitely ok.

It is the task of a characteristic relationship to check valid combinations, if some combinations marked as not valid is not a real error. A very simple example of such an effect: drill-down a characteristic A on one axis and the navigation attribute A__B on the other axis; this leads to many empty cells that cannot exist and the characteristic relationship for navigation attributes will detect this.

Remark.1

You can filter out these kind of messages in the query settings, cf. RSRT.

Remark 2

Buffering can be achieved as follows: set the flag N_USE_EXTERNAL_BUFFER in the constructor of your relation, cf. also the SE24 documentation of the interface and the methods contained in the interface. This buffering is more efficient than a buffer in the relations.

Regards,

Gregor

[o_amon]

Hi Gregor,

thank you very much for your quick and - as usually here - very competent and clarifying reply and help! I managed to process messages and cell-locking as desired and I am installing the buffering as explained by you.

Thank you very much,

Kind regards.

Otto