About DavidSmith

I would add, but the formula from above in a module dimensioned by TIME ONLY.  This will make the formula much more efficient   David     ... View more

@jerrardli Hi No, it is not possible to combine the LOOKUPs It is best practice to split formulae anyway, but in this case it's not actually possible!   One big advantage in separating the LOOKUP, is that is can be referenced again by other formulae which a lot more efficient   I hope this helps David ... View more

@anaplan78 It's good practice to try and avoid SELECT anyway because it reduces flexibility and LOOKUPs often offer that flexibility and optimised calculations And, unintentionally, the ALM restriction helps promote best practice, so all good in my book!! David  ... View more

Hi @david This functionality has been flagged here https://community.anaplan.com/t5/Idea-Exchange/Dynamic-time-on-charts/idi-p/34630 Vote for it to bump it up the priorities list   Also, have a look at this post https://community.anaplan.com/t5/Best-Practices/Time-line-chart-not-synching-with-View/m-p/37311#M842   This may help Failing that, one workaround is to re-engineer the data to be displayed to use a time range that extended past the current calendar - Coupled with the idea in the commuity posy, this negates the need to adjust the re-publish the chart (for a few years at least) I hope that helps David ... View more

@andre.lie It is not possible to download the file from an action.  And depending on the settings when the file was uploaded, even through Anaplan connect, this might not be possible,  E.g, if the file was loaded as "private", then only the person who uploaded the file will be able to download it through Anaplan connect. See here for more details https://help.anaplan.com/anapedia/Content/Import_and_Export/Import_Data_into_Models/Overview_Private_Default_Files.htm Hope this helps David   ... View more

@kunal3591 Hi Unfortunately, Time Ranges are static, meaning the start period does not change with any other general time settings. Only the administrator can amend the name, start period and length of a Time Range David   ... View more

@jngo The dimensionality of the line item is OK I cannot see the full blueprint, but as you have Versions as a dimension, I suspect you have switchover turned on for that line and there are no actuals the corresponding.  In a calculation like this consider if you need versions in the applies to (see point 1 below)   A couple of other points 1. It would be better to put the line item into a different module (to avoid the subsidiary view).  It will help with the testing, be easier to display on dahsboards, and make it easier to audit at later date.  As part of the DISCO methodology, you should try and group line items with the same "applies to" in a separate module; it's a more logical place to house them 2. You could calculate the months spread line item with a formula like ROUND((End - Start) / 365 * 12, 0, DOWN) to ensure the amount was spread correctly   I hope that helps  David ... View more

Just to add, having a Top Level allows you to easily join data between modules without complex formulae.   Take the following example: You have a module that is dimensioned by Customers, Product and Time.  I want to summarise the data in a separate module by Customers and Time.  If I have a Top Level set on the Products list, I just need to reference the source module line item and the Top Level summary will be used to sum up all of the Products.  There is nothing else needed!   Also, whilst in most cases a Top Level Item is used, there will be occasions where if it not necessary.  Think "does it make sense to aggregate the list items"?.  Here are two examples: A list of currencies for analysis - It makes no sense to add them together A list used as a drop down to provide a choice (e.g. Yes, No). If the list is not used as a dimension in a module then it is unlikely that you will need a Top Level item I hope this helps David ... View more

@jessehhhh   It looks like you have a 1:many relationship for both Fund:Entity and Fund:Location You haven't specified if Entity and Locations are independant, or have relationships, but I guess from your question that having a module dimensioned by Funds, Entity and Location is not practical There are different ways to express this: 1. Using modules You could have a module by Funds and Enties and another by Funds and Locations.  You can then "tick" the relevent entries 2. Using numbered list hierarchies (as Rob mentioned) You can also create hierarchies using Funds as a parent and then assign Entities as children (repeat for Locations) 3. Depending on the relationship between Entity and Location is might be possble to create a combined hierarchy with all three, but that could get a little complex to manage   If you can post the "downstream" requirements we may be able to refine the advice     David   ... View more

@LipChean_Soh Sorry, maybe should have been clearer - You format a line item to the same list that the SELECT function is referencing.  You then use a LOOKUP function referencing the new formatted line item David ... View more

Great points, and I absolutely agree. The transformation between modules is key to good model design and it is what makes Anaplan so special; the ability to only hold the relevant dimensionality when required. Visualisation for multi dimensional modules is tricky, so I, to always try and visualise the relevant dimensions when    I would also recommend using a System module (from D.I.S.C.O.) to hope the mappings and visualise this in the middle (as below) You can even undock (or float) the modules to help with the visualisation   And if you are stuggling to understand if it should be a SUM or a LOOKUP, use the following phrase when comparing the lists of the source and system module dimensions. If the Source is the Same, it's a SUM!!    One final point on SELECT.  I would also recommend using a formatted line item rather than a hard coded SELECT for detailed items.  This gives you the flexibility to change the SELECT should the requirements change without needing to find all of the occurences within line item formulae.  The exceptions are Versions and Top Level items but for all other SELECTs, use a formatted line item in a central "global" assumptions module   David ... View more

@mohammad.husa There are some obvious questions posed here, but I'll try and articulate some options   The first question is does there need to be an "input" currency and a "display" currency.  If for downstream calculations you need to maintain the "input" currency then it will be best to have a line item holding that value associated with the data entry You'll need a separate line item to hold the "display" currency. and another to calculate the entered value to the display currency as appropriate   I don't think it will be feasible to have a page selector by currency without holding all of the currency conversions in one module You could have a list with two items "input" and "display" and toggle between the two and publish the formatted line item for the display currency you could then recalculate the  line item to show the input or display value   Without more details it is hard to give specific advice, but if you need to convert line item calculations into currency conversion, you will need to use a line item subset and then have a module with that on which to perform the conversion   I hope that helps for now.  If you post more specific requirements we'll be able to give more directed advice David   ... View more

@daiju.muto Take at look at these https://community.anaplan.com/t5/Shared-Best-Practices/Calculating-levels-in-a-hierarchy-for-dashboard-filtering/ta-p/33567   https://community.anaplan.com/t5/Modeling/Configuring-a-filter-for-nodal-values/td-p/32478   They might help you for your use case David ... View more

thank you for the comments, and you will be pleased to know that we are looking to add this and "connected planning" aspects to the training ... View more

@mjpearlman I agree that we often see much more complex formulae; I have spent many a day trying to understand and optimise horrible formulae.  3 pages is quite short! I've seen a 50 page formula.   There is no easy way to break it down, but my advice would be as follows:   1. Copy the formula to Word or Excel, for analysis. I hate myself for saying that, but often it is easier to split out the elements of the formula.  Y   2.  Look repeated expressions. From above, using FIND to highlight repeated words/expressions works well. These are candidates for splitting into separate line items.  We often see the same parts of formulae repeated. eg.  IF X then a / b * c ELSE IF Y THEN  a / d * c ELSE 1   Here a * c is common to both conditions and therefore can be split out and referenced.  So create a new line item = a * c and the formula becomes: "new line item" / IF X THEN b ELSE IF Y THEN d ELSE 1   or even better split that into two create another line item =   IF X  THEN  b ELSE IF Y THEN d ELSE 1 The original formula then is: "new line item" / "another line item"   3.  Break out conditions when there are multiple IFs.  In a lot of cases, these can often be replaced by lookups (especially when IF(ITEM... is involved), but splitting out the various conditions makes it easier to de-bug and test and well as improving performance   4. Look for "patterns, variables and parameters".  We often see the parts of a formula that follow similar strucutres and have numeric values as forms of parameters, e.g *3, *4, *5.  These can often be split out and reconfigured to be more efficient   Also remember that if you do split out the line items, it is unlikely that you will need the summary options turned on, so the cell count of the additional line items can be minimised I hope that helps David ... View more