Not Fed

[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'];

[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.

[RLReyes]

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?

[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');

[AnthonyT]

Providing that you have a "Next Period" attribute on the Periods dimension

[lotsaram]

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.

[RLReyes]

Thanks everyone for your input & comments.

[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!