This content has been marked as final. Show 7 replies
Hi, pls provide info what is your original bisuness Entity hierarchy, it's not clear for me. Have you only 1 real entity?
1.You don't have to have secondary dim in PUH i'll explane what would be if it used after your answer
2. If you set User 1 as the first owner of ENTITY_MACRO INPUT noone could edit its data after starting budget process and he also couldn't just after he promotes PU. The same is related to Entity 1.1 if you set user2 as the first owner
3. Try to use standard buttom up workflow
Thank you for your answer! The original business consists in one entity (the highest level) inputing macro budget, then the process passes to a reviewer (approve/reject) and then to 3 minor entities (1,2,3) correcting its inputs. As in hiperyon the structure is
ENTITY TOTAL --> father (it sums up children 1,2,3. The real Macro Budget is inputed on ENTITY_MACRO INPUT)
entity 1.1 ---> children
entity 1.2 ---> children
entity 1.3 ---> children
ENTITY_MACRO INPUT ---> support member, out of gerarchy (where the budget is inputed at the highest level).
the process is as follow:
1.budget is inputed on * ENTITY_MACRO INPUT* , then a reviwer should approve or reject it
(a rule is then launched to distribute it on entity 1.1, 1.2., 1.3.)
2. entity 1.1, 2, and 3 have then the possibility to adjust data
3. a reviewer must approve/reject adjusted data at Entity 1.1,2,3.
this inputs happens for the same Account members, on the same version, and on the same form: account members on row, version (+ period) on the columns.
We are not able to block inputed cell, after the process is passed to an other owner. Moreover if i put User 1 owner of * ENTITY_MACRO INPUT* and User 1.1 as reviewer of the same, the process starts from the reviewer, that it is incorrect. Have you got some advices for these two problems?
thanks a lot.
Hi, try to use button-up template for your PUH where User1 is the first owner of ENTITY_MACRO INPUT and User1.1-3 are for minor Entities 1-3. Don't use secondary dim if you don't have to set different approval path (owners and reviewers) for different accounts
Then you should start budget process for all PU (ENTITY_MACRO INPUT, Entities1-3) After that all PU's will have their owners. I'm sure other users except the owners couldn't edit data If not be sure they are not provisioned with an admin role
And here are some info about approval process in planning (18.104.22.168 and above)
1.Secondary dimension helps you to set diff paths for diff combinations of entity and account (or any other dim but the only) So PU will be more granular
2. You don't have to set PUs for all entities
3. You don't have to set PUs for all accounts if secondary dim used.
4. You don't have to start budget process for all PUs used in PUH
5. You don't have to assign owners and reviewers before budget process is started. In this case all started PUs will get First path status having no owners hence anyone could edit such PUs
6. All data out of PU entities are editable for all users if they have write access (in the next we suppose that users have it)
7. All data within PU entities are editable for all users if PUs haven't started or are in the First path
8. If PU has started and has an owner data within PU can be changed by the first owner only or the person who was delegated by him. Don't use Delegate action with Out of office assistant cause the promotional path makes cycled
9. Then you use secondary dim (let say it will be accounts) and you have promoted entity1-account1 noone can edit entity1-account1 PU or even entity1 with any accounts out of PUs in your PUH
10. Admin can change all data wherever they in or out PUs
Thanks if you have read it till the end :)
many thanks to your very useful advices!
I have been now able to block cells, when the process passes from one user to another.
still got the problem of the approval process. The bottom up template seems to be inadequate to my needs:
User 1 inputs in ENTITY_MACRO INPUT that is a member of the same level of ENTITY TOTAL, but he only can 'promote' (or distribute on the contrary) to an higher level. I do need to pass the process not to an higher level, but to childrens of ENTITY TOTAL (that is a member of the same level ). How could approach it? the free format only allow me to pass the process to a reviewer that then can only: approve,reject disconnect, or promote. He is so unable to pass process,after approving data, to children of a same level member.
I thank you very much in advance!
Well, if you still use button-up template you can include ENTITY_MACRO INPUT under the Entity total parent. This is a good idea I think as it used to calculate Entity total so you just do the groupping in order to see that fact. Then you have to set ENTITY_MACRO INPUT aggregation property as ~ or even Never (^).
So what we will have:
- User1 submit data for ENTITY_MACRO INPUT then promote it, then some Approver1 approved this PU. This part is finished but Entity Total not approved as other children of Entity Total not aproved.
- User1.1-3 look at the distributed data in Entity1-3 and can change them. I don't like this step but you can do some improvement (see below)
-User1.1-3 submit changed data, then promote Entity1-3, then some Approver2 (or 1) approve these PUs
-After that Entity Total will be in Approved status automatically as all it's children PUs were approved
What i'm dislike - user1-3 change distributed data and you can't see first distributed values and what were the corrections.
If it's just you need it's allright. If you don't like it too you can change your outline to support distributed values and corrections in separate members. As one of the cases you can use Dividend1 (dynamic parent) and Divident1 dist, Divident1 corr as the children. If you have a lot of accounts use new or existing dimension for it
I just have remembered why changing distributed data bad idea in your scenario
If data in Entity1-3 has changed by Users11-3 and even approved there is a potential issue when distribution rules were executed by the mistake. All corrections will be cleared. To avoid it you should invent a workaround (for an idea see Running Rules on "Locked"/Promoted Planning Units
or you should store distributed and inputed data separately
Edited by: vvipirailo on May 25, 2012 10:36 PM