Before business area consolidation can take place, you need to have manually assigned business areas and partner business areas during various posting procedures.

For information on business area assignments, refer to the corresponding FI documentation. Only partner business area assignments which are relevant to Consolidation will be described here.

Receivables and payables as well as revenue and expense within the scope of the group are eliminated on the basis of trading partner assignments. The term ‘trading partner’ has already been discussed in the consolidation of companies. The term ‘partner business area’ is used in the same sense in Business Area Consolidation. Every posting line of a group-internal, cross-company code or cross-business area business transaction therefore includes both the ‘assigned’ company code and business area as well as the respective trading partner combination. Both combinations also differentiate the debit/credit totals ledger, the data of which is transferred to Consolidation. Elimination documents are then created there for each occurrence of the combination, and in Reporting you can generate an eliminated representation within ‘subgroup creation.’ Within business area consolidation, subgroups are typically composed of all consolidation units within one consolidated business area.

A partner assignment is not always required, since not all consolidation postings generated by group-internal transactions must be re-eliminated in consolidation. Two examples where no partner assignment is necessary are payment entries and transfers of assets (fixed and current). A characteristic of the document type determines whether the partner assignment is required: When posting with a trading partner, a partner business area is required on all line items that are not open-item managed if the document type has been specially flagged. When posting without a trading partner, manual entry of a partner business area is ignored (removed). When posting mere G/L account entries, the partner business area is automatically set from the listed business areas by ‘checking’.

To avoid always having to enter the right partner assignment when processing a business transaction, the main objective is to provide an automatic assignment whenever possible. In this matter there are basically two types of business transactions:

• Those where during business transaction entry both sides of the transaction - yours and your partner’s - are posted. Company code-internal business area transfers, as an example, are one of these transactions. In cross-company code transaction entry, which is internally split into two accounting documents, each individual document belongs to this type. When entering this type of transaction the clerk knows the assignments for the one as well as for the other ‘side’ and can therefore always specify the other business area as a partner.

• Those where a business transaction includes two entries which are made by different persons at different times, whereby the user is only familiar with his/her side of the transaction. A typical example is cross-company (group-internal) purchase including outgoing and incoming invoices. The purchaser sometimes does not know the business area from which the vendor is going to deliver, and more often, the vendor does not know the purchaser’s business areas to which the received goods or services will be applied - especially if the order was not made for storage but instead, say, on a cost center or on account.

The following sub-sections now illustrate the most important business transactions - each divided into its major area of application - regarding the assignments of partner business areas.

This section discusses the following FI transactions with regard to the assignment of partner business areas:

• Invoices from external vendors over multiple business areas

• Invoices from group-internal vendors over multiple business areas

• Company code-internal business area transfers for G/L accounts

• Cross-company code invoice entry

The objective here is to illustrate exceptions, which (a) the user must be aware of, (b) must be taken into consideration in organizational procedures, or (c) must even be restricted during document entry.

The user must enter the business area in the G/L line items. The vendor line item is entered as a whole, without a business area. The partner business area is irrelevant for external invoices and is thus not set. A breakdown adjustment entry is made periodically for the original business area in the ‘balance sheet subsequent debit’ program.

The trading partner is read from the vendor master record and is set automatically in the vendor line item as well as all offsetting G/L entries. The business area is treated as in the above case: manual entry in the G/L line items and automatic, periodic breakdown of the vendor entry according to the G/L line items in the ‘balance sheet subsequent debit’ program. An exception is the manual assignment of partner business areas. You must ensure that the user knows the business area of the supplying member-company and manually enters it into each G/L line item.

Take, as an example of this case, the processing of a revenue entry in business area A against two expense entries in business areas B and C, all within one company code: The business area and the partner business area is manually entered in all three line items. The zero balance for the business areas is generated by the periodic adjustment entries.

Please refer to the FI manuals with regard to the various types of cross-company code posting on the same system or also system-to-system via EDI. Concerning partner business areas, if the situation arises in which essentially one user processes the entire business transaction, he/she must also know the business area of the other company code. It is important that the user always specifies local business areas - even if they refer to another system. This is also true if the business area does not initially exist in the local system.

The Purchasing transactions

• Order

• Goods receipt

• Invoice receipt

are discussed in this section with regard to (group-)member vendors. These are transactions which must be processed by multiple users (clerks) within a delivery/service chain, and which are often processed on multiple, separate systems - if you also include the vendor’s activities.

In order to assign partner business areas in Purchasing you must know the business area from which the vendor will (presumably) provide the goods or service. The following solution is offered for a ‘central scenario’ in which the delivering partner has also implemented the same SD system:

At the time of the goods receipt entry and the invoice receipt, the vendor’s business area is determined using the vendor’s SD customer order that corresponds to the purchaser’s own MM order. The business area is then entered as the partner business area.

As with the business transactions in Purchasing, the Sales side also has transactions that need to determine and assign a partner business area for the group-internal customer. The following transactions are of particular interest:

• Processing the customer order

• Processing the goods shipment

• Processing the outgoing invoice (Invoicing)

The user initiating the incoming order usually has limited access to information about the customer’s use for the product. Even if group rules dictate the specifications for use on the order, changes can still take place afterwards.

For this reason, the concept of determining partner business areas in a central system – analog to the purchasing side – ensures that the MM purchase order of the group-internal customer is accessed.

Therefore, the respective partner business area is derived if the goods shipment or the outgoing invoice process creates posting documents on the basis of the customer purchase order. At the same time, the SD system derives its own business area - from where the goods are shipped - from the sales area. The program RFGAUF00 reprocesses the accounting document if the customer line item needs to be broken down according to the business areas of the offsetting entries.

This section investigates several goods movement transactions, their partner business area assignments and any elimination requirements. We will discuss in particular:

• Stock transfers within a company code

• Stock transfers to other company codes

• Goods received via orders from affiliated companies

• Goods shipments to affiliated companies

• Withdrawals onto CO posting objects within the same company code

The assignment of business areas in the material master record as well as the CO posting objects (cost center, order and so on) plays a crucial role. The assignment is moved into the each respective line item. The programs always set the partner business area automatically, since these transactions only have a maximum of two business areas.

When stock is transferred from one plant to another, the business area for the respective inventory entries is derived from the combination of division (material master) and valuation area. A business area-coded accounting document is generated if the derived business areas differ - even if within a single valuation area. The program RFGAUF00 takes care of balancing the business areas on a periodical basis. Any price differences that occur are assigned to the receiving plant’s business area. In a separate ‘reversal document,’ the ‘Stock Transfer Revenue’ account inherits the business area from each inventory entry.

Unlike the company code-internal transfer, this transfer immediately generates two accounting documents where each inventory entry is posted against a company code clearing account. In both documents, the business area and the partner business area are only entered in the inventory entry, and not in the clearing entry.

The order is used to determine the assignment (material or CO posting object), which in turn is used to determine the business area. The business area is transferred to the inventory entry as well as to the clearing entry for the goods receipt or incoming invoice, and, if applicable, into freight clearing and price difference entries. The partner business area is determined as described above, and is transferred into all line items, in as far as these exist. Reversing entries post to ‘Stock Transfer Revenue’ without the partner business area. When posting the purchasing account, the same combination of business area and partner business area is applied to these line items as well.

When posting a goods shipment to an affiliated company, based on a packing slip for an SD order, the business area is determined by the sales area and the partner business area is determined by accessing the MM order. All line items inherit the assignment combination.

The inventory entry and the consumption entry determine their business area from the material division/valuation area and the CO posting object, respectively. For cross-company code withdrawals, two FI documents are already posted against company code clearing accounts. These clearing accounts are posted without the business area/partner business area. The receiving business area accounts for any price differences.

Cost Accounting includes the following controlling areas:

• Overhead cost management

• Product cost controlling

• Investment controlling

• Profitability analysis

Their account assignment objects are as follows:

• Cost center

• Overhead cost order

• Cost object

• Profitability segment

• Capital investment measure/order

• Project

• Production order

• Network

• Customer order for make-to-order production

These are each assigned to a unique business area - when using business area consolidation - which are then ‘inherited’ by each business transaction.

The business transactions can be divided up roughly into the following categories:

• ‘correctly’ assigned primary postings of FI
• summarized primary postings of FI onto clearing objects in conjunction with direct CO postings onto primary cost elements

• primary cost distribution within CO

• internal settlements via secondary cost elements

The first set of transactions is covered in detail in FI and does not need to be discussed again here. The second set includes, for example, the interface to Payroll Accounting. Payroll expenses are usually transferred directly onto primary cost elements in CO, according to cost centers, and are then summarized and posted onto a clearing account in FI (with a user-defined business area). Business Area Consolidation can naturally only use the exact business area assignment previously known in CO. You therefore have the option in FI to automatically transfer the summary account onto the individual business areas afterwards.

The same example basically applies to the third set of transactions. First, the primary costs are posted to a clearing object in FI which has been assigned to any business area. However, the user initiating this posting does not know how the amount is accurately distributed among business areas or CO posting objects. Later, these primary costs are divided up even further using distribution methods in CO. The depreciation of assets, which is used by various cost centers, is a good example for this. The AA system transfers the depreciation onto a clearing cost center without any knowledge regarding their further distribution. In this case it is also useful if the subsequent cost distribution in the CO system divides the original costing entry via an FI document.

The fourth set pertains to subsequent clearings of primary costs with the final receiver. However, these transactions do not directly credit the original cost element, but instead, credits and debits are made using secondary cost elements that do not have corresponding income statement accounts in FI. This kind of clearing transaction usually assesses multiple primary debits under a common credit cost element. The cost element changes its character during further clearing, and it you might will not want to further clear each of the original cost elements since, in most cases, the entire procedure may not be worth the effort involved.

From a business area consolidation standpoint, it is worth aiming to get a profitability analysis that is as accurate as possible in order to be able to also transfer the assessment into FI here. For this, it is necessary to reassign the secondary ‘transaction’ to an income statement account where posting then takes place. Account determination focuses on the following transactions:

• Assessment

• Activity assignment

• Settlement, and so on...

The high level of detail in CO concerning business area assignments is primarily stored by CO posting object in the transaction data and totals records. A selection program and - starting with Release 3.0 - realtime updates can then take this data and create a ‘reconciliation ledger,’ which builds a bridge between the FI totals databases and the CO totals records according to controlling area.

The reconciliation ledger basically has the following structure:

• fiscal year

• version

• company code

• business area

• cost element

• controlling area (overhead cost management/investment control and so on)

• object type (cost center, order and so on)

• partner company code

• partner business area

• partner controlling area

• partner object type

Business area consolidation provides a transfer program that allows you to selectively generate FI postings from the reconciliation ledger via batch data transfer. First, you decide in Customizing which cost elements are to be processed. Which cost elements are to be disclosed on the consolidated statement depends on whether business area consolidation is aimed at meeting either legal or internal management requirements. In Customizing you also determine a document type to be used for posting in FI. The reconciliation entry is triggered through its own ‘transaction’ and updates values in FI as well as in the reconciliation ledger.

The following overview shows postings being transferred from CO to FI: