Problem with BPS Fox with If-Clause and Foreach-Loop

[Former Member]

Hi folks,

I'm facing an issue with SEM-BPS Fox coding:

Operand display:

{Key Figure Name,Cost component,Version,Value type,Reposting version}

Coding:

DATA CSTCOMP TYPE 0CSTCOMP.

DATA VERS TYPE 0VERSION.

IF {ZPROVERT,#,ADB,010,1} = 0.

EXIT.

ELSE.

FOREACH CSTCOMP.

  FOREACH VERS.

   IF {0AMOUNT,CSTCOMP,VERS,070,2} <> 0.

       {0AMOUNT,CSTCOMP,VERS,070,2}=0.

   ENDIF.

  ENDFOR.

ENDFOR.

ENDIF.

The problem is as follows:

The IF-clause (with FOREACH-loop commented out) works fine.

Also the FOREACH-loop (if the IF-clause is commented out) works also fine.

But both together - it doesn't work (means no records are generated).

The reason is coming somehow from the packaging in the memory during execution (after we did some debugging here - screenshot has been attached).

The system cannot have different parameters in the IF-clause (Cost component = #, Version = ADB) compared to the parameters which result from the loop.

Do you have any idea, if this can be solved somehow?

Regards,
Christoph

[cornelia_lezoch · Accepted solution]

Hi Christoph,

your first IF statement and the statement within the foreach loop have nothing to do with each other. So it does not make any sense to try to combine them in one formula.

What is the reason of that first statement?

Do you want to exclude a certain version or customer?

Probably it would be better to do this with the filter (I think it was planning package in BPS).

regards

Cornelia

[Former Member · Accepted solution]

Dear Cornelia,

great, thank you for your quick answer!

The basic idea is as follows:

If values are available under key figure "ZPROVERT" (only under version "ADB"), then

all values under key figure "0AMOUNT" (for value type = "070" and reposting version = "2")" should be balanced out to 0 (for all versions and all cost components).

Or vice versa: If no values are available under the "ZPROVERT" related IF-statement  -> do nothing.

I think there's no way to have this functionality splitted into 2 formulas, because there's no handover of "false/true" from an IF-statement to another formular, so my approach was to solve it somehow in one FOX formula only.

The filter is not solving the issue in our case - I've tried it out.

The problem is the packaging, means how the systems deals with the FOX coding.

The system walks through all characteristic combinations of IF-statement and FOREACH-loop together (which make no sense for the IF-statement as there's no dynamic parameter inside).

But the IF-statement should be only executed one time and the then FOREACH-loop should run.

I have attached a screenshot, where you can see this packaging issue (1st and 2nd iteration...)

Do you have an idea how to deal with this?

Regards,

Christoph

[cornelia_lezoch · Accepted solution]

Hi Christoph,

havin one fox is o.k., but you should have two different loops.

I see two options:

1) create a local key figure

data check type f.

run your first IF statement and set check = 1 or check = 0 depending on the value.

then close this if.

then run a new if statement, that checks only the check-key figure.

then run the foreach statement ...

it´s more or less what you already have, just take the check of the data record into another if.

2) take the first IF away and combine the check for it with the check of the amount.

so it would be

IF {0amount ...} <> 0 AND {ZPROVERT ...} <>0.

...

regards

Cornelia

[Former Member · Accepted solution]

Hello Cornelia,

great, thank you for sharing your ideas!

I'll try this out in the next few days and feedback if it is working.

Regards,
Christoph

[Former Member · Accepted solution]

Hello Cornelia,

we have tried this out and also in addition I tried to get rid of both FOREACH loops in a different approach.

But the basic problem stays unfortunately - the check condition and the loop (or 2nd trial w/o loop statement) which should set existing values to 0 are never fulfilled at the same time (because we have different char. values).

As soon as if I comment out the IF-statement, the loop (post values to 0) is working fine.

I can also get a positive result on the IF-statement only when displaying a system message in order to check it, but only for those iterated characteristic values which fulfill the "condition" (version = ADB etc.).

So at the moment I assume, that it is not possible to have this kind of trigger construction at all in FOX coding...

So we maybe have to think about a completely different approach to find a solution for this problem...

Regards,
Christoph

[cornelia_lezoch · Accepted solution]

Hi Christoph,

whotever you did, you did something wrong and not what I wrote to you.

i created a similar code and it works just fine.

regards

Cornelia

[cornelia_lezoch · Accepted solution]

one more question

did you run your fox in traceß

are the data record that you check and the data records you want to delete within the same data package / block?

if not, then you need to change the fields to be changed, because the fox runs through each block individual.

regards

Cornelia

[Former Member · Accepted solution]

Dear Cornelia,

This is exactly the problem, in the iteration where the check is true, no data is deleted.

In the other iterations where the data could be deleted the check is not true.

But on the other hand, if I want to have it in one block, I would have to remove all these fields (0VERSION, 0CSTCOMP).

We already tried out different kind of IF-clauses and loops,

and even without the FOREACH loop (only working with discrete values), the system always tries to handle both situation (check and deletion) in two iterations.

As your coding is working as you have written - are you using 2 different key figures (LR_MENGE and LR_INTEG)?

Maybe can you also share your operands display?

That would be really great!

Regards,
Christoph

[cornelia_lezoch · Accepted solution]

Hi Christoph,

if your two data records are not in one data package, what you have to do ist the opposite of you you write - you have to have more fields to be changed.

Compare your data records. There must be another info object where the data records have different values.

Put that one into felds to be changed.

Or post your data records as they appear in the trace, so that I can see what the difference is.

For my two key figures - it is not relevant at all for which key figures the fox runs, I had to choose something that is similiar to what you have, I can not spend the time to create something that is exactly the same.

The  operand I can not post - I have deleted the example already, but it also is not relevant at all - it is just some characteristics, it does not matter what exactly the names are.

regards

Cornelia

[Former Member · Accepted solution]

Dear Cornelia,

there are almost dozens of InfoObjects where the data records have different characteristic values.

But you know, with some many operands the FOX function is a "nightmare" regarding handling.That would also mean - I have to create a FOREACH-loop, which loops on - let's say ~ 30 characteristics.

From this point of view maybe the FOX is a dead end and a function module or some real ABAP might be the only solution then...

Regards,
Christoph

[cornelia_lezoch · Accepted solution]

Hi Christoph,

well if the data record that you want to check is so very much different - is it really only one recordwhere you can identify the char that differ with one key per char?

Because then you can define that record as a reference data record.

take only the char that are really changing into your formula.

then define

data check = F.

check = {key figure,... (all the chars that remain as to be changed I reference char}

don´t write it manually, use the help functionality to define reference characteistics. I don´t really remember how it looked like in BPS, but there should be a button or something where you get help about how to build up the tuples.

this reference data record will be read for each of the packages.

otherwise yes an exit would do.

regards

Cornelia

[adamjab1]

Hi,

I have general question :

Why:

If {...} = 0.

exit.

else.

..

do something

..

endif.

instead of:

if {..} <> 0.

..

do something e.g message I'm inside "If"

..

endif.

save some bytes for The Planet

Make a simple check using message weather you will be inside this IF at all.

If not you probably don't have {ZPROVERT,#,ADB,010,1} <> 0 in the current context. Trace each package for such a value to be sure.

From my experience it can happen when ZPROVERT is a currency od quantity and you don't have unit or currency unit in your changeable operands

Regards

[Former Member]

Hello Adam,

thanks a lot for your answer!

We tried out almost everything, including your proposal.

The system is validating our IF-clause and it's working - we saw it from the messages shown.

What I have written to Cornelia before, was, that the system creates different iterations for the IF-clause and the FOREACH-loop, that's why it's not working in that way.

ZPROVERT is a quantity with a fixed quantity unit "%".

0AMOUNT is a value field, linked to the 0CURRENCY key.

I'll try to have the currency key in the changeable operands.

Maybe your hint is solving the issue somehow.

Regards,

Christoph