Rule not correctly fed

[conflax]

Hi all,

Please can someone help me out with a rule that I cannot get to feed correctly – I have tried numerous options throughout today and it has me stumped!
I have a simple model that is calculating Earned Premium (GEP) from Gross Written Premium, using an earning profile in another cube :

Cube 1 : Budget_Allocated – stores GWP as an entered value.
Cube 2 : Budget_Earnings_Allocated reads GWP from Cube 1 and calculates a 12-month forward spread of earned premium based on a profile .

A rule then brings the GEP into Cube 1 from Cube 2. This is the rule that I cannot correctly feed.

The GEP itself works correctly and I can see the result reading into the Budget_Allocated cube but when I suppress zeroes it disappears indicating it is not fed.

I am feeding Total GWP into GEP and this is not working for future months where no GWP has been added, presumably because there is no value to feed into GEP.

Because of this I tried to come up with a feeder that would feed from prior period’s GWP to create a “rolling feeder” but this hasn’t worked either.

I attempted to push a feeder from the Budget_Earnings_Allocated cube into the Budget_Allocated cube, but this involved switching in SKIPCHECK in this cube, and I then couldn’t work out the correct feeders in that cube.

I also tried (you can laugh) creating an “Index” element and filling each cell with a 1 for all periods, and feeding that into the GEP but this also did not work.
What am I missing?

Thanks.

BUDGET_ALLOCATED RULE AND FEEDER:
#-------------------------Earnings---------------------------------------------------------------------------

['GEP','Commercial'] = n:DB('Budget_Earnings_Allocated',!Allocate,'Premium',!Cover Type Summary,!Company,!Budget Scenario,!Budget Sublevel,!LineOfBusiness,!Scheme,!Time,'All Periods');

FEEDERS;
#--------------------------Earnings---------------------------------------------------------------------------

['Total GWP'] => ['GEP'];

['Total GWP'] => DB('Budget_Allocated',!Allocate,!Cover Type Summary,!Company,!Budget Scenario,'GEP',!LineOfBusiness,!Budget Sublevel,!Scheme,ATTRS(Time,!Time,'Next Period'));


BUDGET_EARNINGS_ALLOCATED RULE (Skipcheck not switched on) :
#----- --EARNED PREMIUM------------

['Premium','Full GWP']=DB('Budget_Allocated',!Allocate,!Cover Type Summary,!Company,!Budget Scenario,'Total GWP',!LineOfBusiness,!Budget Sublevel,!Scheme,!Time);

['Premium'] =N:['Premium','Full GWP']*DB('Budget_Earnings_Profile_Simple',!Company,!Profile Type,ATTRS('LineOfBusiness',!LineOfBusiness,'Earned Premium Profile'),!Budget Scenario,!FC_Earnings_Year_Month,!Time);




Screenshot of Budget_Allocated cube view – it is the “No Cover Type” element where premium does not exist from August onwards that is not feeding in the GEP. (August itself works on here as I have manually entered a value to force feed and not yet restarted the server).

[Darkhorse]

Normal rule of thumb applies if you can see it in your cube but when suppressing zero it disappears its "pulling" the data fine

You need to look at the cube "pushing" the data I call it the chuckle brothers effect... To me to you...
From what im reading are you saying the value in the first cube is disappearing when refreshing?

Not to be funny but try breaking it down to one to one first with feeders so in one cube your asking for premium and total gwp but in the push from the feeding cube your only asking specifically for gwp, try and get it close to one to one don't try anD consolidate the lines. Take it to the nth level in your feeders one company one line one calc and see if it works then.

[conflax]

Hi,

Thanks for the reply

Taking the destination cube (budget_allocated) down to N level without suppress zeroes it works fine, suggesting as you say it is reading from the source cube (budget_earnings_allocated) correctly.

However I don't have a "push" feeder from the source cube, as Skipcheck is not even turned on in that cube. In the destination cube i've got skipcheck on, a rule that reads the source cube, and then a feeder that is only within the destination cube. Is this the problem? is it never going to work unless I have a "push" feeder from the source cube?

Thanks

[Wim Gielis]

Hi,

Thanks for the reply

Taking the destination cube (budget_allocated) down to N level without suppress zeroes it works fine, suggesting as you say it is reading from the source cube (budget_earnings_allocated) correctly.

However I don't have a "push" feeder from the source cube, as Skipcheck is not even turned on in that cube. In the destination cube i've got skipcheck on, a rule that reads the source cube, and then a feeder that is only within the destination cube. Is this the problem? is it never going to work unless I have a "push" feeder from the source cube?

Thanks

You can feed from whatever cube you like/is most appropriate. Just make sure the correct cells are fed: not too little, not too many.

[deepakjain2020]

Hi Conflax,

Below statement given in the Documentation:

"When working with inter-cube rules,
calculation statements reside in the target cube, while feeder statements always
reside in the source cube".

When we follow that, correct feeders should be written keeping Rules in mind with respect to source cube

Regards,
Deepak Jain

[declanr]

Hi Conflax,

Below statement given in the Documentation:

"When working with inter-cube rules,
calculation statements reside in the target cube, while feeder statements always
reside in the source cube".


Regards,
Deepak Jain

The documentation is not to always be trusted as an absolute.

It is often the case that the correct place to feed from is the source but certainly not always, as Wim pointed out you can feed from anywhere and it doesn't have to have anything to do with what gets pulled into the rule.

All that matters is the end result is what you want in terms of everything getting fed and not crippling your performance. "Cheat Feeders" are on occasion the best course of action.

[lotsaram]

I think your problem is simply how you are feeding gross earned premium.
['Total GWP'] => DB('Budget_Allocated',!Allocate,!Cover Type Summary,!Company,!Budget Scenario,'GEP',!LineOfBusiness,!Budget Sublevel,!Scheme,ATTRS(Time,!Time,'Next Period'));

You can't just feed the next period! Underwriting revenue is basically the same as modelling any subscription based sales model. You have a "sale" in one period from which you need to allocate revenue to a number of future periods. How many future periods and the pattern of revenue recognition depends on the policy type, it could be over 6 months, it could be over 36 months, or for special cases like farmer crop protection it could be just one month but in 13 months time. What goes for rules goes for feeders also if your rule to calculate GEP apportions policy revenue over 12 future months then you need to feed forward the next 12 months. From the feeder you posted you are only feeding ONE future period, hence your issue.

If you have a discrete time dimension then your best way to do the feeding is to have forward 12 month consolidations for each month and feed those. Setup of such consolidations should be able to be automated by TI.

The most efficient way to model the underwriting calculations is also with consolidations with consolidation weightings as per the revenue proportion per future month. If there are a lot of policy types then this can add up to quite a lot of rollups which require an automated solution to maintain but if the model is large with a lot of data and longish time horizons then it is far quicker and more efficient than using rules for the calculations (you still have to use rules but more for looking up the correct time consolidations for the policy, the bulk of the calculation can be done with consolidations.)

[conflax]

Hi all,

Thanks everyone for your input. We solved it in the short term by doing :

['Total GWP','All Periods'] => DB('Budget_Allocated',!Allocate,!Cover Type Summary,!Company,!Budget Scenario,'GEP',!LineOfBusiness,!Budget Sublevel,!Scheme,ATTRS(Time,!Time,'Next Period'));

This is a significant overfeed so not a good technical solution but works for now.

Lotsaram : some good ideas there - we do have about 10-15 profile types so there would be a lot of consolidations but I like the idea of consol based earnings as it would be much faster. I will go back and try the 12-consolidations used as feeders as this should speed things up a bit too.

Talking to our consultant he also suggested running earnings as a TI rather than rule, as in our budget model we don't necessarily need instantaneous results. This would be a possibly overcomplicated TI but it would simplify and offer flexibility for top line GWP.


Thanks for your help.