Page 1 of 1
Not Fed
Posted: Fri Jan 06, 2012 10:20 pm
by RLReyes
I have the following lines for a rule & feeder that works majority of the time. There are times when the previous period ending balance does not equal the current period beginning balance. When I do a "Check Feeders", it will return a value "not fed". Thanks in advance.
###Calculate Beginning Balance
['Beginning Balance']=N:
DB('TURNOVER',!campus,!dept,!job_codes,ATTRS('Periods',!periods,'Previous_Period'),!benefits,!status,'Ending Balance');
feeders;
['Ending Balance'] => ['Beginning Balance'];
Re: Not Fed
Posted: Fri Jan 06, 2012 10:52 pm
by David Usherwood
Your rule is taking data from the previous period, so your feeder should feed to the next period.
You've been a bit lucky in that you probably had data in most periods to make your incorrect feeder work.
Re: Not Fed
Posted: Fri Jan 06, 2012 11:07 pm
by RLReyes
David Usherwood wrote:You've been a bit lucky in that you probably had data in most periods to make your incorrect feeder work.
David - If it's an incorrect feeder, what do you suggest I use as a feeder?
Re: Not Fed
Posted: Fri Jan 06, 2012 11:29 pm
by mce
Code: Select all
###Calculate Beginning Balance
['Beginning Balance']=N:
DB('TURNOVER',!campus,!dept,!job_codes,ATTRS('Periods',!periods,'Previous_Period'),!benefits,!status,'Ending Balance');
feeders;
['Ending Balance'] => DB('TURNOVER',!campus,!dept,!job_codes,ATTRS('Periods',!periods,'Next_Period'),!benefits,!status,'Beginning Balance');
Re: Not Fed
Posted: Tue Jan 10, 2012 9:12 am
by AnthonyT
Providing that you have a "Next Period" attribute on the Periods dimension
Re: Not Fed
Posted: Tue Jan 10, 2012 10:13 am
by lotsaram
AnthonyT wrote:Providing that you have a "Next Period" attribute on the Periods dimension
If you have any sort of financial or forecasting model that requires this kind of logic then
you should have BOTH a "last period" AND a "next period" attribute end of story. Or in cases where models have a separate year and period dimension then better still a lookup string cube to store this. (Actually I wouldn't stop there but would typically have -13 to +13 offsets for year and month). To not have this is simply bad design.
Perhaps "bad design" is too strong maybe incompletely thought out, ill thought out or inexperienced would be more appropriate...
The amount of times I have audited a model to see all kinds of complicated combinations of STR, NUMBR, SCAN, SUBST to perform time shifts when a simple ATTRS or DB lookup would suffice (
and be much more efficient in terms of calculation overhead) really makes me grind my teeth.
Re: Not Fed
Posted: Tue Jan 10, 2012 12:59 pm
by RLReyes
Thanks everyone for your input & comments.
Re: Not Fed
Posted: Mon Aug 04, 2014 7:29 am
by ram123
Code: Select all
...Or in cases where models have a separate year and period dimension then better still a lookup string cube to store this. (Actually I wouldn't stop there but would typically have -13 to +13 offsets for year and month). To not have this is simply bad design
Would like to get help in writing a feeder if there are -13 to +13 offsets for the time period
I don't think there is a need to write 13 feeders (for ex: dimnm(<dimname>, dimix(<dimname>,(!<dimname>)+1).. +2, +3...so on..)
I do not have the ATTRS/ATTRN (for 'Prev Period and 'Next Period') in my model.
Help appreciated!