Bypass script logic section based on variable???

[houtbyr]

I have a logic script that sets a variable list of accounts based on a property:

*SELECT(%ASIS_ACCOUNTS%,"[ID]","ACCOUNT","[RATETYPE] = 'AS_IS'")

Then there is a section of the script that will copy the FC values to USD for any of these "AS-IS" flagged accounts.

*XDIM_MEMBERSET ACCOUNT=%ASIS_ACCOUNTS%
*XDIM_MEMBERSET BUSINESS=<ALL>
*XDIM_MEMBERSET CATEGORY=%CATEGORY_SET%
*XDIM_MEMBERSET CURRENCY=FC
*XDIM_MEMBERSET DATASRC=BAS(ALL_DATASRC)
*XDIM_MEMBERSET FLOW=<ALL>
*XDIM_MEMBERSET FUNCAREA=<ALL>
*XDIM_MEMBERSET GROUPS=G_NONE
*XDIM_MEMBERSET INTCO=<ALL>

*WHEN ENTITY.CURRENCY
*IS USD
*WHEN ACCOUNT.RATETYPE
*IS AS_IS
*REC(FACTOR=1,CURRENCY=USD)
*ELSE
*ENDWHEN
*ELSE
*ENDWHEN

*COMMIT

Essentially the ACCOUNT.RATETYPE check is unnecessary as it's used to scope the ASIS_ACCOUNTS variable but I didn't write this script.

After applying some recent system updates, we are now getting a failed status on the package running from Data Manager.

RUN_LOGIC:No value assigned to dimension "ACCOUNT"
model: Finance. Package status: ERROR

It seems that if NO accounts have this "AS_IS" value in their RATETYPE property, it won't be able to set the scope for ACCOUNT properly in the XDIM_MEMBERSET statement. The result, no value is assigned to dimension ACCOUNT as expected.

To resolve this issue, a test account member was created with the property set and the script completed fine.

Is there a way to bypass a section of the script based on the value of variable %ASIS_ACCOUNTS%?

For example, if %ASIS_ACCOUNTS% is blank (no accounts referenced) I can skip over this section of code to bypass the error. The logic only applies to accounts with this property, so if there are none, I don't want the code to run.

[houtbyr]

Thanks Vadim. Sorry about the primary tag, I've corrected it. (I'm new to the forum)

So, with the FOR-NEXT syntax, it won't unnecessarily duplicate the code like a traditional FOR-NEXT and essentially run the XDIM_MEMBERSET several times over and over? Does it literally run through the scoping for each record defined in the loop? It seems like there might be performance impacts to processing each record individually like that versus setting the scope and not using a FOR-NEXT loop. As long as there aren't any negative impacts, I will try that.

I'm still working on getting security access to UJKT at the moment, for now, I have to test UJKT via our basis team.

Curious to note, this logic without matching members didn't seem to error before but now ends in package error after applying support packs and hana revisions.

[former_member186338]

Sorry, but if you look on my code the statements inside FOR/NEXT will be executed ONLY once or not executed at all.

To achieve it I used special SELECT statements (please read explanation in comments!)

[former_member186338]

P.S. Don't use useless COMMIT!

[houtbyr]

It seems like the consultants execute a *COMMIT after each sub-query in the logic. I'm not sure why they did that or if not having some commits would impact later sub queries.

I'll have to look into removing the *COMMIT statements when things settle down a bit to see if there is any impact to functionality or performance.

[former_member186338]

COMMIT is absolutely useless with when/endwhen. Autocommit will happen after endwhen. You can debug yourself in ABAP 🙂