ChauBSD wrote:
Hi Declanr,
I don't have many experienced. But i wanna execute such as above way of your. Can you say more details problem. Why i build my own cube and how do setup TI.
Can you share me. I am try excute. I forced myself to perform.
Thank you
I don't mean offence by this but having looked at your previous posts this method could take you down a road that will cause you more hassle than it's worth, like anything when set up well it will work perfectly... but with small omissions it will provide nothing but headaches. You should investigate the "responsibility" style of application as Overflow suggested or look into getting an experienced consultant to assist.
However the basic concept of setting up a cube is that instead of using the "TM1 Applications" screen (which only allow for an approval hierarchy on 1 dim) you would use TM1 Web (or possibly perspectives if desired) and have a cube to show the workflow; it would be a simple cube containing your 2 approval dimensions; the existing 1 PLUS the year dim, and will also contain a measures dimension (measures along the lines of "Active", "In Progress", "Submitted" and "Approved" as numeric... plus a "status" as string and some extra string for the users and timestamps etc.)... I'd also normally stick your version dim in here so you can see history of who approved what and when.
Your string "status" measure would simply be used to say that if "Approved" = "Active" (numerics) then status = approved, regardless of N or C... so on and so forth.
Someone starts off populating 1's in the "active" measure for those intersections that should be completed, this allows for it to ignore intersections which contain archived elements etc.
You have a TI that takes parameters from your approval dims and puts 1's in the relevant measures accordingly (after performing IF's to see if someone else has already done it etc)... you can put rules on the security cubes to state that when an intersection is "in progress" that user is the only 1 with "write" access; normally to do this you need to create user groups on the fly that contain only the user in question... e.g. "User A" would belong to "Workflow Group - User A" etc.
Stick some nice websheets in place to launch your action buttons and show your workflow and navigate around and then job done.
That's the basics of the concepts, i'd do quite a few things on top of that to "tidy" the model but there is little point in sharing that sort of stuff until the basics are covered.
Like I said before though; the above methodology isn't tricky by any means (which is why I'm confused as to why contributor/applications still doesn't allow for multiple approval dims in 1 app) but it would need to be built by someone who can:
A/ Foresee the sorts of problems that each line of TI could cause (and fix accordingly)
B/ Build it so that it will last for more than just 1 iteration
C/ Make it look nice; in my experience unless something looks fancy then it doesn't matter whether it is good or not because they won't use it (and if you've already shown your customers contributor; despite its flaws - it looks bloody nice and I must confess I am coming around to the way of thinking that it does simple 1 dimension approval models fairly well.)
If you wish to use something like contributor/applications the hard fact is that you need to design your cubes around that plan and quite often that requires a different sort of design to what would be most user-friendly/efficient in the other tm1 interfaces.
If you'd planned that from the start you could have designed your cubes in 2 sets, 1 designed for input (e.g. with your 2 approval dims concatenated into 1) and then another set of "reporting" cubes that take the output data and are designed nicely for users to do standard good ol' fashioned slicing/dicing analysis.