BW Object Naming Standards
Overview
Purpose:
The purpose of defining strict naming standards for BW objects is to ensure the entire
project team is consistent in the approach to creating and identifying objects in the BW
system. The following BW objects are covered by this document.
Table of Contents:
InfoProvider ........................................................................................................................ 2
InfoSource ........................................................................................................................... 5
DataStore Object ................................................................................................................. 5
InfoObject ........................................................................................................................... 6
Query................................................................................................................................... 6
Query View ......................................................................................................................... 7
Report.................................................................................................................................. 8
Web Template ..................................................................................................................... 8
Restricted Key Figures ........................................................................................................ 9
Calculated Key Figures ....................................................................................................... 9
Variables ........................................................................................................................... 10
Structures .......................................................................................................................... 11
InfoPackages ..................................................................................................................... 11
Process Chain .................................................................................................................... 12
Application Component .................................................................................................... 12
Flat Files............................................................................................................................ 13
Custom Generic Extractors ............................................................................................... 13
Datasource......................................................................................................................... 13
Aggregates ........................................................................................................................ 14
Page 1 of 14
BW Object Naming Standards
InfoProvider
Definition:
Analysis-relevant view of a BW object for which queries in SAP BW can be created or
executed.
There are two types of InfoProviders. One type includes objects that contain physical
data. These are known as data targets, such as InfoCubes, ODS objects, and InfoObjects
(characteristics with attributes, texts, or hierarchies). The other type includes objects that
contain no physical data storage, but make the data available for viewing. This includes
objects such as InfoSets, RemoteCubes, VirtualCubes, and MultiProviders. An
InfoProvider contains two types of data: key figures and characteristics. InfoProvider
Definitions and naming conventions are as follows.
InfoCube
Definition:
An InfoCube is a set of relational tables that are arranged in a star schema with a
large fact table for recording transaction data at the center and several dimension
tables surrounding the fact table. The fact table contains the key figures of the
InfoCube, while the dimension tables contain the characteristics of the cube.
InfoSources (see below) supply data to InfoCubes.
MultiProvider
Definition:
Type of InfoProvider that combines data from several InfoProviders and makes it
available for reporting.
The MultiProvider itself contains no data; its data comes exclusively from the
InfoProviders on which it is based (collated using a union operation). A
MultiProvider can be assembled from different combinations of InfoProviders.
MultiProviders, like InfoProviders, are objects or views that are relevant for
reporting.
RemoteCube
Definition:
RemoteCube is not managed in the Business Information Warehouse, but rather
externally.
Only the structure of the RemoteCube is defined in BW. The data for reporting is
read from another system using a BAPI.
Page 2 of 14
BW Object Naming Standards
VirtualCube
Definition:
VirtualCubes are enhanced versions of RemoteCubes. VirtualCubes call selfdefined function modules (local or remote programs) that behave like a fact table.
Similar to RemoteCubes, the data for reporting is read from another system using
a BAPI.
InfoSets
Definition:
A semantic view of InfoCubes, ODS objects and InfoObjects (characteristics with
master data) that allows you to create reports on these objects, particularly on the
joins between these objects.
Unlike the classic InfoSet, this view of data is BW-specific. InfoSets are created
and changed in the InfoSet builder. InfoSets allow you to use the Query Designer
to define reports.
InfoProvider Naming:
The InfoProvider naming convention will follow as close as possible the SAP
standard naming convention in BW. In most cases, the technical name of the
Business Content InfoProvider can be used by dropping the leading 0 and
replacing it with a Z. Therefore for custom InfoProviders the format of the
technical name will be as follows:
Zmmffxnn
 mm = primary module (FI, HR or ST)
 ff = functional area (minus hyphens, i.e. CO-PA use CO)
 x = type of infoprovider,
o M = MultiProvider
o C = InfoCube
o R = RemoteCube
o V = VirtualCube
o I = InfoSet.
 nn = two-digit number
If no or minor changes are made to an InfoProvider, the Business Content name is
to be used, i.e. - 0CCA_C02.
A Custom InfoProvider has a limit of 9 characters for the technical name. If a
problem occurs with length of the technical name when trying to name a custom
InfoProvider by just changing the first character (0) to a Z, please use the
following process:
 eliminate the 0 after “x”.
The following table lists the commonly used functional area abbreviations that
replace ff in the above definition.
ff Description
 CO – Financial / Controlling
Page 3 of 14
BW Object Naming Standards
 AA – Asset Accounting
 AP - Accounts Payable (contains sensitive vendor attributes)
 AR - Accounts Receivable
 GL – General Ledger Accounting
 TV – Travel Management
 TR - Treasury
 CP – Product Cost Controlling
 OM – Overhead Cost Controlling
 FM - Funds Management
 GM - Grants Management
 BC – Personnel Budget Planning
 PM – Plant Maintenance
 SL - Special Purpose Ledger
 PS – Project System
 IM – Inventory Management
 HM - Human Resource
 PY - Payroll
 BN - Benefits
 PT - Time Management
 OM - Organizational Management
 RC – Recruitment
 ER – E-Recruitment
 CM – Compensation Management
 PA - Personnel Administration
 CT – Cross-Application Time Sheet
 CP – Personal Cost Planning
 AS - Academic Structure
 SL - Student Management
 TC - Technical Content
If the cube is a copy of an existing SAP standard cube then the two-digit number
should be the same as the cube copied. If the cube has been fully customized then
the two-digit number must be sequentially assigned in the range 50 to 99.
Examples:
1. A copy has been made of the Costs and Allocations (Marginal Costs)
standard cube (technical name = 0CCA_C02) and a number of additional
InfoObjects have been created and a new cube is necessary. The technical
name of the new cube should therefore be ZFICAC02.
2. A material movements cube has been created from scratch to track
inventory transactions by movement type. The technical name of this cube
would be ZFIICC50.
3. Multi-Cube: Example: ZFISDM50.
Z – custom SD – functional area of the cubes that feed the Multi-Cube
M – Multi-Cube 50 – number of the cube
Page 4 of 14
BW Object Naming Standards
InfoSource
Definition:
An InfoSource is a set of logically associated information that can contain transaction
data (stored in InfoCubes) and master data (attributes, texts, and hierarchies stored in
separate tables). InfoSources describe all the information available for a business
transaction or type of business transaction (for example, cost center accounting).
InfoSource Naming
The format of the name will be as follows:
 Transaction Data: InfoSource = DataSource Technical Name
 Long Description = DataSource Description
 Master Data: Select InfoObject, the technical name and description will be
assigned from the InfoObject.
DataStore Object
Definition:
A DataStore object contains supporting information for the BW InfoCubes. It may be
used to contain information at a more detailed level than the summarized InfoCube
information; or it may contain information combined from multiple sources. This data is
accessible via queries and the Bex analyzer and browser, or via an infoset query.
DataStore Naming:
The DataStore object naming convention will follow as closely as possible to the SAP
standard naming convention in standard BW. The format of the name will be as follows:
Zmmff_Onna
 mm = primary module (FI, HR or ST)
 ff = functional area (minus hyphens, i.e. CO-PA use COPA)
 nn = two-digit number
 a = A, B, C, D, etc for multiple DataStore object’s that feed the same
InfoCube
A custom DataStore object has a limit of 8 characters for the technical name. If a
limitation occurs when naming the DataStore object please try the following:
 eliminate the 0 after O, ZFIPUO1A, ZFIPUO1B
The InfoProvider list (above) shows the commonly used functional area abbreviations
that replace ff in the above definition. The DataStore object should be named according to
the cube it directly supports, if any. If it is fully customized and does not relate to a cube,
it should follow the same scheme for InfoProviders and be assigned a sequential number
in the range 50-99.
Examples:
Page 5 of 14
BW Object Naming Standards
1. A DataStore object has been made to support the Costs and Allocations (Marginal
Costs) standard cube (technical name = 0CCA_C02). The technical name of the
DataStore object should therefore be ZFICAO02.
2. If multiple DataStore objects were created to support ZFICAC02. They would be
called ZFICAO2A and ZFICAO2B. (because of 8 character limitation on
technical name.
3. If multiple DataStore objects were created to support ZSD_C02. They would be
called ZFISDO2A and ZFISDO2B.
InfoObject
Definition:
An InfoObject is a generic term for characteristics and key figures in the Business
Information Warehouse. InfoObjects are used in InfoCubes and in the three structures
that are relevant for data requests—extract, transfer, and communication structures.
InfoObject Naming
Custom InfoObjects should always start with a Z. When a standard SAP InfoObject is
copied the 0 should be dropped from the name and be replaced by Z. A fully customized
InfoObject should also begin with a Z followed by a logical name to describe the
InfoObject. The abbreviations used by SAP for various terms in the standard InfoObjects
should be used where possible. Recognize that replacing a standard business content
InfoObject with a custom Z InfoObject may cause problems because of their use in:
 Authorization Relevance,
 Removing Attributes, or Adding Attributes to an InfoObject affects all
Infoproviders that use the InfoObject.
Only create new Z InfoObjects when a business content InfoObject doesn’t apply or the
InfoObject is being customized for specific use in a InfoProvider.
Examples:
1. A copy of the 0MATERIAL infoobject would be given the technical name
ZMATERIAL.
2. A custom infoobject has to be created to report on the sales quotas. The technical
name would therefore be ZSLS_QUOTA.
Query
Definition:
A query is a data evaluation based on the selection of characteristics and key figures.
Queries can be configured according to the way users want to view and navigate through
data. Users define queries to analyze the data from an InfoProvider.
Page 6 of 14
BW Object Naming Standards
Query Naming:
As queries are created specific to an InfoProvider (InfoCube, DataStore, Master Data,
etc..) it is advisable to identify the respective InfoProvider in the technical name for easy
identification. The naming convention for Super User queries is as follows:
Zcube_Qnnnn
 cube = InfoProvider Name
 Q = constant for queries
 nnnn = four-digit sequential number
The naming convention for Power User queries is as follows:
Ycube_Qnnnn_DDD_III
 cube = InfoProvider Name
 Q = constant for queries
 nnnn = four-digit sequential number
 DDD = Department abbreviation
 III = username of query developer
Customized queries should use sequential numbers in the range 5000 to 9999. If the
InfoProvider and query are copies of standard SAP content the sequential number should
be maintained for the query.
Examples:
1. A custom super user query for infocube ZSD_C04 has the technical name
ZZSD_C04_Q5000. (Standard InfoCube, Custom Query)
2. A custom power user query written by JSMITH for infocube ZIC_C50 would
have the technical name YZIC_C50_Q5000_BSC_JSMITH. (Custom InfoCube,
Custom Query)
3. A copy of query by a power user of 0CCA_C02_Q0004 for infocube
ZCCA_C02 would have the technical name
YZCCA_C02_Q0004_BSC_JSMITH. (Copied InfoCube and Query)
4. A custom super user query for infocube ZCCA_C02 would have the technical
name ZZCCA_C02_Q5000. (Copied InfoCube, Custom Query)
Query View
Definition:
A query view is a “picture” of a query that saves any formatting done in the Bex
Analyzer. An example of this is to hide key figures from the initial display of the report.
Query View Naming
As query views are created specific to an InfoProvider and query, it is advisable to
identify the respective cube and query in the technical name for easy identification. The
standard naming convention is to use the technical name of the query but replace the Q
with a V to designate a View and add _nn, (nn = two-digit sequential number).
Page 7 of 14
BW Object Naming Standards
Examples:
A query view based on query ZZIC_C51_Q5001 would have the technical name
ZZIC_C51_V5001_01
Report
Definition:
A report is a data presentation based on a query or multiple queries. Reports can be
configured according to the way users want to view and navigate through data. Reports
can be dynamic or pixel formatted. Reports are typically viewed through the portal,
although some may be available through BEx Analyzer.
Report Naming:
As reports are not created specific to a single InfoProvider, it is not feasible to include all
InfoProviders in the technical name. It is suggested that the InfoProvider of the primary
or initial query in the report be used in the technical name. The name can be up to 30
characters long.
Zcube_Rnnnn
 cube = InfoProvider Name
 R = constant for reports
 nnnn = four-digit sequential number
The naming convention for Power User queries is as follows:
Ycube _Rnnnn_DDD_III
 cube = InfoProvider Name
 R = constant for reports
 nnnn = four-digit sequential number
 DDD = Department abbreviation
 III = username of report developer
Customized reports should use sequential numbers in the range 5000 to 9999.
Examples:
1. A custom super user report for Grants has the technical name
Z0GM_C02_R5000.
2. A custom power user report for Payroll has the technical name
YZHR_C01_R5000_BSC_JSMITH.
Web Template
Definition:
A Web template is the HTML page that you use to determine the structure of the Web
application.
Page 8 of 14
BW Object Naming Standards
Web Template Naming
As web templates are created specific to an InfoCube and query it is advisable to identify
the respective cube and query in the technical name for easy identification. The standard
naming convention is to use the technical name of the query but replace Q with a T to
designate a template and add _nn, (nn = two-digit sequential number).
Examples:
A web template based on query YZIC_C51_Q5001 would have the technical
name YZIC_C51_T5001_01
Restricted Key Figures
Definition:
A restricted key figure is a key figure that is restricted to certain characteristic values. It
is defined in the query definition and limits the selected data to the values or range of
values selected. It is available for any query created for the InfoProvider of the original
query.
Restricted Key Figure Naming
Restricted key figures are specific to an InfoProvider and therefore will include the
InfoProvider technical name. The format will be as follows:
RKcube_nnnn
 cube =InfoProvider technical name
 nnn = sequential number
Custom restricted key figures will have a sequential number starting at 5000.
Examples:
1. Custom restricted key figure for InfoProvider 0FIFM_C01 would have the
technical name RK0FIFM_C01_5000.
2. Restricted key figures for custom InfoProvider ZIC_C50 would have the
technical name RKZIC_C50_5000.
Calculated Key Figures
Definition:
A calculated key figure is a key figure that is a calculation of one or more other key
figures. Standard, custom, restricted key figures and other calculated key figures can be
used for the calculation. Like Restricted Key Figures, it is also available for any query
created for the InfoProvider of the original query.
Page 9 of 14
BW Object Naming Standards
Calculation Naming
Calculated key figures are specific to an InfoProvider and therefore will include the
InfoProvider technical name. The format will be as follows:
CKcube_nnnn
 cube = InfoProvider technical name
 nnnn = sequential number
Custom calculated key figures will have a sequential number starting at 5000.
Examples:
1. Custom calculated key figure for InfoProvider 0FIFM_C01 would have the
technical name CK0FIFM_C01_5000.
2. A calculated key figure for custom InfoProvider ZIC_C50 would have the
technical name CKZIC_C50_5000.
Variables
Definition:
Variables are selection criteria of a query that are set in the query definition and are not
filled with values until the query is executed (processed) and inserted into a workbook.
They function as a store for characteristic values, hierarchies, hierarchy nodes, texts and
formula elements and can be processed in different ways.
Variable Naming
Following SAP’s naming standard, the format for a variable will be:
Y_nnnnn
 Y:
o S = Selection option variable (range withinclude/exclude/insert)
o I = Interval variable, i.e. the user enters a range of entries
o M = Multiple single values
o P = Parameter variable (single value)
o V = Precalculated value set variable
o T = Text variable
o F = Formula variable
o H = Hierarchy variable
o N = Hierarchy node variable
 nnnnn: Meaningful name based on the InfoObject for which the variable is used
T, F, H and N variables describe the variable type. Whereas S, I and P variables are both
of the type characteristic and the acronym stands for the type of selection criteria. The
abbreviations used by SAP for various terms in the standard variables should be used
where possible. Variables are InfoProvider independent and should therefore not contain
the names of any InfoProviders.
Examples:
1. A custom variable that is used in a query to select on a range of customers would
have the technical name I_CUSTR.
Page 10 of 14
BW Object Naming Standards
2. A custom variable that is used to automatically replace the text of a time
characteristic based on the entry made would have the technical name
T_FYEAR.
Structures
Definition:
Structures are freely definable reports that consist of combinations of characteristics and
basic key figures (for example, as calculated or restricted key figures) of the
InfoProvider. A structure can be a plan / actual comparison or a contribution margin
schema, for example. Structures can be used in several different queries. To do this, it is
necessary to save the structure that may be used again. These structures are then called
reusable structures.
Structure Naming
Following SAP’s naming standard the format for a structure will be:
Scube_nnnn
 cube = infocube technical name
 nnnn = sequential number
Custom structures will have a sequential number starting at 5000.
Example:
A structure that is used in the Sales and Distribution InfoProvider 0SD_O01would
have the technical name S0SD_O01_5000.
InfoPackages
Definition:
InfoPackages are the method that BW uses for loading data from a source system into a
BW PSA. They are associated with an InfoSource and a source system in BW 3.5 and are
associated with a DataSource in BW 7.0. They are used to load either transactional or
master data. They can be combined into Process Chains.
InfoPackage Naming
InfoPackages are entirely custom, and are specific to the source system, InfoSource
(BW3.5) DataSource (BW 7.0) as well as the data that is being loaded:
The format is:
InfoSource (3.5)/DataSource (7.0)_tttt_X
 tttt – Type of data (TRANS – transaction, TEXT-Text, ATTR-Attribute, 01Heirarchy (02, 03 for multiple hierarchies)
 X for Type of Update
o I = delta Initialization.
o F = full Update.
Page 11 of 14
BW Object Naming Standards
o D = delta
Example:
InfoSource i.e. 0MATERIAL would have an InfoPackage of
0MATERIAL_ATTR_I for the initialization and an InfoPackage of
0MATERIAL_ATTR_D for the delta loading of data.
Process Chain
Definition:
Sequence of processes that are scheduled in the background to wait for a particular event.
Process chains are used to control the process of loading data into BW and triggering
various other events, such as dropping and rebuilding indexes when loading some
DataStore objects, triggering the hierarchy/attribute change run and sending alerts. Some
of these processes may trigger an additional event, which in turn can start other
processes.
Process Chain Naming
Process Chains are entirely custom and can be specific to a single process or several
processes. The naming format should allow the viewer to know what process is being
performed by the Process Chain. The format is:
Z_ddddddddddddd
dddddddddddddddddddddd = description of process
Examples:
1. Z_LD FICO MD D – Delta load of masterdata for FI
2. Z_LD PYRL TRANS Full – Full load of payroll data.
Application Component
Definition:
An Application Component is an area that organizes InfoSources together in a logical
way for navigation.
Application Component Naming
Application components should be named Z*. There is a textual description that should
explicitly provide information on the function.
Examples:
1. ZPOCAREA
2. ZTESTAREA
3. ZSANDBOX
Page 12 of 14
BW Object Naming Standards
Flat Files
Definition:
Used to copy files from external sources into BW.
Flat File Naming
Flat Files are entirely custom and are specific to the system, source system and the data
that is being loaded:
InfoObjectName.csv
Example:
1. Transaction.csv
2. Account.csv
Custom Generic Extractors
Definition:
Used to provide transaction and masterdata from R/3 for delivery to BW.
Custom Generic Extractor Naming
Following SAP’s naming standard, the format for a new transaction
datasource will be:
Z_xx_(ffff + description if transactional),(InfoObject if masterdata)
 xx for type of extractor
o Tr = transactional data.
o M = masterdata attributes.
o Tx = masterdata Text
 ffff = functional area or
 InfoObect
Examples:
1. Z_M_ZPLANT
2. Z_TR_PY_ACTION
3. Z_TX_ZPLAN
Datasource
Definition:
Used to provide transaction and master data from R/3 for delivery to BW.
Page 13 of 14
BW Object Naming Standards
DataSource Naming
The format for a custom datasource should follow the naming convention of the custom
generic extractor, or if the datasource is created from a business content extractor the
format will be:
Zdatasource_xxxx
• xxxx = TRAN, TEXT, HIER, ATTR
•
Examples:
1. Z_M_ZPLANT
2. Z_TR_PY_ACTION
3. Z0EMPLOYEE_HIER
Aggregates
Definition:
Used to pre-summarize data to improve data reporting performance.
Aggregate Naming:
BW will determine the technical name.
Page 14 of 14