Technical Articles
New Model – Configuration Options
Introduction
Last year SAC introduced the new model type as successor of the classic account model. The new model brings together the measure based and the account based approach. When you create a new model there are two basic decisions that you need to take:
- Use/Not use the account dimension
- Define the structure priority between measure and account dimension
The structure priority defines is settings like aggregation, exception aggregation, scale, decimal places are determined from the measure or account dimension.
These settings lead to three model configuration types that I call Pure measure model, Pure account model and Mixed model:
Not use account dimension | Use account dimension | |
Structure priority: Measure dimension | Pure measure model | Mixed Model |
Structure priority: Account dimension | n.a. | Pure account model |
To avoid misunderstandings: The Pure Account model is a new model with structure priority = account dimension. It is not a classic account model!
In this blog, I will discuss the pros and cons of these three model configurations with the focus on Financial Planning. With SAC Release 2022.08 we migrated the SAC content Integrated Financial Planning for SAP S/4HANA with SAP Analytics Cloud to the new model and faced the question which of the three model configuration types to use. On the one hand side, this blog shall give reasoning for our decision and on the other hand provide a kind of decision matrix for customer projects that face a similar question.
In Financial Planning the G/L account plays a central role and it needs to be discussed how the G/L account relates to the account dimension. It is not given that the SAC account dimension is used for the G/L account.
You can now draw the following table:
Pure Measure Model | Mixed Model | Pure Account Model | |
Measure Dimension | Amount, Quantity, Price, … | Amount, Quantity, Price, … | Single measure Signed Data |
Account Dimension | Not used. GL Account as generic dimension | GL Accounts | GL Accounts, Quantities, Prices, … |
Structure Priority | n.a. | Measure | Account |
- In the Pure Measure Model, I define measures like Amount, Quantity and Price and model the G/L account as a generic dimension
- In the Pure Account model, I only have a single measure Signed Data and definen all G/L accounts and other measures like quantities and prices within the account dimension
- The Mixed model is similar to the Pure Measure Model, but the SAC account dimension is now used for the G/L account
In the following sections I will now describe different business scenarios and requirements and discuss how they can be implemented in the three model configurations.
In the summary I will provide an overview table that evaluates and compares the different business requirements for the three configuration options.
1. Free Cross-Calculation Structure
A free cross-calculation structure only is available when the account dimension is not used. It allows to define a complex column structure with restrictions (e.g. version/date combinations) independent from the GL account and measure dimension. In the picture below you see a table with the G/L account in the rows, two measures Amount and Activity Quantity in the columns and the additional cross-calculation structure with the members Actual/2022 and Plan/2023:
2. Drivers per G/L Account
In several situations, different drivers are needed per G/L Account
Examples
- Sales price per revenue account
- Sales deduction percentage per sales deduction account
- Account specific growth rate
- Control parameter (where to copy plan data from) per account
In a pure account model, you need to create a separate driver for each account. This multiplies out the GL accounts with the drivers and also the the respective formulas.
In a pure measure or mixed model, the drivers can be modeled as measures, independent from the account dimension. The respective formulas need to be defined only once, e.g.
DATA([d/Measures] = "AMOUNT")
= RESULTLOOKUP([d/Measures] = "AMOUNT", [d/SAP_FI_IFP_GLACCOUNT] = "41000000")
* RESULTLOOKUP([d/Measures] = "PERCENTAGE")
This formula takes the percentage from a deduction account and multiplies it with the revenue from the fix account 41000000.
3. Quantities and Units
In a pure measure or mixed model, quantity fields can be created with a dedicated data type and decimals on the database. In a pure account model, amounts and quantities are all stored with the same data type and decimals.
Quantities can have different quantity units. In a pure account model, typically different quantity accounts are created, one per unit. In a pure measure or mixed model, quantity units better can be modeled as a separate dimension, in a similar way like currencies use a unit dimension. Note that assigning a currency dimension only is possible for a measure, not for an account in the new model.
4. Sign-Flip
In S/4HANA Financials revenues are stored with a negative and cost with a positive sign. On the UI, there are different preferences:
- Show the data as they are stored on the database
- Show revenues positive and costs negative
- Show revenues and cost positive
In order to fulfill these requirements, two ways of doing a sign-flip on the UI are available:
- Global sign-flip, i.e. turn around the sign for all accounts. This is possible in all model flavors by using a calculated measure that does the multiplication with -1. The inverse formula can be used to make the calculated measure input enabled
- Sign-flip by account
- In the pure measure model this can be done via a calculated measure that reads an account attribute that stores the sign. Also here, an inverse formula can be used to make the calculated measure input enabled
- In the pure account and mixed model, the built-in account type can be used
- But note the following: If you use a calculated measure with an inverse formula in a table, the “Add Member” function and data point commenting are not supported
5. G/L Account is Optional
When you use the account dimension the following restrictions apply
- Account needs to be in the rows or columns of the table or restricted to a single value
- Thus the account cannot be left out from the table. There is no built-in #(unassigned) – logic
- In some scenarios however, e.g. when maintaining drivers, the account is not necessary at all, see the following example
6. KPI Definitions
Example 1: Sales Price = Revenue / Quantity
- In the pure account model, this can be defined on the account dimension, because revenue and quantity are modeled as accounts
- In the pure measure or mixed model, this can be defined on the measure dimension
Example 2: Gross Margin % = Gross Margin / Revenue
- In the pure account or mixed model, this can be defined on the account dimension
- In the pure measure model, this can be defined with calculated measures with restrictions to G/L accounts
Example 3: COGS per unit = COGS / Quantity
- In the pure account model, this can be defined on the account dimension, because COGS and quantity are modeled as accounts
- In the pure measure or mixed model, this can be defined via calculated measures where the amount measure is restricted to the COGS accounts and the quantity measure to the revenue account (in S/4, quantity is stored with the revenue account). In the mixed model, the special ACCOUNTLOOKUP functions needs to be used.
7. Data Import and Export
A typical SAP S/4HANA data model is measure based. E.g. amount and quantity are modeled as two measures and not as two accounts.
In a Pure account model, two import steps are necessary to load amounts and quantities from SAP S/4HANA.
In a Pure measure model and Mixed model, one step is enough.
The same applies for the data export from SAC to SAP S/4HANA.
Summary
The evaluation of the seven business scenarios can be summarized in the following table. For each of the three modeling configurations I indicated if the business requirement is support well (+), partly (0) or badly (-).
Pure Measure Model | Mixed Model | Pure Account Model | |
Free Cross-Calculation Structure | + | – | – |
Drivers per G/L Account | + | + | – |
Quantities and Units | + | + | 0 |
Sign-Flip | 0 | + | + |
G/L Account is optional | + | – | – |
KPI Definitions | + | + | + |
Data Import and Export | + | + | 0 |
Conclusion
The table in the Summary section represents a decision matrix with three alternatives in the columns and several decision criteria in the rows. However, you should not simply sum up the ratings in each column. Depending on your planning scenario you should weight the respective criteria before.
For the SAC content Integrated Financial Planning for SAP S/4HANA with SAP Analytics Cloud that we migrated to the new model with SAC Release 2022.08 all decision criteria are more or less equally important. We thus decided for the pure measure model. The account dimension is not used and the G/L account is implemented as a generic public dimension.
However, in a simple, aggregated financial statement plan where drivers and quantities do not play any role but sign-flip and KPI definitions are crucial one may come to the conclusion that a pure account model is the better fit.
Great summary of probably the most important design decision & related considerations when starting a new planning model (or redesigning/converting a model).
I wonder which approach will be the best & default way to go and was hoping SAP to provide more guidance considering future developments & investments.
On my part, I'm avoiding pure measure model because going with sign-flip on calculated measure has several showstoppers. For example: data point comments & data locking will not work.
Great document Hartmut. I believe when it comes purely on Financial planning, the account based model is the best way to go, but If you want to use only the BI solution, Measured model/Mixed model is the easiest and more convenient approach to choose.
Thanks Hartmut! I agree this is a very good summary, although could you please explain better this point about account sign flip with an example:
"But note that calculated measure with an inverse formula do not work for Add Member or cell deletion"
Also, do you know if there is a list of all the current limitations of each model (manly regarding the new model)?
Thanks
Hi Mattia,
Thanks for your input. I have updated chapter 4 and hope this became clearer now.
Best regards
Hartmut
Thanks, Hartmut! Clearer now
Hi Hartmut Koerner,
great post!I think one aspect not mentioned is the difference of loading master data into the G/L account or generic dimension.
In the case of a generic dimension that is being used for the G/L account one could load the G/L hierarchy directly from a source system such as an SAP BW/ERP. This is very easy to accomplish and any future changes to the G/L accounn hierarchy are visible in SAC without further work. Retraction from SAC to BW/ERP or other systems is also much easier as the generic dimension can be mapped 1:1.
If one decided to use an account dimension for the G/L account the hierarchy from the source system would have to be copied and maintained in SAC manually. Changed in the ERP system would then have to be manually adapted into SAC.
Or am I missing something?
Best
Fabian
Hi Fabian,
you should be able also to load a hierarchy into an SAC account dimension. As an example see content model SAP_FI_FPA_IM_S4FinancialPlan.
Best regards
Hartmut
Dear Hartmut,
thank you for this article, is helpful on decision which way to go in specific cases.
One question, when is expected end of maintenance for the Account model type in SAC?
As most of the developments and improvements are now done on New model type, I expect there is some already SAP known date.
Thank you for your reply.
Kind regards,
Václav Schreyer
Hi Vaclav,
we currently do not have an end of maintenance date for the Account model type.
While we are continuously adding more capabilities to the New Model we will also invest into making the transition from the Account model type to the New Model easier for existing customers.
Regards,
Sead
Hi Sead,
ok, thank you for your update to this topic.
I have to only admit, that a certain information on specific "end of maintanance" date was shared with one of our SAC customers from SAP side - here not sure who informed on this, so I am only curious, if it was by mistake or on purposes.
Thank you very much.
Kind regards,
Václav