Forum Discussion

Koemets's avatar
Koemets
Contributor
7 days ago
Solved

IC Account copy

Need to copy an IC account data (Is IC Account = True) between scenarios, one way or another, and it seems like I can't. Tried databuffer copy - no worky. Tried api.data.calculate - same, nothing co...
Finance
  • rhankey's avatar
    rhankey
    6 days ago

    I routinely copy data with Calculate() and DM packages where IsIC=True that includes I#None.  It would be a big problem if that were not permitted.

    I cannot think of any reason why simply changing IsIC to False should "fix" the problem.

    What I think is more likely the problem is that Constraints, InUse, dimensionality or Cell Security might have been updated AFTER the source data that you are attempting to copy was created in the cube.  Put differently, tightening constraints, setting InUse=False, extending a dim, or tightening up cell security among other changes does NOT have any impact of pre-existing data in the cube that may now no longer comply with the new settings.  However, if you try to copy that no longer complient data in any way, OS will apply current settings and silently drop any destination data on the floor that does not comply.

    As I previously mentioned, it is often handy to create a Cube View that attempts to allow input to one of the destination cells you are trying to write to, so you can see if you can write, and if not, what clues Right Click/Cell Status offers.  Based on the clues you have presented, I'm pretty sure the data is being dropped when written to the destination side, for which a Cube View should offer clues.

    If doing the copy in a business rule, it is also often handy to read the right side of the Calculate() formula into a junker DataBuffer, which you can then dump out to the log to confirm if the source data you are interested in is included.

rhankey's avatar
rhankey
Contributor II
6 days ago

I'm not sure how changing IsIC=False gives joy if the account in question has IC data.

In any event, what you describe is usually a result of running afoul of constraints or InUse=False, but could also be dimensionality differences due to horizontal extensibility, or even cell security.  For something like constraints, you need to remember that thought it appears the problem is with IC data, the constraint extensibility issue could be, and often is, with a member in another dimension.

If you still can't find the problem, you can use a Cube View to attempt to input a value to a destination cell to which you are attempting to copy the data.  Other than Scenario & Origin, be sure to make sure you are writing to exactly the same members as one of the cells that is failing to copy.  You will normally find the Cube View also fails to write, at which point you can right click and select Cell Status to offer some additional clues.  If the Cube View does allow you to write the cell, then you have an issue with the business rule.

Koemets's avatar
Koemets
Contributor
6 days ago

It's not about having or not having IC data. The source account in question has data with I#None, and it needs to be copied into Forecast. But nothing can be copied by neither of methods as long as IsIC =True. Hence the wondering if this is a bug or a standard feature.

  • rhankey's avatar
    rhankey
    Contributor II
    6 days ago

    I routinely copy data with Calculate() and DM packages where IsIC=True that includes I#None.  It would be a big problem if that were not permitted.

    I cannot think of any reason why simply changing IsIC to False should "fix" the problem.

    What I think is more likely the problem is that Constraints, InUse, dimensionality or Cell Security might have been updated AFTER the source data that you are attempting to copy was created in the cube.  Put differently, tightening constraints, setting InUse=False, extending a dim, or tightening up cell security among other changes does NOT have any impact of pre-existing data in the cube that may now no longer comply with the new settings.  However, if you try to copy that no longer complient data in any way, OS will apply current settings and silently drop any destination data on the floor that does not comply.

    As I previously mentioned, it is often handy to create a Cube View that attempts to allow input to one of the destination cells you are trying to write to, so you can see if you can write, and if not, what clues Right Click/Cell Status offers.  Based on the clues you have presented, I'm pretty sure the data is being dropped when written to the destination side, for which a Cube View should offer clues.

    If doing the copy in a business rule, it is also often handy to read the right side of the Calculate() formula into a junker DataBuffer, which you can then dump out to the log to confirm if the source data you are interested in is included.

    • Koemets's avatar
      Koemets
      Contributor
      6 days ago

      Thank you. I will look into possible related constraints that you've mentioned. Will keep you posted.

    • Koemets's avatar
      Koemets
      Contributor
      6 days ago

      And you were right. It was IC constraint, set on main IC hierarchy, outside of None member. Thank you again.