}bedrock.cube.data.copy

[wimgielis]

Describe the bug
When copying data and the source element is equal to the target element in a given dimension, data can be cleared and get lost when there is a zero out on the target.

At first, I thought that Bedrock could present this issue when source and target element are not textually the same but rather, an alias of the source is mistakenly used for the target. A zero out will then wipe out data.
Yes, this issue is present in Bedrock with this process.

But then I also tried the case when source and target are exactly equal, with a zero out. I was surprised to see that also in that case the data is lost.

To Reproduce
ExecuteProcess( '}bedrock.cube.data.copy', 'pLogOutput', 0, 'pStrictErrorHandling', 1,
'pCube', 'SYS_Parameters', 'pSrcView', '', 'pTgtView', '', 'pFilter', '',
'pFilterParallel', '', 'pParallelThreads', 0,
'pEleMapping', 'SYS_Parameters¦COGS Percent -> COGS Percent', 'pMappingDelim', '->',
'pDimDelim', '&', 'pEleStartDelim', '¦', 'pEleDelim', '+',
'pFactor', 1, 'pSuppressConsol', 1, 'pSuppressConsolStrings', 1, 'pSuppressRules', 1, 'pSuppressZero', 1, 'pIncludeDescendants', 0, 'pCumulate', 0,
'pZeroTarget', 1, 'pZeroSource', 0,
'pTemp', 1, 'pCubeLogging', 0, 'pSandbox', '',
'pFile', 0, 'pDelim', ',', 'pQuote', '"', 'pDecimalSeparator', '.', 'pThousandSeparator', ',', 'pSubN', 0
);

ExecuteProcess( '}bedrock.cube.data.copy', 'pLogOutput', 0,      'pStrictErrorHandling', 1,
	'pCube', 'SYS_Parameters', 'pSrcView', '', 'pTgtView', '', 'pFilter', '',
	'pFilterParallel', '', 'pParallelThreads', 0,
	'pEleMapping', 'SYS_Parameters¦COGS Percent -> COGS %', 'pMappingDelim', '->',
	'pDimDelim', '&', 'pEleStartDelim', '¦', 'pEleDelim', '+',
	'pFactor', 1, 'pSuppressConsol', 1, 'pSuppressConsolStrings', 1, 'pSuppressRules', 1, 'pSuppressZero', 1, 'pIncludeDescendants', 0, 'pCumulate', 0,
	'pZeroTarget', 1, 'pZeroSource', 0,
	'pTemp', 1, 'pCubeLogging', 0, 'pSandbox', '', 
	'pFile', 0, 'pDelim', ',', 'pQuote', '"', 'pDecimalSeparator', '.', 'pThousandSeparator', ',', 'pSubN', 0
);

Expected behavior
Validations on the chosen parameters should avoid data losses and abort the process as soon as possible with a suitable error message.

Screenshots
If applicable, add screenshots to help explain your problem.

Version
Latest versions

[lotsaram]

TBH I would describe this as "error between screen and keyboard."

[wimgielis]

Hello lotsaram,

I tend to agree that it is a human error but one that should be accounted for since the consequences can be quite drastic.

The code change would be very minor. There is already code for element mapping source and target:
If(sSource @='' % sTarget @='');

Just add underneath:
If(sSource @= sTarget & pZeroTarget = 1 );
sMessage = 'Source and target element cannot coincide for dimension ' | sDim | ' when a zero out on the target is done. Chosen element is ' | sSource;
nErrors = nErrors + 1;
LogOutput( cMsgErrorLevel, Expand( cMsgErrorContent ) );
#ProcessError();
EndIf;

I see code in that same process to validate the dimension name in the element mapping parameter.
Example: Scenario¦Actual -> Budget

A typo in the dimension name is captured with code.
Scennnnario¦Actual -> Budget
would be flagged. Good as this is what is expected.

To me this is also a clear PEBCAC and even less likely than a typo in the selection of elements.
Furthermore, this dimension typo does not even lead to a data loss, since TM1 will encounter errors later on in the process (chain).

In other words, when I use an element mapping Year¦2024 -> 2024 instead of Year¦2024 -> 2025
I can only hope there is a good backup and no time/data input is lost.
When variables are passed with parameters coming from a PAW dashboard it's even more likely that someone by accident chooses source year 2024 and target year also 2024, both from the dropdowns behind the action button.

BTW there were other code suggestions to this process from 4 months ago. Not sure if they have been missed since it was during Summer holidays.