Changing Numbers in Forecast Cube after Manager Submission

[gatorfe]

Once the budget data has been submitted by a sales manager then the sales person is not able to edit the data.  Is this a setting that can be turned on and off for a cube.  I have a Budget and Forecast Cube in the planning program.  Since the data was submitted by the planning manager the sales person can't update any more numbers in their customers Budget or Forecast Cube.  For the Budget Cube that is fine because those numbers should not change but once a year but for the Forecast Cube that's not good because I want to change those numbers every quarter.  Any insight would be greatly appreciated.  Thanks in advance for your time. 

[SomeClown]

No, this is not a cube setting.  It's application level.

You could always create two apps, one budget, one forecast (a common practice).

[Extirpator]

gatorfe,

We advise our field to never use the submit button. If they do submit and you need to unlock it, you must GTP and reset the workflow state to something other than locked. Unfortunately, GTPing while users are in the application will cause them to lose unsaved data.

Consider the following option. When the annual budget is done, make the Budget cube read-only from the Contributor Administration Console:

• Development > Access Tables and Selections > Access Tables...
• Select the P&L Accounts D-List (for example) and the Budget cube, click Add.
• The dimension/cube will show up as an access table in the bottom left pane. Select it and press Edit.
• Change the Access Level to READ and click Add.
• In the bottom pane, it will show a READ Access Level for <<ALL>> P&L Accounts.
• OK.
• Save.
• GTP.

The Forecast cube can still be updated, but the annual budget is essentially locked (read only). This requires the single GTP when you wish to lock the Budget, so make sure nobody is in the application when you GTP.

Extirpator

[craig_karr]

I would say build one forecast model and one budget model as someclown suggested, or if it is inconvenient for some reason to have two applications, make use of imported access tables that is automatically imported by a macro on a daily or hourly basis at and lock the budget data by importing access tables on the budget cube with the elist included. By doing that you can "lock" the budget data for individual elist items while keeping the forecast data writeable.

It is possible to trigger this lock from contributor by using a flag and then create the imported access table based on that flag from the publish container

[SomeClown]

If they do submit and you need to unlock it, you must GTP and reset the workflow state to something other than locked.

One correction here: the reviewer node for an elist item can always Reject the child node which unlocks the elist item.  This would not require a GTP (also a common practice). 

You do need to ensure your elist item has a user assigned with Review rights at the appropriate level for this to work.

[Extirpator]

Thanks SomeClown,

Since we don't use Submit, I forgot that other way of unlocking the submitted nodes.

Why do you and craig_karr favor the two applications? It seems that would require maintenance of two e.Lists and two rights files. Any changes to the underlying model would require synching and GTPing both applications each time. Data would need to be moved from one app to the other once the budget is complete. Actuals, if used in the budgeting and forecasting process, would need to be linked into both applications.

I agree that all of these steps are not technically difficult; however, one model with the Budget / Forecast dimension seems easier to maintain, update, and data can be internally linked until the budget is locked. Comparisons of budget vs. forecast can be a calculation within the D-List.

While both versions have their merits, I am wondering if I am missing something when others are recommending separate models. The primary advantage I can see of two separate models is to capture the budget and not have it change at all, even in the event of organizational shifts (which the forecast would probably adjust for).

Thanks for your feedback!
Extirpator

[SomeClown]

1 - Forecast and Budgeting can occur at different levels, e.g. budget at a retail store level, but forecast at a district level
2 - Different users for different apps (forecasting might not be done by budgeting users)
3 - Different processing cycles - some clients have budgeting and forecasting cycles that overlap which complicates app management
4 - It's faster - performance curve for Contributor apps is non-linear - two smaller apps are going to process faster than one larger app, both for end-user experience and administrative tasks (unless the apps are very very small)
5 - Most clients find it easier to manage gatorfe's issue by having two apps as it's pretty straightforward.  Not using the Submit button prevents the use of workflow management to track the entry of numbers, a challenge when you have multiple apps with hundreds of users.

[craig_karr]

I wouldn't say that I favour having two models instead of one. As you say two models tends to be more heavy on administration so I usually try to avoid two or more models if it is possible to build just one. Further one obstacle with more models is that you usually end up having to to run admin links between them and still the data is out of sync. And the users often find it more convenient to just have one model.

I think that you have to evaluate pros and cons with more than one model in each separate case and then decide what to do, given that it is actually possible to meet the customer's demands with only one model.

[Extirpator]

SomeClown and craig_karr,

Thank you both for your feedback, both from the program performance standpoint and the real-world considerations.

Extirpator