Forum Discussion

Krishna's avatar
Krishna
Valued Contributor
4 years ago
Solved

Data Cell Conditional Input rule ???

All - I am working on Conditional Input rule and when I create a Finance rule & attach to the Cube business rule it is working but when I am trying to call the Finance rule or extender rule using DM ...
Security
  • ChrisLoran's avatar
    ChrisLoran
    4 years ago

    So you want data to become read-only on the *source*/originating scenario after you've copied data to another scenario?  Or you want the data to be read-only on the other scenario.

    If you want the data to be read-only for forecast-type scenarios then you can do something like this:
    Select Case api.FunctionType

    Case Is = FinanceFunctionType.ConditionalInput

    If api.Time.IsFirstPeriodInYear() _
    AndAlso api.Scenario.GetScenarioType = ScenarioType.Forecast _
    AndAlso api.Account.Text(api.Pov.Account.MemberId, 1).XFEqualsIgnoreCase("FC_Readonly") Then
    Return ConditionalInputResultType.NoInput
    End If

    But if you want to lock certain intersections in the *originating*/source scenario after the data has been copied then you could have a system account (could be in a separate cube) which tracks whether a data copy has been performed or not, which would be updated using the DM job, for the originating time/scenario. Then the ConditionalInput rule could read that system account,
    e.g.   A#[DataCopyCompleted]  , and if it contains a non-zero amount then consider certain intersections blocked on that scenario.  Then some administrator could reset it on request in exceptional cases. 

ChrisLoran's avatar
ChrisLoran
Icon for OneStream Employee rankOneStream Employee
4 years ago

Hello KrishnaS
Why are you attempting to call a ConditionalInput rule from a DM job ?
The correct usage is to go to the Cube settings , and add that Finance Business rule , containing the ConditionalInput code, as one of the related Business Rules to that cube.

This is not like the HFM NoInput rules, which execute once at startup.
In OneStream a Conditional Input rule runs on-demand on a cell by cell basis, during data loads, displaying cube views etc..  Therefore it needs to be very efficient and optimised, if you need to just apply security to some specific Account/UD combinations then it would be better to use Data Access security in the cube settings.

I know this is only sample code you presented here, but also try to avoid referencing scenarios by name (use ScenarioType and its associated enumeration where possible ), never refer to time member names ( use the IsFirstPeriodInYear function, as opposed to testing for "....M1" (which won't work if a scenario is quarterly/yearly/weekly etc).

Krishna's avatar
Krishna
Valued Contributor
4 years ago

Thanks, Chris Loran Appreciate your quick response.

1. Thanks for the feedback on Scenario & Time. I will follow the same in my code.

2. The NoCOnditional Input is working when I attach to the cube.

I am trying to make a cell read only after I copy the data to another scenario. If I attach to the cube it is triggering instantly. How do I overcome? or am I missing anything?

 

  • ChrisLoran's avatar
    ChrisLoran
    Icon for OneStream Employee rankOneStream Employee
    4 years ago

    So you want data to become read-only on the *source*/originating scenario after you've copied data to another scenario?  Or you want the data to be read-only on the other scenario.

    If you want the data to be read-only for forecast-type scenarios then you can do something like this:
    Select Case api.FunctionType

    Case Is = FinanceFunctionType.ConditionalInput

    If api.Time.IsFirstPeriodInYear() _
    AndAlso api.Scenario.GetScenarioType = ScenarioType.Forecast _
    AndAlso api.Account.Text(api.Pov.Account.MemberId, 1).XFEqualsIgnoreCase("FC_Readonly") Then
    Return ConditionalInputResultType.NoInput
    End If

    But if you want to lock certain intersections in the *originating*/source scenario after the data has been copied then you could have a system account (could be in a separate cube) which tracks whether a data copy has been performed or not, which would be updated using the DM job, for the originating time/scenario. Then the ConditionalInput rule could read that system account,
    e.g.   A#[DataCopyCompleted]  , and if it contains a non-zero amount then consider certain intersections blocked on that scenario.  Then some administrator could reset it on request in exceptional cases. 

    • ChrisLoran's avatar
      ChrisLoran
      Icon for OneStream Employee rankOneStream Employee
      4 years ago

      After-thought: If going down the route of using system accounts to flag whether data has been copied or not, and you end up with more than a couple of system accounts, then I would put these into a separate accounts dimension and assign that "System Accounts" dimension to a separate cube. This prevents polluting your financial account dimension, and also creates an extra boundary from the typical end-user (non-power user) who should not see these system accounts. 

      • Krishna's avatar
        Krishna
        Valued Contributor
        4 years ago

        Thanks, Chris, for the feedback. I also found another way to lock the Cell using the Scenario Properties "No of No Input Periods" it will lock the period from inputting the data, but it is kind of maintenance for administrator.

    • Krishna's avatar
      Krishna
      Valued Contributor
      4 years ago

      The below I am trying to achieve.

      The data to become read-only on the *source*/originating scenario after you've copied data to another scenario?