SAP BusinessObjects Planning and Consolidation projects are more susceptible than most SAP NetWeaver BW implementations when it comes to neglecting data integration. This is not only because SAP positions SAP BusinessObjects Planning and Consolidation as an application that the business (usually the finance department) can own, but also because much more business process integration needs to be addressed to deliver an SAP BusinessObjects Planning and Consolidation project successfully. Anyone who has implemented SAP ERP knows that even in an enterprise application designed for end-to-end integrated business processes, a great deal of time is spent data mapping within and between SAP modules — whether it is different functional teams arguing over the material master views, the sales and distribution (SD) team deciding how to design its sales areas, or the Financial Accounting (FI) team deciding how to map its chart of accounts to logistical processes. Yet many SAP BusinessObjects Planning and Consolidation projects treat data mapping as a simple file download-and-upload exercise, trivializing the differences in business process conventions between source and target. These conflicts can make the data integration task into SAP BusinessObjects Planning and Consolidation a complex and potentially costly endeavor. SAP ERP rules conventions are often different from what is required in SAP BusinessObjects Planning and Consolidation because they were designed for different processes. Currency conversion in SAP ERP, for example, may be different from the currency conversion process in SAP BusinessObjects Planning and Consolidation where a fixed currency conversion rate might be used for planning to exclude currency fluctuations, or where currency conversion is performed to fulfill special requirements of the legal consolidation process. Therefore, it is paramount for the success of any enterprise-wide SAP BusinessObjects Planning and Consolidation project that the hidden complexities of data integration are visible so you can plan for and design them into the solution. Data integration has two facets:

• Technical integration: Load data technically from a given system into SAP BusinessObjects Planning and Consolidation
• Semantic integration: Ensure that the data loaded into SAP BusinessObjects Planning and Consolidation is correct, valid, and meaningful in the business context of planning and consolidations

For more information about the differences between these two types of integration, see the sidebar “The Difference Between Technical and Semantic Integration.”

Semantic Data Integration Examples

The challenge with semantic data integration is that it is often specific to your organization and the goal of your SAP BusinessObjects Planning and Consolidation project. The following are two real business requirements for SAP BusinessObjects Planning and Consolidation and the corresponding semantic data integration questions.

• Semantics of bringing SAP ERP assets into SAP BusinessObjects Planning and Consolidation
• Semantics of SAP ERP gross margin data in SAP BusinessObjects Planning and Consolidation

Whether for consolidation, balance sheet planning, or depreciation planning as part of operational expenditures (OPEX), most likely you need to bring fixed assets data into SAP BusinessObjects Planning and Consolidation. However, loading assets from SAP ERP into SAP BusinessObjects Planning and Consolidation might be more challenging than just running an SAP ERP asset report, saving it as a flat file, and loading this file into SAP BusinessObjects Planning and Consolidation using Data Manager. One of the biggest semantic integration challenges might stand in the way: mapping different financial accounting conventions such as US Generally Accepted Accounting Principles (GAAP) to International Financial Reporting Standards (IFRS). This topic will gain momentum as the Securities and Exchange Commission’s (SEC) proposed milestones approach. If you happen to be in a situation in which your SAP ERP system is using US GAAP accounting, but SAP BusinessObjects Planning and Consolidation will be based on IFRS, then loading asset data will definitely involve more than just a flat file upload. The semantics of asset recognition for depreciation, for example, are very different. US GAAP generally does not require the component approach for depreciation. Under IFRS, however, asset componentization requires you to track and account for property, plant, and equipment at a more disaggregated level. Let’s look at an example. In the oil and gas industry, large assets are comprised of a large number of components. Many of those have different useful lives. Take pipelines, for example. Since US GAAP does not require the component approach for depreciation, an oil company may account for its pipeline in, say, 100-mile chunks: Each 100 miles of pipeline is a separate asset. Under IFRS, that would not be allowed because the assets need to be componentized by useful life. Therefore, the actual pipe, the bolts, the gaskets, and the valves may all have different useful life times and thus would have to be accounted for as separate assets. Simply loading the SAP ERP assets into SAP BusinessObjects Planning and Consolidation would not deliver any benefits to your SAP BusinessObjects Planning and Consolidation implementation. The assets would actually have to be componentized first to make semantic sense in SAP BusinessObjects Planning and Consolidation. The task of loading assets from SAP ERP into SAP BusinessObjects Planning and Consolidation — while technically relatively simple — might present a huge semantic challenge if your SAP ERP system is on US GAAP while your SAP BusinessObjects Planning and Consolidation system consolidates according to IFRS. The next example may not be as complex as a US GAAP-to-IFRS conversion, but it shows how important it is to equip the SAP BusinessObjects Planning and Consolidation system with the data that end users expect to see. It illustrates two different types of semantic integration:

• Business rule challenges
• Data mapping challenges

Consider the SAP ERP postings in Table 1.

SAP ERP account January 2009 February 2009 March 2009 Shipping and handling $100 $50 $100 Revenue $1000 $1000 $1000 Discounts $300 Cash discount $10 Returns $200 Cost of goods $300 $300 $300 Total Margin $790 $550 $500
Table 1	SAP ERP source data

This data should be loaded into SAP BusinessObjects Planning and Consolidation against the following SAP BusinessObjects Planning and Consolidation accounts:

• Sales
• Discounts
• Cost of goods

You can define SAP BusinessObjects Planning and Consolidation accounts per your business requirements — the three accounts in Table 1 are just examples. I kept it simple to illustrate the mapping of granular SAP ERP operational accounts to higher-level accounts for planning. The first question is: How do you map the more granular SAP ERP accounts to the high-level SAP BusinessObjects Planning and Consolidation account structure that is used for planning and performance management? The answer depends on how an organization plans and reports, so there is no right or wrong answer. In this example, let’s assume it makes the most business sense to map as shown in Table 2.

SAP ERP account SAP BusinessObjects Planning and Consolidation account Shipping and handling Sales Revenue Sales Discounts Discounts Cash discount Discounts Returns Sales (as negatives) Cost of goods Cost of goods
Table 2	Mapping between SAP ERP and SAP BusinessObjects Planning and Consolidation accounts

I made three business assumptions in mapping this way:

• Shipping and handling is considered part of the sales revenue stream
• Returns diminish the sales revenue
• Returns do not reduce the cost of goods

Depending on the business in question, these assumptions may or may not make sense. Therefore, it is important to include the definition of business semantic mapping of accounts (and other data elements such as customer, materials, and entities) into the SAP BusinessObjects Planning and Consolidation design. By defining the mappings per Table 2, the data aggregates as shown in Table 3 when it is loaded into SAP BusinessObjects Planning and Consolidation.

SAP BusinessObjects Planning and Consolidation account January 2009 February 2009 March 2009 Sales $1100 $850 $1100 Discounts $10 $300 Cost of goods $300 $300 $300 Total Margin $790 $550 $500
Table 3	The SAP ERP source data mapped to the SAP BusinessObjects Planning and Consolidation accounts

The second question is the business rule challenge: The $300 discount in March 2009 turns out to be a quarterly discount of 10% for customers reaching a certain order volume. Thus, it is misleading to apply the $300 all in March (even though they are booked this way in SAP ERP). For management reporting and planning, the $300 should be evenly split across the months of the relevant quarter (i.e., $100 per month). Since it was not certain until March whether the customer would actually get the discount and how much it would be, it’s difficult to account for that up front in the months of January and February. Spreading the $300 discount in SAP BusinessObjects Planning and Consolidation across January, February, and March leads you to the picture in SAP BusinessObjects Planning and Consolidation in Table 4.

SAP BusinessObjects Planning and Consolidation account January 2009 February 2009 March 2009 Sales $1100 $850 $1100 Discounts $110 $100 $100 Cost of Goods $300 $300 $300 Total Margin $690 $450 $700
Table 4	Data in SAP BusinessObjects Planning and Consolidation after discount is distributed

  Table 4 is what the user would expect to see in SAP BusinessObjects Planning and Consolidation. Simply uploading the raw data of Table 1 into SAP BusinessObjects Planning and Consolidation would not achieve this. You need to define and apply standard business rules and data mappings (which carry the three implicit business assumptions as laid out above) to make the data semantically meaningful for the business user in SAP BusinessObjects Planning and Consolidation across the enterprise.

Common Requirements and Semantic Integration Scenarios

Semantic data integration is challenging because there are no universal right answers. What’s right depends on your organization and on the goals that you try to achieve with your SAP BusinessObjects Planning and Consolidation application. Awareness of these semantic integration challenges is critical for the success of any SAP BusinessObjects Planning and Consolidation project. The challenges need to be communicated to business and IT to ensure the business users define them in a standard way and implement them correctly in SAP BusinessObjects Planning and Consolidation. Failure to do so results in incorrect or meaningless data in SAP BusinessObjects Planning and Consolidation. Now I will shed light into some hidden pitfalls of data integration by listing features that are frequently expected from SAP BusinessObjects Planning and Consolidation solutions. Common business requirements are followed by the associated semantic data integration challenge.

Requirement 1: Single Source of Truth for Planning and Forecasting

The single source of truth — the notion of one forecast or single-figure forecast is often debated when implementing SAP BusinessObjects Planning and Consolidation. At a high level, having one sales forecast makes a lot of sense. However, in reality, different departments often have different forecasts based on their needs (both functional and political). It is not uncommon to find a marketing forecast, a sales forecast, a revenue plan, and a demand plan all showing different numbers for next year’s expected sales. Taking a closer look one often finds that the plans are constructed in very different ways. Table 5 provides an example of how five different departments might go about creating their plan — illustrating the different methods they use to come up with the initial plan, the dimensions and key figures they are interested in, the time horizon, and the organizational entity by which they plan.

Department Plan based on Dimensions planned Key figures Time horizon Organizational entity Manufacturing Purchase orders Product SKUs Order quantity Short term Plants Sales Relationship with key accounts Customers, channels, and products Sales dollars Quarterly focus Sales force Finance Invoices Product lines and customers groups Revenue, discounts, rebates, and margin Annual focus Responsibility centers Marketing CRM, syndicated data, market assumptions, and surveys Customer segments, brands, and categories Share, penetration, promotion lifts, and development indexes Short- to mid-term Segment or account Research and development Studies, panels, and market research Projects and products Diffusion rates, penetration, repeat purchases, and preference Long-term Product lines

Table 5

Five methods to create a plan

These different methods and semantics usually lead to different plan numbers and thus impose a big challenge to the goal of having SAP BusinessObjects Planning and Consolidation contain the single forecast figure. To get the different departments to agree on one number, their different planning processes, methods, and semantics would have to come together. This is known as a consensus forecasting process. Without this change, the forecast number in SAP BusinessObjects Planning and Consolidation cannot become the single source of truth. Let’s look into this a little more by using the finance and manufacturing department as examples.

Requirement 2: Base SAP BusinessObjects Planning and Consolidation on the Demand Plan

The requirement to integrate manufacturing’s demand plan with the finance plan is frequently cited in SAP BusinessObjects Planning and Consolidation projects. In an SAP-centric environment, this boils down to the requirement of loading SAP Advanced Planning & Optimization (SAP APO) data into SAP BusinessObjects Planning and Consolidation. It is possible to use Data Manager to technically load a purchase order-based SAP APO unit plan by plant and SKU into SAP BusinessObjects Planning and Consolidation. Most likely this data is of little use for a finance community interested in comparing actual invoices with business units’ revenue plans in local currency and dollars, including discounts and rebates given to specific customers. Also simply dollarizing the demand plan — meaning multiplying the units by the sales price — may not yield the desired result for multiple reasons:

• What are the sales prices? Who defines them? Do you use historic average sales prices (ASPs) or do you leverage a pricing engine?
• How do you convert the manufacturing plant-based plan into one that pertains to business units?
• How do you add customers to the SAP APO plan?
• Finance compares the plan to invoices — not to purchase orders on which the SAP APO plan is usually built. Unfulfilled orders or items that fell off the truck are being planned for in the plants, but the finance community is not interested in them in their sales number because they do not generate revenue. Conversely, manufacturing does not really care about discounts and rebate billings, but finance needs to account for them when projecting revenue.
• How do you handle divested businesses for which you still produce? They are usually not part of the business unit revenue stream any more, but plants still forecast their production.
• How do you handle intercompany revenue in planning? Do you want to plan for intercompany sales? SAP APO does usually not contain this information.

Unless your organization answers these questions and adopts the planning process accordingly, loading SAP APO quantities into SAP BusinessObjects Planning and Consolidation is of little value. One possible solution in the next section takes time and technical and business resources. Also, it involves changing processes and systems other than just SAP BusinessObjects Planning and Consolidation. Imagine this possible SAP APO-to-SAP BusinessObjects Planning and Consolidation integration scenario: The finance community starts its planning process in SAP APO. The SAP APO system is enhanced to contain customer data along with product details. An entity representing the business unit — along with the plant — is added to SAP APO. This entity is based on the SAP ERP profit center. To integrate SAP APO and SAP BusinessObjects Planning and Consolidation forecasts semantically, you then implement the process of consensus forecasting between finance and manufacturing. For more information about support for consensus planning in SAP APO see “Reconciliation of Demand Plans” in SAP Help. The resulting consensus forecast data is loaded into SAP BusinessObjects Planning and Consolidation, where it is dollarized based on historic average sales prices per product. The ASPs are calculated based on SAP ERP SD actuals data loaded into SAP BusinessObjects Planning and Consolidation. The SD actuals are used to adjust the plan to account for the order-to-invoice differences. SD data is also the basis for finance users to plan discounts and rebates in SAP BusinessObjects Planning and Consolidation. Planning for intercompany revenue is done in SAP BusinessObjects Planning and Consolidation only, based on mapping trading partner data in SAP ERP Financials to the SAP BusinessObjects Planning and Consolidation intercompany dimension. The result of this process is a clear link between the manufacturing and financial plan. This helps avoid costly problems such as out-of-stock situations or inventory pile-ups due to different numbers in the sales and production/demand plans.

Requirement 3: Enable Price-Volume-Mix Variance Reporting

The previous section hinted at the use of SD-invoice data directly (or indirectly through the SAP ERP Profitability Analysis module [CO-PA]) in SAP BusinessObjects Planning and Consolidation as the basis of a company’s sales and revenue. While this billing data is the source of revenue in SAP ERP, it usually involves more than just a Data Manager upload to SAP BusinessObjects Planning and Consolidation to get the data semantically right (even assuming SD or CO-PA are configured properly). Here are some things to think about up front:

• SD data alone may not give you the correct revenue number. Often revenue is adjusted using SAP General Ledger journals (e.g., to account for discounts). Thus, you may a need to combine SD billing postings with SAP General Ledger journals to get to the revenue number that users expect to see.
• The SD invoice contains sold quantities. Sales volume can be very useful for price-volume-mix or market share analysis, or to calculate average sales prices. Be aware though that SD contains the unit of measure in which the item was sold. Simply loading this into SAP BusinessObjects Planning and Consolidation results in a mix of boxes, eaches, pallets, pieces, and cartons. To make proper use of the volume information, you may have to perform unit conversions based on the SAP ERP material master. SAP NetWeaver BW (or CO-PA) offers standard functionality you can use to harmonize the units before loading the data into SAP BusinessObjects Planning and Consolidation.
• SD invoices are usually far too granular for SAP BusinessObjects Planning and Consolidation. You might want to consider a staging application (in CO-PA or SAP NetWeaver BW) to pre-aggregate the data before presenting it to SAP BusinessObjects Planning and Consolidation users. Otherwise performance in SAP BusinessObjects Planning and Consolidation can be very poor.
• Another important topic is intercompany invoices. Are they part of your organization’s revenue plan? If not, intercompany billing revenue needs to be identified and excluded before SD data is loaded into SAP BusinessObjects Planning and Consolidation.

Keep in mind that SAP ERP has many other potential sources of revenue in addition to SD or CO-PA such as Profit Center Accounting (EC-PCA), Special Ledger (FI-SL), SAP General Ledger, and Sales Information System (SIS). Depending on what you use as the source of truth in your organization, it may be one of those applications rather than SD transaction data that should be staged into SAP BusinessObjects Planning and Consolidation. Investigate carefully what your data source should be for SAP BusinessObjects Planning and Consolidation.

Requirement 4: Make Data Available in the Local Currency

This requirement is common and sounds like a no-brainer. However, when taking a closer look, the question of which exchange rate to use arises. Do you want to convert at a spot rate, a monthly average rate, or at constant currencies using a frozen exchange rate to eliminate currency conversion fluctuations from your performance management reporting? Especially when using a fixed exchange rate, the topic of restatements arises: restating historical results at the current frozen exchange rate. Basically, for a past transaction from 2008, you’d like to see three records in SAP BusinessObjects Planning and Consolidation to compare 2008 and 2009 data:

• Transaction in local currency
• Transaction in USD at 2008 rate
• Transaction in USD at 2009 rate

SAP BusinessObjects Planning and Consolidation only allows you to enter one conversion rate per account. To circumvent that, you can use different SAP BusinessObjects Planning and Consolidation categories. However, that means that you need to create custom logic code to generate local currency records in different categories, or that you need to create custom logic code to generate data on the fly. Another option is to use SAP BusinessObjects Planning and Consolidation Currency Conversion Business Rules. The hidden complexities of currency conversion are discussed in detail in the IT article “Navigate the Complexities of Currency Conversion for More Accurate Management Reporting.” To ensure the scope of your SAP BusinessObjects Planning and Consolidation project does not increase significantly, be sure to flush out the exact requirements for currency conversions and evaluate them against SAP BusinessObjects Planning and Consolidation’s two methods for currency conversion — FXtrans logic and SAP BusinessObjects Planning and Consolidation Business Rules.

Requirement 5: Allow Drill-down by Product and Customer

Business users frequently ask the following question: “Once we have SAP BusinessObjects Planning and Consolidation, can we drill down to the SKU level or customer detail?” This question is really not about SAP BusinessObjects Planning and Consolidation functionality, but about data design: Does your application source for SAP BusinessObjects Planning and Consolidation contain customer- or SKU-level detail? If not, then neither SAP BusinessObjects Planning and Consolidation nor any other reporting tool allows you to report by SKU and customer detail. If your source of data is SAP (e.g., SD data) then customer and SKU (i.e., SAP Material Number) are available. The next question to answer is the semantic integration question: What do users mean when they say “customer”? Do they mean SAP ERP bill-to, ship-to, or sold-to business partner function? A marketing person might be thinking of an SAP Customer Relationship Management (SAP CRM) business partner when he talks about a customer. Defining what SAP ERP data element is meant by “customer” drives the data mapping exercise to SAP BusinessObjects Planning and Consolidation. Usually planners do not want to plan at a sold-to customer level, but expect to see just one line for all the different sold-tos for a specific customer. Often companies want to group customers in SAP BusinessObjects Planning and Consolidation using hierarchies to allow for effective revenue forecasting. Defining a new customer hierarchy for SAP BusinessObjects Planning and Consolidation is usually not trivial and takes time and data ownership. The requirements around customers can lead to a lot of work that needs to be planned for in your SAP BusinessObjects Planning and Consolidation project. In contrast to the case of “customer,” it is usually pretty clear what a user means when he asks for SKU level detail. In SAP data, a SKU refers to the SAP ERP material number. Although the mapping is initially clear, some other questions should be investigated. For example, which materials should actually be loaded into SAP BusinessObjects Planning and Consolidation? Usually the material master in the SAP system contains hundreds of thousands of materials, but very few of them are relevant for sales planning. Raw materials, semi-finished goods, and work in process (WIP) are seldom relevant to sales planning. Only materials that are actively sold play a role — which may just be 5% or 10% of your material master if you are a manufacturer with large bills of material (BOMs). Rather than loading all materials into SAP BusinessObjects Planning and Consolidation, you should identify the actively sold materials first (e.g., by investigating which material numbers appear on SD invoices in the last year or two). In addition to the active materials, you might want to plan for new materials in SAP BusinessObjects Planning and Consolidation yet to be defined in SAP ERP. Those have to be added to the material dimension in SAP BusinessObjects Planning and Consolidation with governance and integration implications for SAP ERP material master maintenance in case these materials become real. With SAP BusinessObjects Planning and Consolidation now holding just a fraction of your material master, but with some additional SKUs for new materials, it is clear that the SAP product hierarchy cannot be transferred to SAP BusinessObjects Planning and Consolidation, but a new hierarchy needs to be created. Also, a product hierarchy geared toward planning might differ from the definition of your SAP ERP material hierarchy. That is another reason for investing time and resources to create an SAP BusinessObjects Planning and Consolidation product hierarchy that can bring together plan versus actual data. Before blindly loading your SAP ERP data straight into SAP BusinessObjects Planning and Consolidation, it might behoove you to take a step back and ask if it really makes sense. For example, as it relates to the SAP ERP material master: Does it really make sense to plan at a SKU level, or is it more suitable to plan at a higher level, such as product group or brand?

Requirement 6: Reconcile Master Data with SAP ERP

As seen in the previous section, master data loading may not be as straightforward as simply replicating the SAP ERP structures in SAP BusinessObjects Planning and Consolidation. This is especially true for the SAP BusinessObjects Planning and Consolidation entity dimension and the SAP BusinessObjects Planning and Consolidation account dimension. The account dimension technically translates a key figure-based model into an account-based, single-key-figure data model within SAP BusinessObjects Planning and Consolidation. It defines what the key figure actually represents (going beyond statutory accounts) — for example, revenue, headcount, sales quantity, or what SAP ERP might call statistical key figures that are stored separately from accounts. In addition, the account type property defines the SAP BusinessObjects Planning and Consolidation key figure’s signage and how it aggregates over time. The entity dimension defines the entity’s local currency (stored as the value LC in a field that SAP ERP would call a currency key for values such as USD and EUR). It sets the foundation for currency conversion in SAP BusinessObjects Planning and Consolidation. The entity dimension has a lot of application-specific process logic such as identifying process owners for status tracking. As a result, the roles of the account and entity dimensions are important in mapping data to SAP BusinessObjects Planning and Consolidation. Let’s look at the account first. One ubiquitous requirement in planning is the need to align all data with a single common chart of accounts. SAP ERP already has a well-defined chart of accounts, so it seems obvious that the SAP BusinessObjects Planning and Consolidation account dimension should simply be loaded from the SAP General Ledger account and it will reconcile to SAP ERP. Taking a closer at the SAP General Ledger presents a question right away: Should you map to the global accounts, the operational chart of accounts, the financial statement version, or an alternative set hierarchy? The operational or local chart of accounts is the account to which you posted in SAP ERP. It usually contains a level of detail not needed in planning. Another common challenge is that cost-of-sales financial statements don’t organize overhead costs by account groupings, but rather by business function such as:

• Administration
• Sales
• Marketing
• IT
• Research and development

SAP ERP meets these reporting needs by using another field called Functional Area instead of SAP General Ledger accounts (a subaccount concept foreign to SAP BusinessObjects Planning and Consolidation). If you prefer to plan your P&L in this common cost-of-sales format, mapping the SAP Functional Area to SAP BusinessObjects Planning and Consolidation accounts becomes vitally important. Another common example in which the intricacies of SAP data might interfere with a simple mapping of the SAP General Ledger accounts to SAP BusinessObjects Planning and Consolidation accounts is the area of assets and asset history sheet reporting. In SAP ERP, asset accounting leverages another subaccount field known as the SAP transaction type to classify additions and subtractions to accounts — for example, acquisition, retirement, or deprecation. Thus, simply mapping accounts may not be enough if you are interested in the breakdown of a fixed asset’s history from its opening balance through to the closing balance. When using the consolidation functionality of SAP BusinessObjects Planning and Consolidation, the Flow dimension is often used to model the transaction type. However, planning applications in SAP BusinessObjects Planning and Consolidation usually don’t use Flow. In planning SAP BusinessObjects Planning and Consolidation projects, you may need to combine a mapping of SAP General Ledger accounts with SAP transaction types to achieve similar reporting in SAP BusinessObjects Planning and Consolidation. As a matter of fact, an SAP ERP-to-SAP BusinessObjects Planning and Consolidation account mapping for P&L planning may not be based on SAP General Ledger accounts at all, but rather:

• CO-PA value fields for revenue, discounts, and cost of goods sold
• Function areas for cost center groupings such as marketing, sales, and administration

In this example, you could model SAP ERP cost elements for primary (i.e., SAP General Ledger relevant) and secondary (i.e., internal accounting only) postings such as expense lines (i.e., travel, salaries, and facilities) and allocations (i.e., assessed charges, production labor, and financial settlements) in a separate dimension in SAP BusinessObjects Planning and Consolidation. However, while this mapping might be ideal for planning and performance management in SAP BusinessObjects Planning and Consolidation, a legal consolidation project most likely requires a different mapping of the account dimension — based on the SAP ERP group or operational chart of account. For an example of how to map SAP General Ledger data to SAP BusinessObjects Planning and Consolidation to support consolidated financial reporting, see “How-to Get Balances from SAP ECC 6.0 for Consolidation in BPC 7.0 NW.” Now let’s look at the entity dimension. There are many SAP ERP data field candidates to be mapped to the SAP BusinessObjects Planning and Consolidation entity dimension including but not limited to:

• Cost centers or cost center groups
• Profit centers or profit center groups
• Business areas
• Company codes
• Plants or storage locations
• Sales organizations
• Divisions

What you need to map to your entity dimension is dependent on your project. SAP BusinessObjects Planning and Consolidation-specific considerations relate to workflow ownership structures and currency conversion requirements. Different implementation options accommodate various data mapping strategies, including:

• Using multiple entity hierarchies in SAP BusinessObjects Planning and Consolidation to roll up entities in different ways
• Creating additional custom entity dimensions to model more than one entity per record
• Using different SAP BusinessObjects Planning and Consolidation Application Sets to map the standard SAP BusinessObjects Planning and Consolidation entity in different ways

You also might want to plan against new entities that are not in SAP ERP yet or against hierarchical groupings that need a postable node value (i.e., a dummy leaf node underneath an SAP BusinessObjects Planning and Consolidation parent node). These design options raise SAP ERP integration challenges due to differences in hierarchy conventions between SAP BusinessObjects Planning and Consolidation and SAP ERP. While it seems desirable at first to have SAP BusinessObjects Planning and Consolidation dimensions reconcile with SAP ERP via one-to-one direct mappings, the reality is that the differences between SAP ERP transaction-based business processes and planning and financial consolidation processes may force you down the path of data mappings. What the business needs is outside the system: a definition of enterprise standards for data, processes, and mapping conventions for what I termed in this article “semantic integration.” Keep in mind that semantic data integration may be different for financial consolidation as compared to planning (and planning itself can take many forms).