TM1 Forum

Hi there,
I am relatively new at TM1 and work at a retailer where comp status is an important KPI - it is all based on date logic. We have built a rule driven cube to calculate whether a store is comp or not by populating with 1's and 0's. the cube has 5 dimensions. 2 of the dimensions have attributes that we are using to calculate whether a store is comp (1) or not (0) and then the 1 & 0 get populated in a separate measures dimension. The two dimensions are a stores dimension (listing of stores with open/close dates) and a time dimension where we have added the number equivalent of hte date and/or are using the dayno formula with these attributes to compare.

The rule works perfectly, but I can't figure out the feeders. From the forum it sounds like I need to potentially make sure the config file is set-up a certain way or because some of the attributes are string, potentially the feeders will need to be prompted to refresh when we update the attributes. Any guidance would be great. Let me know what other information you may need to help me with this!! It is my first post!

I've gotten this far:
['comp status'] => DB('comp status', !Version, !YearMonth, !Company, !stores, 'comp status')

cube name is comp status as well as the measure which is being populated.

Thanks so much,
Dahlia

The forum is a tremendous source of information and inspiration but there is no substitute for an initial grounding in the manuals.

I'd suggest reading/ re-reading chapter 5 of the Rules guide - improving Performance with Feeders to give you the starting points to resolving your Feeder and understand how your Rule is/ will work

Also worth noting the request for guidance link http://www.tm1forum.com/viewtopic.php?f=3&t=1037 which will assist in getting the result you want/ need quicker!

Please read (and comprehend) the request for assistance guidelines. This is a classic example where in order for others to be able to help you, you really need to provide some more information. Like is this cube only for comp status or is it also the sales reporting cube? What are the measures? (as in where is the actual leaf data as this is where all feeding has to come from).

That said. DO YOU REALLY NEED TO FEED Comp Status? My guess would be no you probably don't. This is just a lookup value, an intermediate used for a calculation. If queried AT THE LEAF level the result will be correct even if not fed, feeding only affects consolidation not leaf calculation. In the sales cube you either just incorporate base/comp/non-comp concept into the version or measure dimension OR BETTER you have a separate "Comp" dimension with elements base and comp. Base feeds comp for sales value and qty and the rule for comp is easy Comp = Base * Comp Status (assuming Comp Status is Boolean either 1 or 0). More efficient to use multiplication than to evaluate with an IF condition.

Thanks for the feedback lotssaram and Edward Stuart. I have looked at the rules guide and have many rules that fall into this category, but this is honestly our most complex situation and I'm not sure how to solve.

lotsaram - Comp status is being calculated via the rules created in the cube - it is not a lookup value and doesnt already exist in the measures. So because it is a calculation within the cube I need to feed it. When I turn skipcheck on and suppress zeroes, i then have no values, so I know it is a feeder issue. here is the first part of the rule which deals with closed stores and their status.

['Comp Status']=N: if(if(ATTRS('Stores', !Stores, 'Closed')@='',Continue,dayno(ATTRS('Stores', !Stores, 'Closed')))<>0,if(if(ATTRS('Stores', !Stores, 'Closed')@='',stet,dayno(ATTRS('Stores', !Stores, 'Closed'))+21916)>numbr(ATTRS('YearMonth', !YearMonth,
'Currentmonthend')),if(if(ATTRS('Stores', !Stores, 'open')@='',Stet,dayno(ATTRS('Stores', !Stores, 'open'))+21916)+5*91>=numbr(ATTRS('YearMonth', !YearMonth, 'Priormonthend')),0,1),0),Continue);

in the stores dimension we've loaded dates so that the DAYNo formula can read it and we add 21916 to make it comparable to how we loaded in the numerical value of a date as an attribute of our YearMonth dimension.

I'd be fine overfeeding the cube since it is dense, but since I have no other measures besides comp status (unless I create a random one), I dont know how to make that work.

I'd also be fine taking skipcheck off, but my understanding is that since we are feeding this value to other cubes it has to be on.

Thanks again!

Dahlia wrote:Comp status is being calculated via the rules created in the cube - it is not a lookup value and doesnt already exist in the measures. So because it is a calculation within the cube I need to feed it. When I turn skipcheck on and suppress zeroes, i then have no values, so I know it is a feeder issue. here is the first part of the rule which deals with closed stores and their status...

Comp Status most definitely is a lookup value as in it is something which needs to be "looked up" in order to determine another calculation. As in this case the lookup happens at leaf level then you have no need to feed this measure. A "lookup value" doesn't need to be a loaded numeric or string, it can just as well be calculated via a rule. Not all rules need to be fed. As long as somewhere else ['sales'] => ['comp sales'] then this is all you need. I don't know if I can put it any more simply than that.

You would only need to feed comp status if and only if you are using this measure to compile for reporting purposes the number of comp stores per company/region/period etc. Then in that case feeding would make sense. (mind you in this case calculating comp store status via TI and populating the cube via procedure could be an equally valid approach.)

Mr Usherwood would you care to join me in your standard refrain of "repeat after me, do not feed lookup values ..."?

Thanks lotsaram. It is the latter - we are coming up with the count of stores. So, given the rule I posted before, what would you expect that feeder to look like, if you dont mind?

Thanks!

Dahlia wrote:Thanks lotsaram. It is the latter - we are coming up with the count of stores. So, given the rule I posted before, what would you expect that feeder to look like, if you dont mind?

Thanks!

I do mind. Because you haven't as requested by both myself and Edward Stuart referred to the Request For Assistance Guidelines and included in your post(s) the requested relevant information that might possibly help others to help you. We don't have a crystal ball and we don't have unlimited time. You need to include information on the dimension structure of the cube and especially the measures and what data is physically loaded to the cube. Feeding can only come from leaf data so this is critical to answering your question.

Typically what determines a comp store status is how long the store has been trading for, was it closed for renovation, did it rebrand, etc. so the obvious answer is feed from sales! It doesn't matter if there might be a little bit of overfeeding, that's normal.

Hi, I'm sorry. I didnt mean to offend. I thought I gave you the proper information.

Dimensions are (in this order):
Version
YearMonth
company
Store
measures

the only measure in the cube is 'comp status'. Sales are not in this cube. There is no loaded data in the cube. I want to create 1's and 0's via the attributes. there are attributes - open date, remodel date, close date in the stores dimension and then the related month end date (current month end, prior month end) in the YearMonth dimension. We currently do this manually in Excel and i want to stop doing it by calculating in the cube. Sales will follow two different forecasting routes depending on the comp status of the store. So, comp status really leads sales, not the other way around. I could load some bogus amount into each period in a bonus element and have that feed comp status I think, but I was going to try to avoid that.

Here is a part of the rule:
['Comp Status']=N: if(if(ATTRS('Stores', !Stores, 'Closed')@='',Continue,dayno(ATTRS('Stores', !Stores, 'Closed')))<>0,if(if(ATTRS('Stores', !Stores, 'Closed')@='',stet,dayno(ATTRS('Stores', !Stores, 'Closed'))+21916)>numbr(ATTRS('YearMonth', !YearMonth,
'Currentmonthend')),if(if(ATTRS('Stores', !Stores, 'open')@='',Stet,dayno(ATTRS('Stores', !Stores, 'open'))+21916)+5*91>=numbr(ATTRS('YearMonth', !YearMonth, 'Priormonthend')),0,1),0),Continue);

I did research and wasn't sure if this falls under the scope of being a conditional feeder. It seems that way, but when I looked at how that would feed I thought it might look like this

['comp status'] => DB('comp status', !Version, !YearMonth, !Company, !stores, 'comp status')

which didnt work. (I think because I dont know that comp status can feed itself.)

Thanks,
Dahlia

Dahlia wrote:Hi, I'm sorry. I didnt mean to offend. I thought I gave you the proper information.

No offence. Just common sense. If you're asking for (free) help then don't make it hard for others to help you out. Do the legwork up front with as much info as possible (the RFA guide is there for a reason) and it pays off for you (hopefully!) with a quicker and better answer and less chance for any frustration on either side.

Dahlia wrote:['comp status'] => DB('comp status', !Version, !YearMonth, !Company, !stores, 'comp status')

which didnt work. (I think because I dont know that comp status can feed itself.)

Nope. This won't work. Only actual data can feed. Besides which this is a classical circular reference, which had you had any data in comp status would probably have caused a stack overflow. In any system avoid circular references.

I think my answer still stands. Feed from sales. Wherever sales is in whatever cube, feed from there. You will certainly have this at at least the grain of YearMonth/ Company/ Store. You will just have an inter cube feeder, nothing wrong with that. And no it shouldn't be a conditional feeder, you don't need that.

I don't know why you would want to populate this attribute via a rule. It's almost impossible to feed without overfeeding. Better to have a quick little TI that can be kicked off by anyone that will reset the open/closed flag for all stores whenever a date is changed. I've had the exact same scenario in multiple models, i.e., insurance policies in force, debt instruments outstanding. etc., that were all driven by dates and needing a flag across a time series. You almost can't do it without either 1) overfeeding or 2) some crazy conditional feeders which I always avoid like the plague unless I have no choice. A properly written TI would probable run in mere seconds and would free you from all this worry. Always remember the mantra, just because you can write a rule to do something, it doesn't mean you should. Rules should be saved for things that absolutely have to be dynamic. Everything else should be a consolidation or a TI.