Update work status over multiple categories, periods etc...

Question

A customer of mine discussed the work status update procedure. In BPC 4.2, you could, via the webpage, select a list of entities with multiple time periods and then update them all at once.
This would come in handy for instance if you need to set the status for the budget for instance and you need to update 12 periods all at once.
Now in v5 and up, the work status update function has not greatly improved from what it was. Customers need to update multiple categories (for instance if they close category with corporate P&L, another category , for instance the divisional P&L should also be automatically closed for further input by updating the work status) or you may want to update selected entities (that in the some cases not always follow the exact hierarchy depending on how internal responsabilities are organized)
In short, the functionality of updating work status is very limited when you need to do more than just one entity at a time.
I was wondering what solutions exist in the field as a work around to this issue ? I can think of several, but i want to understand what options the customer has.
I hope you can come up with creative ideas.
Thank you
Edwin van Geel

Answer 1

Hi Edwin,
I agree with you that the web UI for changing work status can be very tedious -- of course the push-to-children is a huge time-saver over updating 12 months (or 150 cost centers) one by one. But it would be so much nicer if we had an EVUWS or whatever, to be able to do this in a customized layout from Excel.
For many of my projects, this work status update is the only time users ever go over to the web UI, and everything else is in Excel. (Correct, I'm not a big BPF fan either.)
I haven't ever tried a custom SP to change work status. Not many things scare me, but this one scares me a little bit.
I've used data retrieved from tblFinanceLock to only allow other custom data mgmt routines (imports, exports, etc.) to run if the lock status is appropriate. It's a lot of work to get right, particularly if you want to allow something to proceed (like an export) ONLY if the entire node (and all its dependants) are locked.