Sum between Anaplan time and custom time

Highlighted
New Contributor

Sum between Anaplan time and custom time

I have a use case where I am trying to sum from Anaplan time (days) to a custom time dimension called Cohort Time which is in months. I have a module (Attachment 1) which has number of leads per day in Anaplan time with a Cohort Time line item coming from a separate module. Worth mentioning that the months in Anaplan time and Cohort time don't match up most of the time. I am summing to a new module that is dimensioned the same as the first except Cohort Time is now replacing Anaplan time. If I just do this the formula takes, but it only gives zero values. I can get it to work if I sum into Cohort Time but still include Anaplan time and then create a separate line item without Anaplan time and SELECT: TIME.All Periods on the first line item but it creates a ton of sparsity that I'd rather not have (blueprint in Attachment 2). Is there any way to get around this need to sum into both time dimensions and then select out anaplan time?

7 REPLIES 7
Certified Master Anaplanner

Re: Sum between Anaplan time and custom time

Hi Chris,

 

Does your fake time dimension map 1:1 to Anaplan Time? If so I believe it would be sufficient to just do a LOOKUP instead of a SUM. If I am understanding the problem correctly you can add a Time (Anaplan Month) formatted Line Item that maps to the Cohort and use it as a Lookup in the Cohort dimensioned module. 

 

Thanks,

Griffin

Highlighted
New Contributor

Re: Sum between Anaplan time and custom time

Unfortunately it's not 1:1. There are multiple Anaplan Days that map to a single cohort time day and the days don't align by month either. 

Highlighted
Contributor

Re: Sum between Anaplan time and custom time

Chris,

 

Did you find a solution for your problem? 

 

I am doing a similar cohort modeling, and my question is here;

 

https://community.anaplan.com/t5/Best-Practices/Diagonal-sums-over-flat-list-dimension-on-Anaplan/m-...

 

I would appreciate any inputs you may have.

Highlighted
Master Anaplanner/Community Boss

Re: Sum between Anaplan time and custom time

@visivasa

@chris.friederic

@Griffink

Hi

This is a know issue of summing from a time dimension to a module without time, but the good news is that is can be solved

1. Create a fake list of days covering the timescale.

2. Create a module using 1. above and and map the real days to the fake days on a 1:1 (start is formatted as date)

3. You also map the Cohrt months here too

2019-01-16_09-47-42.png

4. Create a module also dimensioned by the 'fake days' (in my example I also need Products) and map the data from the real source into this module using a lookup from the above mapping module.2019-01-16_09-48-06.png

 

5. Map the data into you Cohrt Months target module using the first mapping module2019-01-16_09-38-04.png

I hope this helps

Good luck

David 

 

 

 

Highlighted
Certified Master Anaplanner

Re: Sum between Anaplan time and custom time

@DavidSmith Has there been a resolution on this? The last post was from a year and a half ago, and I am still experiencing a similar issue where I cannot sum a value based on Time dimension.

Seems that Anaplan needs to stay more on top of these bugs...

Highlighted
Master Anaplanner/Community Boss

Re: Sum between Anaplan time and custom time

@DavidEdwards 

 

I think engine is designed in such a way due to 1:1 relationship of Time period and blocks. Would be great if Anaplan can come up with something on this

Highlighted
Master Anaplanner/Community Boss

Re: Sum between Anaplan time and custom time

@DavidEdwards 

As @Misbah says, this is part of the inherent design on the Anaplan engine and the way the blocks work (and not a bug as such), so this is a very difficult area to address

It was the primary reason for the development of TIMESUM()

 

As with everything, there are a lot of areas we need to address and prioritising them is difficult.

That said, I do have "enhancements to time" as one of my big areas of investigation for next year - no promises, but I am going to look into what is possible

David