Enable data entry at a higher level when cube has 0 value

Mounil

Hi,

as the split and splat functionality goes, unless the cube 1 has some values, if we want to enable data entry at a higher level of aggregation than the cube 1 dimension itself, the data entry only becomes enabled if the cube as a value.

To resolve it, we flow a very small constant number (by opening up the calculation domains on the cube dimensions) to enable data entry or dataflow a cube 2 (that has a parent of the entity of cube 1) populated through a data reader with a constant into cube 1, or several other ways through which we can get some or the other value into cube 1 to open up data entry. There are pros and cons of each of this approach, but if the cube 1 dimensions have dimensions with a large number of active members, then often there are performance issues, or an error occurs that says tuples limits exceeded.

So, is there any solution where data entry is enabled even if the cube is blank, i.e. no constant value or any value needs to be dataflowed into cube 1. & the split and splat feature works as expected ?

Vincent Brown

If Board was able to allocate values to lower aggregations, even when everything below is null, this would be a big help for us. Even if there was only one option on how this should be done, such as an equal allocation to all members.

Currently, we are dealing with these small numbers that Mounil mentions a lot. They need to be initialized and maintained throughout the flow of the application. They can skew ratio-based calculations. Also, the user and procedures can delete them (leading to building in safeguards against this). This is quite an overhead in building our applications, that takes the focus away from the planning logic. Also, this often pops up after tools are live, and users find cells no longer entry-enabled, leading to frustration and delays with the planning process.

The only workable alternative to the small figures, is to build a data model per aggregation level, and manage synching the figures on different aggregation levels, which of course leads to complexity.

So I fully support this request!