-
Export Function
Hi Anaplanners,
Hope you all are doing good!
I have one question regarding export. Lets say we have module dimensioned with 4 dimension . And we cannot add 4 dimension in row. I have added time dimension(Year) in Page selector.
While exporting I dont want time to be displayed in export file. Is there and possibility in achieving this.
regards,
jeevaK
-
Clear a date formatted list property.
Hello everyone.
My case is simple : For a specific client need, I have a list with date property. Each time a date is input in the module, a process is run to "save" the input in the lists properties.
Some of these properties are date formatted line items.
When the client input a date and save it, the import sends the date from the module to the list property. But when he clear it in the module and then save, the line item "Date" of the list doesn't move.
I tried to add another process that specifically target this property with a "BLANK" date, but it doesn't work.
Anyone has an idea ? Is it a specificity of the date type ?
Thanks
-
New Function To Convert Date Format to Text Format
It would be very useful to have this functionality rather than convert to numbers through DAY, MONTH, YEAR and back to text through TEXT function.
Best practice would dictate to split these functions out but this increases clutter and causes unnecessary calculations in models.
-
Melhores Práticas para Configurações de Tempo em Modelos Anaplan de Grande Escala
As configurações de tempo no Anaplan vão muito além de uma etapa inicial de configuração, elas representam uma das principais dimensões em um modelo padrão. Com exceção dos modelos do tipo Data Hub, a maioria dos módulos utiliza a dimensão de tempo, e qualquer alteração nas configurações de tempo impacta diretamente o desempenho, a usabilidade, a escalabilidade e a manutenção de longo prazo do modelo como um todo.
Em modelos de grande escala, onde o volume de dados e a dimensionalidade crescem rapidamente, adotar uma estratégia sólida para a dimensão de tempo é essencial.
Este artigo apresenta dez boas práticas fundamentais para configurações de tempo, com base no Planual e em experiências práticas de modelagem no mundo real.
1. Use o Model Calendar como Padrão
O Model Calendar deve sempre ser o padrão para a escala de tempo, salvo em casos muito específicos. Isso porque ele é dinâmico, flexível e fácil de manter ao longo do tempo.
Utilizar o Model Calendar ajuda a manter a consistência entre os módulos, reduz atualizações manuais no encerramento do exercício e evita complexidade desnecessária.
Configure a dimensão de tempo para refletir os calendários operacionais e fiscais da empresa. Esse alinhamento reduz erros de interpretação e facilita os relatórios, mantendo o planejamento aderente às necessidades do negócio.
Evite o uso de Time Ranges, exceto quando um módulo ou cálculo exigir um subconjunto de períodos não cobertos pelo Model Calendar. Usar o Model Calendar por padrão está alinhado ao princípio de construir modelos escaláveis e sustentáveis.
Fonte: Planual Regra 1.01-02
2. Aplique Time Ranges Somente Quando Necessário
Time Ranges são ferramentas poderosas para limitar os períodos que um módulo precisa calcular. No entanto, seu uso excessivo aumenta a complexidade de manutenção, exigindo ajustes manuais em mudanças de anos.
Use Time Ranges como exceção, por exemplo, para 3 anos de históricos de realizados ou meses de previsão. Também é possível criar Time Ranges com agregações distintas, como trimestres, YTD, YTG, All Periods, etc. Isso reduz o número de células e melhora o desempenho.
Sempre nomeie os Time Ranges conforme padrões que indiquem claramente seu escopo e propósito. Isso facilita a manutenção e auditorias no modelo.
Fonte: Planual Regras 1.01-06 a 1.01-08
3. Desative Subtotais (Trimestres, YTD, YTG) por Padrão
Ao usar o Model Calendar ou Time Ranges, o Anaplan ativa automaticamente subtotais como totais trimestrais.
Apesar de úteis em relatórios, essas opções podem aumentar significativamente o tamanho e o tempo de cálculo do modelo. Se um módulo não exigir explicitamente esses totais, desative-os nas configurações de tempo.
Isso evita cálculos desnecessários. Ative-os apenas em módulos que realmente dependam desses agregados.
Fonte: Planual Regra 1.01-05
4. Use a Configuração “Current Period” de Forma Estratégica
A opção “Current Period” na configuração de tempo do modelo é útil para acionar comportamentos dinâmicos em dashboards e cálculos.
Ao definir o Current Period (período atual), é possível usar filtros Booleanos como ISCURRENTPERIOD() e funções como CURRENTPERIODSTART(), comuns para destacar ou filtrar dados do mês, semana ou período atual.
Para melhores resultados, utilize um módulo SYS Time para centralizar esses Booleanos e reutilizá-los em todo o modelo. Isso torna os filtros mais fáceis de manter e atualizáveis.
Fonte: Planual Regra 1.01-03
5. Prefira PREVIOUS() ao invés de CUMULATE() em Cálculos Acumulados
Em cálculos baseados no tempo, como saldos ou balanço de inventário, os Model Builders costumam optar entre CUMULATE() e PREVIOUS().
Para modelos grandes ou longos períodos, PREVIOUS() é mais eficiente — ele avalia apenas uma célula anterior por cálculo, enquanto CUMULATE() percorre vários períodos, consumindo mais memória e tempo.
Use PREVIOUS() para construir lógica acumulativa passo a passo, por exemplo:
Estoque Final = Estoque Inicial + Entradas - Saídas
Estoque Inicial = PREVIOUS(Estoque Final)
Essa abordagem é mais escalável e fácil de depurar do que uma única função CUMULATE() extensa.
Fonte: Planual Regra 2.02-10
6. Crie um Módulo Centralizado de Tempo (SYS Time)
Lógicas relacionadas ao tempo, como “Realizado”, “Forecast” ou “Período Anterior”, devem estar concentradas em um módulo SYS Time dedicado.
Esse módulo deve ter apenas a dimensão de tempo e conter Line Items referenciados por todo o modelo.
Centralizar a lógica de tempo:
* Promove consistência
* Reduz redundâncias
* Melhora performance e reduz o tamanho do modelo
Além disso, apoia a metodologia DISCO ao manter a lógica separada de cálculos e inputs.
Fonte: Planual Regra 1.01-04
7. Evite SELECT em Períodos de Tempo
Evite usar SELECT para referenciar períodos específicos como SELECT: TIME.'Jan 24'. Isso insere valores fixos no modelo, comprometendo a flexibilidade e adaptação a novos anos fiscais.
Prefira usar flags Booleanas ou Line Items do módulo SYS Time com LOOKUP. Exemplo:
Vendas[LOOKUP: Período Selecionado]
Isso mantém suas fórmulas dinâmicas e compatíveis com rollovers automatizados. O uso de SELECT só é aceitável em estruturas globais como SELECT: TIME.All Periods.
Fonte: Planual Regra 2.02-14
8. Cuidado com Funções de Tempo em Módulos Grandes
Funções como YEARVALUE(), LAG(), OFFSET() e MOVINGSUM() são intensivas em desempenho, especialmente em módulos com várias dimensões.
Evite aninhar essas funções em uma única fórmula. Prefira dividi-las em Line items auxiliares (helper line items), facilitando a leitura, reuso e auditoria. Isso também permite ao Anaplan otimizar recálculos.
Reduzir a complexidade das fórmulas melhora a performance em modelos de alto volume.
9. Evite Escalas Diárias de Tempo, Exceto Quando Estritamente Necessário
Granularidade diária pode ser necessária em alguns processos, mas aplicá-la ao modelo inteiro ou por longos períodos (anos) aumenta drasticamente o tamanho e complexidade do modelo.
Em módulos transacionais, a data pode ser um Line Item ao invés de uma dimensão. Isso permite aplicar filtros e consolidar os dados por semanas ou meses nos módulos de saída.
Prefira isolar o tempo diário em Time Ranges curtos e aplicá-los somente onde esse nível de detalhe for realmente necessário. Sempre questione se a granularidade semanal já não atenderia à necessidade.
Fonte: Planual Regra 1.01-08
10. Evite Adicionar a Dimensão de Tempo em Módulos de Alta Densidade
Módulos com muitas linhas como dados transacionais, histórico de vendas ou preços detalhados não devem ter a dimensão de tempo, salvo quando for essencial.
Use atributos com formato de lista (como "Válido de", "Mês Efetivo") ou filtros para vincular os dados temporalmente. Isso reduz drasticamente o número de células e melhora a performance.
Adicionar tempo a listas extensas multiplica o número de células, mesmo que a maioria fique vazia. Reserve a dimensão de tempo para módulos analíticos e de planejamento, não para armazenamento bruto de dados.
Conclusão
As configurações de tempo no Anaplan são fundamentais para a eficiência e sustentabilidade do modelo. Elas impactam diretamente desde o desempenho de cálculo até a experiência do usuário.
Em modelos grandes, aplicar essas boas práticas ajuda a reduzir a carga do sistema, melhorar a clareza e facilitar a manutenção.
Comece com um calendário de modelo robusto, utilize Time Ranges apenas quando agregarem valor, centralize a lógica de tempo e evite complexidade desnecessária em módulos com alto volume de dados.
Postado no Linkedin
https://www.linkedin.com/feed/update/urn:li:ugcPost:7317553783402614788/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B1HAJ369jTnSvQR6kui3AkQ%3D%3D
-
Calculation Effort column for Classic Engine
In the world of Anaplan modeling, performance is key. Slow model calculations can be a major bottleneck, impacting productivity and decision-making. But what if you could pinpoint exactly what’s causing the slowdown? Enter the Calculation Effort column — a powerful new feature designed to help you identify and address performance issues in your model.
This innovative feature provides visibility into the computational effort required for each line item in your model, allowing you to self-diagnose problems and optimize performance. Whether you're a Model Builder, Solution Architect, or Administrator, the Calculation Effort column empowers you to take control of your model's efficiency.
In this article, we’ll explore how the Calculation Effort column works, its benefits, and how you can use it to streamline your model. From understanding its real-time updates to comparing it with traditional Model Open Analysis (MOA) reports, we’ll cover everything you need to know to make the most of this feature. Let’s dive in and discover how you can enhance your model’s performance with the Calculation Effort column.
What is the Calculation Effort column?
What does the Calculation Effort column show?
The Calculation Effort column displays the percentage of computational effort required for each line item.
Opening a model initiates the calculation of all its line items. Therefore, the opening time varies depending on model complexity and data volume.
Once opened, the Calculation Effort column shows the line items requiring the most computational resources.
Analyzing these high-impact line items against Planual and Best Practice guidelines for formulas reveals opportunities for optimization. This process can improve the overall model's performance.
When does the Calculation Effort recalculate?
The Calculation Effort column updates automatically whenever you modify a line item in the blueprint, change the formula or its dimension. It does not change the calculation effort with other user actions such as cell input.
The calculation effort column will update only to the specific line items triggered to recalculate from the action mentioned above. For line items that don't recalculate, the original calculation effort values remain unchanged.
The modified line item's calculation effort values are recalculated and reflected as a percentage. The other line item calculation efforts will then change relative to the new percentage of the modified line item.
Improving a line item's performance (lowering its calculation effort) will result in increased calculation effort for other line items, as one percentage goes down others will raise to make 100%. However, the overall calculation time of the model is still reduced. Therefore, a higher calculation effort on other line items does not mean they are slower, they are just slower relative to line item that was modified.
Here's an example:
Line Item
Calculation Time (ms)
Calculation Effort
1
3
50.00%
2
2
33.33%
3
1
16.67%
Note: Calculation Time column is not shown in the platform.
Decreasing Line Item 1 Calculation from 3 ms to 1 ms
Line item
Starting - 3 ms
Lowering to 2.5 ms
Lowering to 2 ms
Lowering to 1 ms
Line item 1
50.00%
45.45%
40.00%
25.00%
Line item 2
33.33%
36.36%
40.00%
50.00%
Line item 3
16.67%
18.18%
20.00%
25.00%
Consistently monitoring the calculation effort following each modification may reveal increases; however, this does not necessarily imply a decline in model performance. You can always re-open the model to evaluate the overall impact of any changes made.
Additionally, when a new line item is added, the calculation effort percentage of all the line items in the model will be updated.
What is the difference between M.O.A. and Calculation Effort column?
Model Open Analysis (MOA) is a report containing modules and line items along with their corresponding calculation time, similar to the Calculation Effort column. It can also show list property calculation times which the Calculation Effort column does not show.
The Calculation Effort column shows the % calculation effort of a line item, whereas Model Open Analysis shows the calculation volume in milliseconds. Both show calculation based off the line item running on a single calculation thread.
Model Open Analysis requires a case through Anaplan Support where a model copy is taken to the Anaplan Support internal tenant. The turnaround time for generating this report may take up to 10 days. In contrast, the Calculation Effort column is a built-in feature, there's no waiting period.
Results appear directly in your model blueprint after opening the model.
Benefits of using this feature
For Model Builders and Solution Architects: This feature addresses model performance issues during development.
For Administrators: It helps maintain optimal model performance.
Overall benefits: The Calculation Effort column highlights the source of performance problems, which can cause slow model opening times.
Where to find Calculation Effort in a model
You can find the Calculation Effort column in your model in two ways:
* Blueprint view
* Line Item view
Blueprint view
* Navigate to the module that you wish to work with.
* Within the module, navigate to the blueprint view.
* Once in the blueprint view, scroll to the right and you will see the Calculation Effort column beside the Cell Count.
Line Item section
* In the navigation bar, go to the Module Panel:
* Navigate to the line items section.
* To see the Calculation Effort column, scroll to the right.
Exporting to sort and find Top 10
If you want to export all the line items and their Calculation Effort columns, once you’re in the Line Items section page, just click the export as shown, allowing you to export all the line items to different formats.
How to use Calculation Effort and how it can help you
In this module, there are four lists:
* L1 Transaction ID
* SS S4 Direct Payee
* LIS_Transaction Measures
* Time (month level)
And one formula which is summing data and multiplying that summation by the summation of two other line items in a different module:
CALC Transaction Measure Lookup.Collect Measures[SUM: 'LIST L1 Transaction ID'.Booking Month] * (CALC Rep Credit Amount.Final Credit Split + CALC Rep Credit Amount.Final Credit Split[LOOKUP: 'LIST S4 Payee'.New Payee Mapping])
When the model opens, you can see the Calculation Effort is 9.996%, which means this one line item is taking almost 10% of the calculation time of the entire model.
When reviewing this formula, it breaks Planual Rule 2.02-18 Break up formulas. So if you create a line item for just the SUM, that reduces the Calculation Effort to just under 4% (3.79%).
Now, look at the second part of the calculation, you can see both conditions are coming from the same module:
(CALC Rep Credit Amount.Final Credit Split + CALC Rep Credit Amount.Final Credit Split[LOOKUP: 'LIST S4 Payee'.New Payee Mapping])
In the CALC Rep Credit Amount module, you can see it is dimensionalized by two lists (Time is not one of them): L1 Transaction ID, S4 Payee
We need to create a new line in this module for three reasons:
* This part of the original calculation does not need Time, so if you create it in this module, the number of times it is doing the calculation will be much less and therefore more efficient.
* Do the calculations in the source module and then get the final number instead of making multiple “trips” to the source module.
* If this calculation is needed for other line items/modules within the model, it is now calculating as efficiently as possible.
The new formula is:
Final Credit Split + Final Credit Split[LOOKUP: 'LIST S4 Payee'.New Payee Mapping]<br />
and will have a Calculation Effort of 0.15%.
Back to the original module, we have the SUM done, which uses the native Time dimension, but the second part of the calculation doesn’t. With that knowledge, we create a new line item (subsidiary view because we don’t need it by Time) which references the New OEG line item in Calc Rep Credit Amount. This part of the equation has a Calculation Effort of 0.20%.
Lastly, we need to multiply the SUM result by the Calc result which will result in a Calculation Effort of 1.42%.
The Calculation Effort for this line item has now decreased from 9.96% to 5.56% (3.79 + 0.2 + 0.15 (from the new line item in CALC Rep Credit Amount) + 1.42%), which is a 45% reduction in calculation effort (1 – (5.56 / 9.96)).
Conclusion
This new Calculation Effort can greatly help understand where the model calculations are and their percentage of the model opening time. Remember, when reviewing these numbers, it is best to review them when the model has just been opened. If the model has been opened and you create a new line item with logic, it is best to ensure you are the only one working on the model as other “new” line items can and will impact the calculation effort percentage.
Frequently Asked Questions
* Who can use this feature?
This feature is available to users having Workspace Admin access to the model who can review the blueprints of modules.
* Do I need to set up anything before I can use this feature?
No additional set-up required, as this feature is viewable in the blueprint and line item section views.
* Can I still request MOA reports?
MOA reports are still available, but it takes about 10 business days to get them processed. To save some time, we suggest checking out this feature first.
Please note: A Japanese version of the article can be found here:
Calculation Effort Column.pdf
Authors: Anaplan's Kenneth Privaldos (@KennethP), Model Performance Specialist, and Rob Marshall (@rob_marshall), Director of Architecture and Performance.
-
How I built it : Centralizing complex calculations
Author: Fabien Junod is a Certified Master Anaplanner and Senior Solution Architect at Autodesk.
Hello Anaplan Community,
Let me ask you a question: do you have the same complex calculation in multiple models (maybe with different dimensions) and wish you could centralize them?
In this “How I built it” tutorial, I shared exactly how to do that.
Background
In my company, we had multiple forecasting models for multiple teams. And each one had the exact same complex revenue recognition calculation. The only difference was the dimensionality.
As a result, every time we updated the revenue recognition logic, we had to change the formulas in many Anaplan models with the risk of introducing an error and having inconsistent calculations across the Anaplan ecosystem.
In this tutorial, I explain how I was able to remove the revenue calculation from the individual spoke models and centralize it in a “central engine” (another Anaplan model)
And this central engine can be leveraged by any spoke model regardless of the dimensionality. Moreover, any new model that requires the revenue recognition calculation can be connected to the central engine (with minimal effort) and immediately have it.
Key features
* Transforming the data from a dimensioned module to a flat module
* Leveraging one calculation module for multiple spoke models
* Immediately benefit from any logic change in all spoke models
https://play.vidyard.com/ZXvZg6QLmNCMLvxqgLMekx
Questions? Leave a comment!
