I'm building a model with drillback to transactions.
Are there ways around the following behaviors?
1. If the SUM functions used to generate the drillable amount include time, the drill to transaction fails if the source module containing the transactions doesn't contain time (but uses a line item mapping transaction date to time). The only way I've been able to get around this is to create a false time dimension (i.e. list) ... so that the SUM statement isn't based on Native Anaplan Time, but rather based on a list value (that maps in native time). Short of adding Native Time to my transaction module, is there a simpler way around this?
2. When the transaction module opens (upon drillback), the column settings are always only default. Is there any way to present a view that has custom column widths (or saved view)? I have the default view customized the way I'd like to see it, but the drill to transaction ignores it.
Solved! Go to Solution.
We had similar issues as standard 'Drill to Transaction' functionality didn't meet our requirements. So we developed a work around to replicate 'Drill to Transaction'
1) We created a new transaction module and referenced it with formula to the source module. Defined line item filters for each of the required lists on pages and formatted it as boolean. Create a VIEW and apply the line item filters.
2) Played around with 'Applies To' for new transaction module, keeping the size to minimum.
3) Create two dasboards, one with summary data and another with transaction data.
4) Connect the second dashboard with the first one using action button
5) Sync the filters of summary dashboard with transaction dashboard.
Thanks : I have already seen that link but I'm keen to hear about all sort of use cases for this.
In fact I feel it would be beneficial if there was standard pre-packaged functionality that could help model builders to easily achieve this without having to create processes, views, etc.
(For those that are familiar Essbase/Hyperion I think it would be great if Anaplan was to create a bit more functionality to match their ASO setup)
The main challenges I'm facing are :
1. The use case I'm working on means the starting module/s are very big , meaning the views/processes that are used to create the transactional reporting would cause performance issues
2. We have a separate model where we are going to import transactional module iteractions into lists and modules and create some higher level reporting with drill-down to transaction enabled
Is anyone using this sort of strategy on big extracts/reports ? I'm particularly interested in hearing if there are any potential issues/limitations with reports based on transactional modules that are huge and any other relevant hints&tips.