Get Started with the New Model Type

Measures in SAP Analytics Cloud Models

The main difference between the model types is how they handle measures, which are the structures in your model that hold numeric values.

Measures in Classic Account Models

In a classic account model, model values are stored in a single default measure, and you use the account structure to add calculations, specify units, set up an account hierarchy, and set aggregation types for all the data.

Measures in the New Model Type

The new model type exposes measures as single entities and lets you add and configure multiple measures with aggregation and units to fit your data. It adds plenty of flexibility: you can still match the structure of a classic account model by using a single measure and an account dimension, or you can remove the account dimension when it's not required for your use case:

Examples of model data in different configurations.

This example shows two modeling approaches for simple sales planning data. The new model supports either approach.

Refer to the Choosing a Model Configuration section to figure out the best configuration for your data, or read the Benefits of Models with Measures section to get a full list of benefits.

Benefits of Models with Measures

Models with measures offer the following main benefits, both for analytic and planning use cases:

Flexible model structure: Since both accounts and measures are available as structures for your data (holding calculations and setting aggregation, units, and so on), you can display your data more precisely for a variety of use cases. You can decide whether to include an account dimension, and whether to prioritize the settings for measure or accounts. See Set Structure Priority and Create Custom Solve Order for details.
- Accurate aggregation: Aggregating data over measures instead of accounts opens up some new options. For example, you can generate your balance sheet and profit and loss statement out of a single model.
- Explicit data types: Measures can be set up as integers or decimals. By setting different types of data for different measures like monetary amount, number of units, operating hours, and so on, you can avoid incorrect data, for example decimals when planning on headcount values.
  
  With an integer measure, you can avoid decimals while still distributing the entire value
- Optional account dimension: When you structure your data with measures, you can add your accounts to a generic dimension instead of an account dimension. This setup lets you avoid restrictions on the account dimension. See Choosing a Model Configuration for details.
Improved calculations:
- Calculated measures in models: Since measure calculations can be added to your model, you can reuse them across different stories and analytic applications. You can also add them to some data action steps.
- Calculations on numeric dimension properties: Using this feature, you can change account values from positive to negative based on dimension properties. For example, you can set up calculations that show either positive or negative values for expenses, which makes it easier for different types of users like controllers or accountants to analyze and plan on the same data. Refer to Changing the Signs of Your Account Values Using Numeric Properties for details.
  
  A calculated measure in a model that changes the signs of your account values
Enhanced currency features:
- Base currencies and conversion measures in models: You can add multiple base currency measures to your model and then add currency conversion measures on top of them. This way, you can model and plan on multiple currencies like transaction, local, or group currencies. With currency conversions available in the model, you can use them in formulas as well as data action copy steps. For details, see Work with Currencies in a Model with Measures.
- Planning across currencies: In tables, you can plan on any base measure or conversion measure, such as local, transaction, and group currencies, and instantly see the results across dependent currencies. And you can apply currency conversion while copying data between base measures with a data action. For details, see Plan with Currency Conversion and Convert Currencies in a Data Action.
  
  Entering data on a base measure and a conversion measure
Data integration: The measure model matches the structure of data from several other SAP systems more closely, including SAP S/4 HANA, SAP BW, and SAP IBP. Data integration is generally faster and requires fewer transforms, because you can import data from multiple measures directly instead of turning them into account members.
Clearer terminology for charts and tables: By removing non-financial data from members of the account dimension, you can make data in charts and tables easier to understand for your viewers and content creators.

However, you might need to consider usage restrictions, both for planning and analytics models. See Restrictions for Models with Measures.

Choosing a Model Configuration

With the new model type you can pick different configurations for your model, including whether to use an account dimension or not. It's optional because each measure sets many of the same properties of an account dimension member, such as aggregation, scale, units, and whether there are currency values or not. Check the table below for an overview.

Configuration	Description
Model with measures and an account dimension	This model configuration has two main structures, which can give more flexibility. Consider this setup in the following cases: You want to be able to add calculations both to accounts and measures in the model. You want to set properties like aggregation types and units on your accounts. Measures can also have these properties, but you can give priority to the account settings. You want to use a public account dimension. Your model needs to be compatible with data from a classic account model. For example, using a single measure (or two if you have preconverted currency data) and giving priority to the account dimension makes your model similar to a classic account model.
Model with measures and no account dimension	A simpler configuration, this setup removes the account properties and formulas. It can also make additional features available, though. You might want to use it in these situations: You only want to set up calculations, aggregation types, and units on your measures. Your data doesn't have many different accounts. For example, sales and other line of business scenarios often focus on a single account. Or you might be creating an analytic model with non-financial data. You want to store account data in a generic dimension, for example, to apply multiple hierarchies, page filters, or measure calculations using RESTRICT or LOOKUP to your accounts.
Classic account model	In some cases, you may want to keep using a classic account model: You have an existing classic account model that can’t be migrated to a model with measures yet. For details about migrating your model, see Migrate From a Classic Account Model to a New Model Type. You’re using an import data connection to BPC.

Configuration

Description

Model with measures and an account dimension

This model configuration has two main structures, which can give more flexibility. Consider this setup in the following cases:

You want to be able to add calculations both to accounts and measures in the model.
You want to set properties like aggregation types and units on your accounts. Measures can also have these properties, but you can give priority to the account settings.
You want to use a public account dimension.
Your model needs to be compatible with data from a classic account model. For example, using a single measure (or two if you have preconverted currency data) and giving priority to the account dimension makes your model similar to a classic account model.

Model with measures and no account dimension

A simpler configuration, this setup removes the account properties and formulas. It can also make additional features available, though.

You might want to use it in these situations:

You only want to set up calculations, aggregation types, and units on your measures.
Your data doesn't have many different accounts. For example, sales and other line of business scenarios often focus on a single account. Or you might be creating an analytic model with non-financial data.
You want to store account data in a generic dimension, for example, to apply multiple hierarchies, page filters, or measure calculations using RESTRICT or LOOKUP to your accounts.

Classic account model

In some cases, you may want to keep using a classic account model:

You have an existing classic account model that can’t be migrated to a model with measures yet. For details about migrating your model, see Migrate From a Classic Account Model to a New Model Type.
You’re using an import data connection to BPC.

Examples of Model Configuration

Here are two more examples of how you might use the new model to store data, compared to the classic account model:

Models using currency conversion

Classic Account Model Data with Different Currencies
Entity	Currency	Date	Account	Values
Germany	EUR	March 2022	Gross Profit	1000000
Germany	EUR	March 2022	Operating Expense	750000
United States	USD	March 2022	Gross Profit	850000
United States	USD	March 2022	Operating Expense	600000

With the new model, you can import additional currency measures. In this case, an account dimension is helpful. Without it, your model might need many different measures, making the data more difficult to manage and analyze.

New Model Data with Different Currencies
Entity	Currency	Date	Account	Local Currency Value	USD Value
Germany	EUR	March 2022	Gross Profit	1000000	800000
Germany	EUR	March 2022	Operating Expense	750000	600000
United States	USD	March 2022	Gross Profit	850000	850000
United States	USD	March 2022	Operating Expense	600000	600000

Models that show balances and changes over time

Your model may contain values for balances as well as changes over time, for example, if you're working with headcount, inventory, or capital expense data. In a classic account model, you use a dimension to separate the different types of values. In this case, it's the Flow dimension.

Classic Account Model Data with a Flow Dimension
Entity	Date	Account	Flow	Values
Germany	March 2022	Headcount	Opening	70
Germany	March 2022	Headcount	Transfers	5
Germany	March 2022	Headcount	Closing	75
Germany	March 2022	Salary	#	700000
Germany	March 2022	Benefits	#	3150000
United States	March 2022	Headcount	Opening	60
United States	March 2022	Headcount	Transfers	-5
United States	March 2022	Headcount	Closing	55
United States	March 2022	Salary	#	6000000
United States	March 2022	Benefits	#	2700000

With the new model you can use different measures instead of a flow dimension, which lets you set the correct aggregation for each one.

New Model Data with Separate Measures for Balances and Changes Over Time
Entity	Date	Account	Expenses	Opening	Transfers	Closing
Germany	March 2022	Headcount	-	70	5	75
Germany	March 2022	Salary	7000000	-	-	-
Germany	March 2022	Benefits	3150000	-	-	-
United States	March 2022	Headcount	-	60	-5	55
United States	March 2022	Salary	6000000	-	-	-
United States	March 2022	Benefits	2700000	-	-	-

Restrictions for Models with Measures

Usage restrictions for Account/Measures based Formulas and Calculations:

The Link Formula between models will not be supported. You might consider using the LINK function in an advanced formulas step or cross-model copy.
Cross-model copy steps in Data Actions don't support copying between classic account models and models with measures. Instead, you can use the LINK function in an advanced formulas step.

Usage Restrictions for Stories and Applications

Blending is not supported when the model contains an Account dimension.
Table Thresholds are not supported (in the classic design experience) when the model contains an Account dimension.
For geo maps, area enrichment is not supported.
Measures can only be sorted via Edit Member Order.
Stories made against classic account models are not migrated and must be adjusted to the new model.
Measure based filters are not supported in models that have both measures and account dimensions.

Data Import restrictions

Dimension members must exist first: prior to fact data import, you need to create dimension members in modeler, or import data to global dimension.
For SAP data center tenants, all measure columns must be mapped. For data sources with less measure column, you might consider creating a calculated column in wrangling with a constant 0 or null.
Models created from a CSV/Excel file or data source (data first workflow) are still created as classic account model.
In non SAP data center, incremental load isn't supported when importing data to the new model type.
In non SAP data center, importing data to the new model needs to specify a new query from the data source. Copying of existing query associated with a model is not supported.
Data upload into the new model doesn't support combining data function.
The "Copy query from a model" option isn't available when importing data from a model with measures.

Microsoft Office integration restrictions

If you migrate a classic account model already used with the add-in, you need to re-insert that model into an existing workbook created with SAP Analytics Cloud, add-in for Microsoft Office.
You can't use the new model type with the add-ins SAP Analysis for Microsoft Office and SAP Analysis for Microsoft Office, edition for SAP Analytics Cloud.