Add New Periods To Time P Dimension-Things To Know-Help!

[slu]

Hi TM1 Gurus,

I am new to TM1, I got a request to add new time periods to our time period dimension. Our current time period is discrete, not continuous format, We have Year, QTD, YTD, then its children. Current years lasts to 2014, 2014QTD and 2014YTD. I need to add 2015-2020 to the dimension. A coworker suggests me to look at all the rules and TI proccesses associated with time period to find out whether any rule statements would be affected by adding new time period elements.

I like to get your suggestions what the best practices are to do this because there are thousands of rules and TI proccesses which might take forever for me to fully understand all and prevent any potential impacts of adding new elements to time period dimension. One thing I could think of is to check any hard-coded rule codes related to date, anything else that can help me quickly detect any potential crashes..Any hints would be helpful, thank you

[tomok]

Don't you have any system documentation that tells you what all the rules and TI's are doing? I always deliver that as part of my consulting engagements. Heaven help you if there is no documentation. Absent that all you can do is go through each and every cube rule and TI, looking for code that might be impacted by adding new dates. Most likely you won't break anything by adding new years, it's just that all the calculations, reports, etc., that rely on dates and their specific attributes may not work. What is the name of your Year dimension? For starters, look for the attribute cube for this, }ElementAttributes_Year, and see what you need to populate. After that you could use a text editor for the .rux and .pro files looking for the name of your Year dimension. I wouldn't expect this to be a comprehensive due diligence but it may help. Good luck.

[slu]

Everybody developed those rules and TI processes no longer works for the company, documentation has nothing given to me thus far. I am with the company just a few days, was given "dev" write access only right now. We only have one time period dimension name "bpmTime" (attachment). I will start with elementattribute cubes per recommendation. I have no clues about how to start TI due diligence. I wonder how to print out those rules quickly, I found Pdata folder, I also know right click rule editor window, copy and paste to a notepad, any quick way to print them all out?? Thanks

[rmackenzie]

I like to get your suggestions what the best practices are to do this because there are thousands of rules and TI proccesses which might take forever for me to fully understand all and prevent any potential impacts of adding new elements to time period dimension.

People on this board will consistently make the point about not using DIMIX and ELPAR in rules (especially time-focussed ones) exactly because of the situation you find yourself in now - being a new person and being asked to add elements to the dimension in a way that could potentially impact on existing time-series logic dependent on dimension indexing... so one thing you can check for is usage of these functions in your different rules. You could search for these strings in your rules (not TI):

Code: Select all

DIMIX('bpmTime',

or

Code: Select all

ELPAR('bpmTime',

If you find these strings then this is a warning against adding elements to the time dimension until you are absolutely sure of what you are doing. I also agree with tomok's recommendation; actually, if you find your time dimension does actually have attributes then this would be mildly reassuring.

Everybody developed those rules and TI processes no longer works for the company ... I am with the company just a few days, was given "dev" write access only right now.

Take a back-up !

[lotsaram]

Do you at least know how the time dimension was maintained in the past? Is there a "dimension worksheet" or "XDI" for bmpTime? If so then adding new years should be as easy as copying the rows associated with the last year and doing a find/replace.

As Tomok and Robin have mentioned to make sure you don't break any rules (if they were written badly with DIMIX logic) then put any new elements at the end of the dimension.

[slu]

All, we have an elementattributes_bpmTime cube, Is "midly reassuring" meant we are ok? Most of our reports' column fields (time periods) use attributes from this cube, mainly two, 'YearToDate', 'Prior Year', I spent one hour to review rule codes in }elementattributes_bpmTime cube yesterday, codes were written mostly by SUBST ('bpmTime', starting point, length) and IF conditions based on types and N vs.C of time elements such as mmm-yyyy, mmm-yyyy YTD, mmm-yyyy QTD, concatenated 'bpmtime' with YTD if condition is true. Prior year used STR and NUMR to covert 4 digit year string to numeric, then minus one. It appears that this cube is fine when adding new years.

I have not found any dimension worksheet .xdi file yet, I did 2015 manually using dimension editor window, I read threads not to mixing xdi and dimension editor window due to compiled dim and xdi are stored in different directories, one change could overwrite another, should this practice be applied in real work?? Robin, in what cases people could try to use dimix and elpar functions in a time focused dimension. DIMIX returns indexing number of a time element, it is numeric related, people use it for calculation? or combine it with DIMNM to return an element? ELPAR returns indexing (1,2,3) parent name of a time element (string), I do not fully understand why adding new years would affect this function. All replies are great, sorry I add additional inquries, let me know I should create a new topic. I highly appreciated your assistance.

[rmackenzie]

Is "midly reassuring" meant we are ok?

Sorry, mildly reassuring doesn't mean you are in the clear, but from your post on the research you have done, it doesn't sound as if you have the kind of system that will break because of indexing. Using attributes on the time dimension is a good practice and if you are looking after this system going forward then you will want to carry on with this standard.

I read threads not to mixing xdi and dimension editor window due to compiled dim and xdi are stored in different directories, one change could overwrite another, should this practice be applied in real work??

Yes, this is a common pitfall and can cause a crippling loss of confidence in a system. How you make the choice depends on how TI updates the dimensions - if TI is updating a dimension you wouldn't also use an XDI.

Robin, in what cases people could try to use dimix and elpar functions in a time focused dimension.

You might have a rule like this:

Code: Select all

['Result']=IF(DIMIX('Year',!Year)<3,1,0);

If you inserted a year in between other years then the value in the Result measure may change... any function that works with dimension indexing introduces this liability. DNEXT is another one to potentially avoid.

I do not fully understand why adding new years would affect this function.

The problem is inserted elements above or in-between existing elements. Normally, inserting new elements at the bottom of the dimension should mean that rules based on indexing wouldn't be affected. But the simple fact the using these rules is 'risky' means that many people avoid them altogether and use attributes instead.

All replies are great, sorry I add additional inquries, let me know I should create a new topic. I highly appreciated your assistance.

No worries.