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 ...
Forum Discussion
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).
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?
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 IfBut 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.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.