Many SAP BW implementations begin with a rollout of R/3 Financial Accounting (FI) information. A common requirement of these implementations is to deliver balance sheet and profit and loss (P&L) analyses via SAP BW. With the launch of the BI Content 3.2 Add-On, this requirement is now much easier to fulfill.

New functionality in this release, based on existing R/3 configuration settings, allows users to accommodate so-called “contra accounts” in their financial reporting without the need for costly custom workarounds. Prior to the 3.2 release, it was necessary to either address contra accounts during the staging process via customized transformations or during the query definition process by using custom VBA coding in BEx workbooks. The balance sheet functionality will be available with SP18 for SAP BW 3.0B and with SP15 for the BI Content 3.1 Add-On (please read SAP note 652934 for details).

On the balance sheet, a contra account is one that can appear as either an asset or a liability depending on its status at the financial statement runtime. Cash is one example. When the financial statement is generated, a positive cash balance is considered an asset. However, a negative balance can be considered a liability because the cash must be repaid to the bank. Because cash is an asset, some companies elect to record a negative balance in the asset section of the balance sheet. Other firms, however, represent a negative balance as a positive number on the liability side of the balance sheet.

I will identify the master data settings and data models required to display contra accounts using either of these accounting practices. If the finanacial statement is a P&L, the contra account simply shifts values between revenues and expenses instead of shifting between assets and liabilities. For the remainder of this article, I will refer only to balance sheet scenarios. However, the same logic can be applied to P&L statements.

The new functionality delivered with the BI Content 3.2 Add-On supports cost-of-sales accounting methods, which are consistent with the Generally Accepted Accounting Principles used in the United States (U.S. GAAP) as well as period accounting methodology. The BI Content 3.2 Add-On delivers new InfoObjects, virtual InfoCubes including the necessary function modules and queries, which allow users to display contra accounts (within the context of a hierarchy) as either assets or liabilities, depending on the hierarchy node total.

Figure 1 provides a visual example of how the contra accounts are displayed in an SAP BW query. In the figure, you see the results of a balance sheet query that compares fiscal year 2000 with fiscal year 1999. The account structure is displayed in a mandatory hierarchy. Under the column Fiscal Year 2000, the hierarchy node for bank 1 has a positive $60,000 balance despite the fact that Bank account 4712 — one leaf of this node — has a negative balance. In fiscal year 2000, bank 1 is shown in the current assets section of this hierarchy. However, in fiscal year 1999, the hierarchy node for bank 1 has a balance of negative $40,000. In fiscal year 1999, the bank 1 account is displayed in the liabilities section of the hierarchy. Figure 1 also displays how the accounts themselves will be displayed in the query.

Figure 1

In an SAP BW query, contra accounts are displayed in a hierarchy with placeholders in both the assets and liabilities sections. The balance of the account at the financial statement runtime determines which placeholder the system uses.

Note that contra accounts exist in the hierarchy twice — once in the liabilities section and again in the assets section — because contra accounts must have multiple placeholders in the hierarchy. The balance of the account at financial statement runtime determines which placeholder the system uses.

Financial Statement Items

To accommodate contra accounts, two new characteristic InfoObjects are delivered with the BI Content 3.2 Add-On. These new InfoObjects store master data that the system uses to determine how the transaction data values for each leaf/node of the hierarchy are aggregated and displayed in a balance sheet query. The first new characteristic InfoObject, 0GLACCEXT (financial statement item), is the balance sheet (and P&L) statement item, and the second, 0BAL_DEPEND (balance dependency of a hierarchy) is an attribute for balance sheet hierarchies attached to 0GLACCEXT.

0GLACCEXT stores master data for the balance sheet item. This master data correlates to the R/3 General Ledger (G/L) accounts for firms using period accounting, or functional areas for those based on cost-of-sales accounting procedures. Figure 2 shows the four components of the key composition for 0GLACCEXT, which is created by the BW system automatically when the master data is loaded from SAP R/3:

• The chart of accounts
• The G/L account or functional area
• The position indicator
• The account type

Figure 2

The new 0GLACCEXT key composition consists of four components

The first two components are self-explanatory. The position indicator determines the nature of an account and defines which accounts are to be processed as contra accounts, and the account type specifies if the account is a G/L account or a functional area.

The position indicator has three possible values. Position indicators with a 1 or 2 value represent a contra account. For a 1 value, the total for the account is treated as an asset if the amount is negative and as a liability if the total is positive. A 2 value means that the account should be treated as a liability if the total for the account is negative and as an asset if the total is positive.

If an account is defined in the financial statement version as being a contra account, the staging process creates two financial statement items within 0GLACCEXT for this account. One financial statement item has a position indicator of 1, which is used for processing values on the asset side of the balance sheet, and the other financial statement item has a position indicator of 2, which is used for processing values on the liability side of the balance sheet. If the account is not defined in R/3 on the financial statement version as a contra account, the position indicator is set to default () and only one financial statement item is created in 0GLACCEXT for that account.

The default setting () establishes that the account is treated as a traditional account. This means that if the account is naturally an asset — such as a cash account — then it is to be treated as an asset regardless of the total in the account. In other words, if the default setting is used, a negative balance appears as a negative asset on a balance sheet query, while that negative balance appears as a liability on the balance sheet query when the position indicator is set at 1 and 2.

Each of the four key composition values is determined in the R/3 source system and written to 0GLACCEXT when the master data is extracted. You set the indicators in SAP R/3 for the G/L account numbers, for example, when you maintain the financial statement versions in R/3. (Refer to the “Defining the Debit/Credit Shift” entry in the R/3 online documentation at help.sap.com for more information.) This type of maintenance must be performed in the source system and cannot be done directly in SAP BW. The extractor then reads the R/3 settings and determines what the values will be in the SAP BW master data for the position indicator and other 0GLACCEXT components when it pulls from tables T011 and RFDT in the R/3 source system.

Balance Dependency of a Hierarchy

0BAL_DEPEND is an attribute of the nodes within the hierarchies loaded into 0GLACCEXT and is new to the BI Content 3.2 Add-On. The 0GLACCEXT hierarchies are unique in SAP BW because they are the only ones that have an attribute. The balance dependency (0BAL_DEPEND) of a node determines how that node is aggregated (Figure 3). Keep in mind that a node in a hierarchy can consist of several end nodes, each of which represents a financial statement item. Nodes that contain financial statement items that are treated as contra accounts have corresponding placeholders in both the asset and the liability sides of the hierarchy (i.e., the nodes for Postal giro, as depicted in Figure 3).

Figure 3

The 0BAL_DEPEND attribute is used to determine if a balance sheet item is represented as a firm’s assets or liabilities.

0BAL_DEPEND has three possible values:

• Normal aggregation (default value): This is the most frequently used setting and employed for accounts that are fixed on either the assets or liabilities side of the balance sheet.
• Aggregation only with debit sign (1): This value is entered for contra account nodes on the asset side of the balance sheet. The sum of all the accounts in this node is checked, and if it is positive, the individual accounts (0GLACCEXT items) are aggregated and displayed in the asset section of the balance sheet query.
• Aggregation only with credit sign (2): This value represents contra account nodes on the liability side of the balance sheet. The sum of these nodes is checked, and if it is negative, the individual accounts (0GLACCEXT items) are aggregated and displayed on the liability section of the balance sheet query.

Similar to the master data for 0GLACCEXT, the values for the attribute 0BAL_DEPEND are determined by the source system configuration and are not maintained directly in SAP BW.

To recap: The master data is loaded from the source system into the new characteristic InfoObject 0GLACCEXT along with the hierarchies, which include an attribute value for 0BAL_DEPEND. The logic for filling both the concatenated key of 0GLACCEXT and the hierarchy attribute 0BAL_DEPEND comes from the configuration settings in the R/3 source system. The master data is not maintained directly in SAP BW.

Transaction Data

Transaction data is processed through two InfoCubes delivered with the BI Content 3.2 Add-On. These are virtual InfoCubes with services and do not contain data. The G/L accounting virtual InfoCube (0FIGL_VC1) is for period accounting, and the cost-of-sales ledger virtual InfoCube (0FIGL_VC2) is for cost-of-sales accounting.

When loading transaction data into the SAP BW system, it continues to be loaded into the preexisting delivered InfoCubes 0FIGL_C01 and 0FIGL_C02. To display the nodes with balance-dependent positions in the balance sheet hierarchy, the virtual InfoCube employs the RS_BCT_FIGL_DATA_GET function module included in the BI Content 3.2 Add-On. With this module, the virtual InfoCube pulls data from the InfoCubes loaded with transaction data (0FIGL_C01 and 0FIGL_C02) and, using the master data settings that were loaded into 0GLACCEXT and 0BAL_DEPEND, calculates the balances of the nodes on the fly and displays the result in the query. Note that the RS_BCT_FIGL_DATA_GET function module can be modified to pull data from custom InfoCubes instead of from the predelivered InfoCubes if you create virtual InfoCubes with services or you are loading transaction data into custom InfoCubes.

This RS_BCT_FIGL_DATA_GET function module is a key element to the entire balance sheet concept in SAP BW, so I would like to summarize what the system is doing at this point. As we have seen, the hierarchy for 0GLACCEXT can contain regular and contra-account master data. The balance dependency (0BAL_DEPEND) attribute on the nodes of this hierarchy contains either the value 1 or 2 if the node is for contra accounts, or it is blank if the node represents normal accounts. For contra accounts, there are duplicate nodes in the hierarchy.

Nodes on the asset side of the hierarchy contain the 0GLACCEXT financial statement items with position indicators of 1. The 0BAL_DEPEND value is also 1 for these nodes. The mirror nodes on the liability side of the balance sheet contain the 0GLACCEXT financial statement items that have a position indicator of 2. The 0BAL_DEPEND value is also 2 for these nodes.

The transaction values, then, are duplicated in the hierarchy, and at runtime the function module RS_BCT_FIGL_DATA_GET reads the data according to the hierarchy beginning with the assets section. When it reaches the nodes that have a 0BAL_DEPEND value of 1, it totals the individual items within that node and posts the total to the asset side of the balance sheet if it is positive. If the total is negative, it ignores the values from that node entirely. Later in the hierarchy, the function module reads the same entries again, except this time they are in a node with a 0BAL_DEPEND value of 2. If the total is negative, the function module posts the node to the liability side of the balance sheet, and it ignores the node completely if the total is positive. As a result, the query displays the hierarchy with balance-dependent positioning of the nodes that contain contra accounts.

The BI Content 3.2 Add-On also delivers two new key figure InfoObjects —0VAL_FLOW and 0VAL_STOCK. As depicted in Figure 4, the function module called by the virtual InfoCubes maps the values contained in the key figure InfoObjects 0BALANCE, 0DEBIT, and 0CREDIT from where the transaction data is stored (0FIGL_C01 and 0FIGL_C02), and into 0VAL_FLOW if it is an income statement item or into 0VAL_STOCK if the item is for a balance sheet.

Figure 4

Transaction data is loaded into InfoCubes 0FIGL_C01 and 0FIGL_C02 and called by two new virtual InfoCubes delivered with the BI Content 3.2 Add-On. 0FIGL_VC1 is for period accounting, and 0FIGL_VC2 is for cost-of-sales accounting.

The accounts of the P&L statement have the key figure 0VAL_FLOW with a normal aggregation because here the comparison values for a period are necessary. The accounts of the balance sheet are using the key figure 0VAL_STOCK, which is a key figure with exception aggregation (last value with regard to 0FISCPER). This is necessary as balance sheet accounts have an opening balance that is calculated by adding the balance of the close of the previous year to the total for the period selected for the balance sheet.

To recap: Transaction data is loaded into SAP BW via the same methods that were used prior to the release of the BI Content 3.2 Add-On. One of the two newly delivered virtual InfoCubes (which call the forementioned new function module) then reads the data from the InfoCubes that have been loaded with transaction data, calculates the data on the fly, and aggregates/displays the data according to the logic embedded in the master data. Data is not physically rewritten during this process.

Query Definition and Analysis

The final step in producing a balance sheet query that displays a hierarchy with balance-dependent nodes is to actually create a query and execute it for analysis. Two queries (0FIGL_VC1_Q0001 and 0FIGL_VC2_Q0001) are available with the BI Content 3.2 Add-On for the virtual InfoCubes. You can use them as templates. The query is defined using one of the virtual InfoCubes as the InfoProvider. The characteristic InfoObject 0GLACCEXT (financial statement item) along with its associated hierarchy must be in the query definition (Figure 5). The key figure InfoObjects 0VAL_FLOW (in P&L queries) and 0VAL_STOCK (in balance sheet queries) must also be included in the query definition.

Figure 5

The characteristic InfoObject 0GLACCEXT along with the hierarchy associated with it must be in the query definition as well as the key figure InfoObjects 0VAL_FLOW (in profit/loss queries) and 0VAL_STOCK to produce a balance sheet query with hierarchies featuring balance-dependent nodes.

Execute the query and view the results. With the launch of BI Content 3.3 Add-On, which became available in October 2003, the balance sheet and P&L statement is automatically available for SAP BW Web applications. Prior to the BI Content 3.3 Add-On, presenting a balance sheet or P&L statement in SAP BW Web applications required implementing SAP note 580892.

For more information, see the document “Financial Statements in the SAP BW System” in the SAP Help Portal.