SAP BW/4HANA InfoObjects: Basics, Types, and Creation Steps

InfoObjects are reusable metadata objects that give SAP BW/4HANA models consistent business meaning. They define characteristics such as Customer or Company Code, key figures such as Quantity or Net Amount, and supporting properties such as texts, attributes, units, and currencies.

A reliable design starts with the reporting and data-loading requirements, then assigns each field to the appropriate InfoObject type. This prevents the same business field from being modeled with different technical properties across ADSOs, transformations, and CompositeProviders.

01What an InfoObject does

An InfoObject provides a shared definition for a business field. Its definition can include a technical name, description, data type, length, master-data behavior, text settings, navigational attributes, units, currencies, and authorization-relevant properties.

Characteristics describe the dimensional context of a record. Examples include Customer, Product, Fiscal Year, Company Code, and Sales Organization. A characteristic can carry master data, texts, attributes, or hierarchies when the model requires them.

Key figures describe measurable values. Examples include Quantity, Net Value, Cost, and Discount. Their definition includes numeric behavior such as data type, decimal places, aggregation, and—where relevant—the associated unit or currency.

InfoObjects are used by multiple model objects, so a change to a shared definition can affect data loading, activation, reporting, and dependent objects. Treat the definition as a governed interface rather than as a local field label.

02Characteristic and key figure choices

Use a characteristic when users need to filter, group, join, authorize, or navigate by a business concept. Use a key figure when the value is numeric and is aggregated or evaluated as a measure.

A numeric source field is not automatically a key figure. If the value identifies a category, code, or status, model it as a characteristic even when the source system stores it numerically.

03InfoObject creation workflow

Use BW Modeling Tools in Eclipse to create and maintain InfoObjects in the BW/4HANA project. Coordinate the definition with the team responsible for the source structure and the downstream ADSO or CompositeProvider.

1. Define the business meaning. Record the field name, business description, source origin, allowed values, granularity, and whether the field is used for filtering, grouping, authorization, or aggregation.
2. Select the InfoObject type. Choose a characteristic for dimensional context or a key figure for a measurable value. Identify the related unit or currency where applicable.
3. Set technical properties. Define the data type, length, decimal places, master-data and text requirements, and other properties required by the model.
4. Choose a naming convention. Use a stable technical name that communicates the business meaning and follows the naming standard for the BW/4HANA system.
5. Assign the InfoObject to the appropriate InfoArea. Keep related objects together so modelers can locate and govern them consistently.
6. Activate the object. Resolve validation messages before using the InfoObject in an ADSO, transformation, or CompositeProvider.
7. Test with representative data. Check values, lengths, decimal behavior, units, currencies, texts, and master-data relationships.
8. Document dependencies. Record the source field, consuming objects, transport sequence, and any downstream recalculation or reload requirement.

For a broader model context, see the SAP BW/4HANA overview and SAP BW/4HANA InfoArea modeling.

04Master data, texts, and attributes

A characteristic can have master data that supplies reusable descriptions or attributes. For example, a Product characteristic may have product text, product group, and product hierarchy-related information. Decide whether an attribute belongs in master data or in the transactional record based on its stability, reuse, and reporting behavior.

Texts support readable descriptions in reporting and administrative tools. Define the required text language behavior and verify that the load process supplies the expected language records.

Navigational attributes expose selected master-data attributes for analysis. They are useful when a reporting model needs to analyze a characteristic by a related property without duplicating that property in every transaction record. Confirm the activation and loading sequence before making such attributes available to consuming objects.

05Using InfoObjects with ADSOs and transformations

ADSO fields can use reusable InfoObjects when the field needs governed semantics across the data warehouse. Reusable definitions are especially helpful for common characteristics, units, currencies, and key figures.

Transformations map source fields to target fields and apply rules such as formulas, routines, lookups, and conversions. Validate that the source and target semantics match before activation. A source amount mapped to a target key figure also needs compatible currency handling, decimal behavior, and aggregation intent.

Use the SAP BW/4HANA Advanced DataStore Object guide when deciding how the InfoObject definition fits the persistence layer. Review SAP BW/4HANA transformations when a mapping requires conversion or rule-based derivation.

A CompositeProvider consumes fields from its underlying providers. Consistent InfoObjects make unions, joins, and analytical navigation easier to manage, but they do not remove the need to verify field compatibility and granularity.

06Troubleshooting InfoObject activation

Start by reading the activation log and identifying whether the issue concerns the definition, a dependency, a naming conflict, or the consuming object. Make one controlled change at a time and reactivate the affected object.

Activation fails after a property change: Check dependent ADSOs, transformations, and providers. Confirm that the new length, data type, decimal behavior, unit, or currency remains compatible with each consumer.

Values are truncated or rejected: Compare the source definition, transformation mapping, and InfoObject length and data type. Test boundary values, leading zeros, negative values, and decimal values where those cases are valid.

Amounts or quantities are misleading: Verify the associated currency or unit and confirm that the transformation does not apply an unintended conversion. Check aggregation behavior in the consuming provider.

Texts or attributes are missing: Confirm that the master-data load supplies the relevant records and languages, then verify the activation sequence and the characteristic settings.

The object cannot be found by another modeler: Check the assigned InfoArea, project visibility, technical name, and transport status. Use a consistent naming convention and description so the object can be located without relying on personal knowledge.

07Operational checklist

Before releasing an InfoObject for use, verify the following:

• The business meaning and grain are documented.
• The characteristic or key figure type matches the intended use.
• Data type, length, decimal places, unit, and currency are compatible with the source.
• Texts, master data, attributes, or hierarchies are enabled only when required.
• The object is assigned to the correct InfoArea.
• Dependent ADSOs, transformations, and providers are identified.
• Activation succeeds in the intended transport sequence.
• Representative source values pass validation and produce expected results.
• The owner knows whether a later definition change requires a reload or recalculation.

08Summary

InfoObjects provide reusable semantics for SAP BW/4HANA models. Characteristics define the dimensions used to filter and group data, while key figures define measurable values and their aggregation behavior. A disciplined creation workflow covers business meaning, technical properties, dependencies, activation, and representative-data testing.

Use shared InfoObjects where consistent semantics add value, and keep local fields local when reuse would create unnecessary coupling. The best design is the one whose definitions remain understandable and stable as ADSOs, transformations, and CompositeProviders evolve.