Implementation Guide and System Settings 

Use

Before you use the R/3 System, you must configure it to your specific requirements and organizational structures. This involves setting a large number of parameters that must be complete and consistent.

To enable you to do this easily and systematically, the Implementation Guide (IMG) offers a framework for the configuration functions. The IMG is divided into central and component-specific system configuration functions.

Furthermore, when the SAP R/3 System is operating, you must make continual adjustments and changes that are carried out using the function Environment Update settings found in the menus of the corresponding application components.

If system configuration is required for a new release (wide-ranging functional expansion of the R/3 System) or for an upgrade (limited program corrections and enhancements), you also carry this out with the aid of the IMG.

Customizing, then, is a central means of system administration and maintenance used for:

R/3 System implementation and configuration

Ongoing R/3 System maintenance

Release changes and system upgrades

Features

The aim of a central system administration is to provide a user-friendly way of adapting the SAP R/3 System to the individual needs of each organization. With the aid of the Implementation Guide (IMG), you can completely maintain all R/3 System configurations.

You use the IMG to configure your organization’s specific structures.

This task is simplified by the hierarchical subdivision of the IMG:

You set cross-component defaults, such as the assignment of organizational units.

After general Customizing, you make Customizing settings for specific application areas.

The IMG activities are structured in the order that they are to be processed.

You make the settings necessary for Controlling (such as, defining the cost center categories in your organization) with the IMG for the Controlling component (CO).

In the IMG you can:

Display information necessary for R/3 System configuration

Branch to the relevant Customizing transaction and make the necessary settings

SAP provides an Implementation Guide IMG, which you can use for Customizing in all components. You can adapt this SAP Reference IMG according to your requirements:

You can use the reference IMG to create a customer-specific IMG containing only the applications and country-specific data you wish to use.

The Enterprise IMG can be further subdivided into Project IMGs. To do this you select from more functions and countries.

You can create a release-specific IMG containing only those parts of the customer-specific or project IMGs for which release information is available.

In each project IMG you can create specific views in order to reduce the number of implementation activities:

Mandatory activities must be executed before the production start. The R/3 System standard settings are usually adapted to meet each customer’s requirements.

Optional activities need not be included for a productive start. SAP recommends checking the standard R/3 System standard settings. Customer-specific adjustments may be necessary, depending on the given requirements.

Non-critical steps contain activities that need not be included for a production start. Checking the SAP R/3 System standard settings is not necessary. SAP recommends adopting the standard R/3 System standard settings. Customer-specific adjustments are rarely needed and should be made only with the aid of an SAP consultant.

Critical steps demand special caution because errors can have far-reaching consequences requiring a great number of corrections.

Before you begin using the SAP R/3 System, you should edit the system settings and maintain the corresponding parameters for the necessary parts of the R/3 System. For more information, see the relevant sections in the IMG and make the system settings.

Before you create master data for cost centers, read Cost Centers in the IMG

for Controlling and make the relevant configurations.

You can change and maintain some configurations in a productive system by choosing Environment Update settings. From there you can access the corresponding sections of the IMG.

For more information, see the R/3 Library under BC Basis  Business Engineer  Configuration

Tools  IMG ( See also:  Implementation Guide (IMG)).

 

 

 

 Controlling Organization 

Use

Using the R/3 System, you can define each of the organizational units in your organization from the perspective of an SAP application component.

In the integrated R/3 System there are direct links between internal and external accounting. This is also reflected in the relationships of the organizational structures of Controlling (CO) and Financial Accounting (FI).

You define the organizational structure in the Financial Accounting component (FI) from an external accounting perspective.

You define the organizational structure in the Controlling component (CO) from a managerial accounting perspective.

Since the R/3 System is fully integrated, you must define the organizational structure on a cross-component basis.

You assign organizational units from the Financial Accounting component to the units in the Controlling component. This enables you to transfer cost-accounting-relevant postings to Controlling.

The following sections describe the organizational units used in the Controlling component (CO) and those from other components linked to the Controlling organizational units. You cannot define these organizational units separately from one another.

Cross-component relationships exist between the following organizational units in internal and external accounting:

Company code in the Financial Accounting component (FI) Business area in the Financial Accounting component (FI) Controlling area in the Controlling component (CO)

 

 

 

 Company Code 

Definition

The company code is the smallest independent unit representing a closed financial accounting system in an organization. This involves the recording of all relevant transactions and generating all supporting documents for financial statements, such as balance sheets and profit and loss statements.

 

 

 Controlling Area 

Definition

The controlling area is an organizational unit that represents a closed system used for cost accounting purposes. A controlling area may contain one or more company codes, which can operate in different currencies, if required. The company codes within a controlling area must all use the same operational chart of accounts.

All internal allocation transactions refer only to objects from the same controlling area.

Use

Internal business transactions are portrayed in the controlling area. Primary costs are transferred from external accounting and classified according to managerial accounting perspectives. If the primary cost are direct costs, they are assigned directly to cost objects; if they are overhead costs, they are assigned to cost centers or internal orders and allocated further using internal allocation methods.

Both organizational units are assigned when you create master data. Controlling objects are assigned to a controlling area and a company code at the same time.

The level of detail provided by the Controlling component enables you to track specific information for cost monitoring, business decisions and sales control. For example, the Controlling component contains subdivisions such as cost centers and internal orders in addition to accounts.

 

 Business area 

Definition

The business area is an organizational unit in external accounting. It corresponds to a separate operational or responsibility area in the organization and value flows recorded in Financial Accounting can be assigned to it.

Use

Business areas are used primarily in segmented external reports dealing with significant areas of the organization, such as product lines and branch offices, that cross company code boundaries. Segments can be defined as an isolable operational field in the organization

If you want to create business area balance sheets for internal reporting purposes, you must maintain the business area within the Controlling component as well. This means that when you create cost center master records you must specify the business area. CO objects, such as cost centers and internal orders, function as account assignment aids since the business area can be derived from the master data records. When you post primary costs to a cost center, for example, the R/3 System determines the business area automatically from the cost center master data. This enables the costs to be assigned to the correct business area. Therefore, you do not need to manually set the business area in the posting document, as it can be set automatically by the system This reduces the number of incorrect assignments to a minimum.

 

 

 Operating Concerns ?

Definition

The operating concern represents a part of an organization for which the sales market is structured in a uniform manner.

Use

Individual marketing segments, defined by a combination of classifications (such as product group, customer group, country, and distribution channel), are used to calculate operating profit by comparing costs and revenues.

Integration

One or more controlling areas can be assigned to an operating concern.

 

 

Profit Centers 

Definition

A profit center is an organizational unit in accounting, which classifies the organization from a management perspective, that is, for the purposes of internal control.

You can display results for a profit center, which are calculated using cost-of-sales and/or period accounting.

 

Plants 

Definition

A plant is an organizational unit in logistics, which classifies the organization from the production, procurement, maintenance and materials planning perspectives.

A plant is where materials are produced or goods and services are provided.

Integration

The R/3 System assigns a plant to a company code based on the valuation area, and thereby, also to a controlling area.

See also:

Assigning Controlling Areas and Plants .

 

 

 Assigning Company Codes and Controlling Areas 

Use

Company Code and Controlling Area can be combined in a number of ways. Using these combinations you can represent organizations with varying structures.

 

One Company Code Assigned to One Controlling Area

In this example, the financial accounting and cost accounting views of the organization are identical.

Multiple Company Codes Assigned to One Controlling Area

This example is described as Cross-Company Code Cost Accounting. Cost accounting is carried out in multiple company codes in one controlling area. All cost-accounting relevant data is collected in one controlling area and can be used for allocations and evaluations. Here, the external and internal accounting perspectives diverge.

This method can be used if, for example, the organization contains a number of independent subsidiaries using global managerial accounting. Cross-company code cost accounting gives you the advantage of using internal allocations across company code boundaries.

 

 Assignment of Plants and Controlling Areas 

Use

The Plant is an organizational unit in Logistics. A valuation at plant level is required for material cost estimates and order costing.

The valuation of material stock is made either at plant or company code level.

To valuate the materials in a plant you need to assign each plant to a valuation area. From an accounting perspective, each valuation area is assigned to a company code. As the assignment between company code and controlling area is always unique, the SAP R/3 System can derive the corresponding controlling area from the assignment made between plant/valuation level/company code.

 

 

 Processing Controlling Areas 

Purpose

This section describes how the Controlling Area is processed to depict the organizational structure from the Controlling viewpoint.

Prerequisites

Before you can create a controlling area, you must already have created in FI the company codes and business areas to which you want to assign to.

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Organizational Structure of Financial Accounting (see:  Organizational Structure of Financial Accounting).

Process Flow

You make these settings for the controlling area using the Implementation Guide (IMG).

In the IMG for Controlling General, see the section Organization  Maintain controlling area (see: Maintain Controlling Area).

1. Define the controlling area and enter the cost-accounting relevant basic data.

(see: Creating or Changing Controlling Areas, Editing Assignment Control, Currency, Chart of Accounts, Fiscal Year Variant, Defining the Cost Center Standard Hierarchy, Activating the Reconciliation Ledger, Defining the Distribution Method and the Logical System).

2. Activate the required subcomponents of the Controlling component (CO) – Cost Centers, Order Management, Profitability Analysis, and so on (see:Subcomponents).

3. You can save additional control information (see: Control Indicators).

4. Assign one or more company codes to your controlling area (see: Assigning Company Codes And Controlling Areas).

You can also activate individual components in the controlling area using the Implementation Guide of the given Controlling component.

 

 Creating or Changing Controlling Areas 

To create a new controlling area and maintain its basic data, go to Maintain Controlling Area choose New entries and enter the controlling area, name and person responsible. Then enter the Basic data for the new controlling area.

To maintain the basic data for an existing controlling area, select the relevant controlling area, and choose Detail.

 

 

 

 Processing Assignment Control 

1. In the editing for the controlling area, choose Assignment Control COCode  CO area.

2. Enter the Assignment indicator. This defines the assignment of the company code(s) and controlling area. Together with the currency type, it also determines the controlling area currency.

o Enter 1 for a 1:1 relationship between company code and controlling area. A prerequisite for this is that a company code of the same number must already have been created.

o Choose assignment indicator 2 if you want to: Assign one controlling area to multiple company codes Use a currency other than the company code currency for the controlling area

 

 Currency 

Definition

Legal means of payment in a country.

Use

In external accounting, you assign a company code currency (= first local currency) to each company code. You can also specify one or two parallel currencies (= second and third local currencies) for a company code, which are recorded in the external accounting documents. Parallel currencies include currencies of other organizational units (group currencies, hard currencies, index-based currencies, or global company currencies).

When you create a controlling area, you specify whether the controlling area currency is different from the company code currency and which particular currency is to be the controlling area currency.

You can use the company code currency or the currency of a different organizational unit recorded as a parallel currency in the company code. You can also use a separate controlling area currency not dependent on the company code currency.

Cross-company code cost accounting can therefore be performed for company codes that use values recorded in different currencies. SAP recommends defining a uniform parallel currency for company codes and using this as the controlling area currency, because you may then make postings in the Controlling component (CO) using the relevant currencies.

See also:

Currencies).

 

 

 Maintaining Currency Settings 

1. To set the currency in the controlling area, you must enter the currency type and in certain cases the currency as well.

The currency type, together with the assignment control indicator, determines which currency is allowed as the controlling area currency and whether the controlling area currency can differ from the currency of the assigned company codes.

2. You only maintain the C&V profile field if you are using transfer prices (see:  Transfer Prices). You then store a currency and valuation profile to ensure the consistent updating of the data.

3. The Currency and Valuation Profile Active indicator in the controlling area shows whether calculation using group and profit center transfer prices is active.

To make the necessary settings for parallel valuations in Controlling, see the Implementation

Guide (IMG) under Controlling  Controlling: General Execute parallel valuation/transfer prices. You can also find more information there for working with transfer prices /see: Recording Parallel Valuation Approaches/Transfer Prices).

 

 

 

 Chart of Accounts 

Definition

The chart of accounts is an organizational structure, defined along accounting principles, that records values and value flows for orderly account management.

Use

The operational chart of accounts is used by the Financial Accounting component (FI) and the Cost and Revenue Element Accounting component (CO-OM-CEL). The items in a chart of accounts can be simultaneously expense or revenue accounts in FI and cost or revenue elements in CO-OM-CEL.

Integration

You must assign each company code to one chart of accounts.

In addition, you may assign each company code to a country chart of accounts. The chart of accounts and country chart of accounts are linked using alternating account numbers.

The accounts from internal and external accounting are managed in an integrated accounting system. Therefore, when creating a controlling area, the charts of accounts used by the corresponding company code must be respected.

The controlling area adopts the chart of accounts belonging to the company code assigned. In cross-company code cost accounting the controlling area and all company codes assigned to it must use the same chart of accounts.

Nevertheless, you may also use a country chart of accounts to apply the specific external accounting requirements of a given country while using unified cost accounting.

You assign a company code to the controlling area. The company code uses chart of accounts INT (International Chart of Accounts). The controlling area also uses chart of accounts INT.

Your organization has subsidiaries in France and Italy which produce balance sheets in different company codes. Managerial accounting is to be performed on a unified basis for the entire corporation.

In order to comply with the accounting regulations of each country, the company codes are assigned to different country charts of accounts.

In addition, you also define a uniform worldwide chart of accounts for internal accounting to which you assign the company codes and the controlling area.

For more information on the chart of accounts, see the R/3 Library under FI Financial Accounting G/L Accounting General Ledger Account Master Data Chart of Accounts List.  Chart of Accounts List).

.

 

 

 

 Defining Charts of Accounts 

If you set the Chart of accounts indicator to 1, the controlling area adopts the chart of accounts of the company code.

If it is set to 2, you must enter the chart of accounts manually.

Note that cross-company cost accounting is possible only if the controlling area and its assigned company codes all use the same chart of accounts.

To take country-specific accounting requirements into account, you must assign the company codes from external accounting to country charts of accounts.

 

Fiscal Year Variants 

Definition

The fiscal year variant contains the number of posting periods in the fiscal year and the number of special periods.

Structure

You can define a maximum of 16 posting periods for each fiscal year in the Controlling component (CO). You define the fiscal year variant in the Implementation Guide (IMG) for Financial Accounting.

Integration

You must also define which fiscal year variant is used in the company code.

When you create a controlling area, you must also specify the fiscal year variant. The fiscal year variants used by the company code and the controlling area can only differ in the number of special periods used. You must ensure that the fiscal year variants use the same number of equally-defined standard periods.

A company code using a fiscal year variant with 12 posting periods and 4 special periods can be assigned to a controlling area using a fiscal year variant with 12 posting periods and 1 special period.

However, it cannot be assigned to a controlling area with 52 posting periods.

For more information, see the R/3 Library under  FI Financial Accounting  G/L Accounting FI Closing and Reporting Posting Periods and Fiscal Years. Posting Periods and Fiscal Years).

 

 

 

 Defining Fiscal Year Variants 

Enter a fiscal year variant defined during Customizing of the Financial Accounting component (FI) in the Implementation Guide (IMG).

 

 Defining Cost Center Standard Hierarchies 

The standard hierarchy is the organizational structure in which Cost Center Accounting is depicted in the organization. Enter the name of the cost center group that acts as the standard hierarchy in the controlling area.

Note the following requirements:

You may not use the cost center group in any other controlling area.

The cost center group cannot contain any individual values (cost centers). No other group (such as a cost element group) may use the same name.

If a cost center group of the name entered does not exist, the R/3 System asks whether it should create it. The system creates the top node of the cost center group. Maintain the cost center hierarchy in the master data maintenance for Cost Center Accounting.

You may only change the standard hierarchy entry for the controlling area if you have not yet assigned any cost centers or cost center groups to this cost center group.

 

 

 Activating Reconciliation Ledgers 

Use

The Reconciliation ledger indicator shows whether the Reconciliation Ledger is active or not.

Features

If the indicator is selected, the reconciliation ledger is posted to for all postings on CO objects.

Actions

When you create a new controlling area, the R/3 System activates the indicator in the standard system.

You activate and deactivate the reconciliation ledger in the IMG for Cost and Revenue Element

Accounting in the section Reconciliation Ledger  Activate reconciliation ledger (see  Activating Reconciliation Ledgers).

In the Document type field you choose a Document Type as the default for reconciliation postings with the ledger. The defaulted document type can be changed during the reconciliation posting.

You can use the document type to specify the characteristic attributes for the creation of the document, for example, the valid document number range.

See also:

Reconciliation Postings

 

 

 

 Subcomponents 

Use

Activate the subcomponents you require within the controlling area.

Features

Cost Center Accounting

This indicator, together with the Controlling component (CO) interface, controls specific settings for the Cost Center Accounting component (CO-OM-CCA). The following values are allowed:

" "'

Cost Center Accounting is not active. You cannot use cost centers as account assignment objects.

1

Cost Center Accounting is active. The R/3 System checks whether the cost centers have valid master data records for the given period in the cost center master data. You can use cost centers as account assignment objects. When postings are made, the R/3 System updates the CO files.

2

Cost Center Accounting is active, but the Controlling data is not updated. If Cost Center Accounting is installed at a later date, you can post subsequently the cost-relevant business transactions to cost centers in the CO files.

3

Basically the same as for "2". However, the cost centers exist here only as a raw version, that is, you do not maintain them fully.

Order Management

This indicator, together with the CO interface, controls specific settings for order management.

" "'

Order management is not active. You cannot use orders as account assignment objects.

1

Order management is active. The R/3 System checks whether the orders have valid master data records in the order master data. You can use orders as account assignment objects. When postings are made, the R/3 System updates the CO files.

2

Order management is active, but the CO files are not updated. If you implement order management at a later date, you can post subsequently the cost-relevant business transaction on the orders to the CO files.

3

Basically the same as for "2". However, the R/3 System only checks whether orders exist, not whether the posting itself is valid.

Profitability Analysis

This indicator controls specific settings for Profitability Analysis. The following values are allowed:

" "

Profitability Analysis is inactive. You cannot use profitability segments as account assignment objects.

2

Only costing-based Profitability Analysis is active. You can use profitability segments as account assignment objects. You can settle orders or projects to profitability segments.

3

Only account-based Profitability Analysis is active. You can use profitability segments as account assignment objects. FI documents containing an assignment to a profitability segment are passed on Profitability Analysis and posted there.

4

Both account-based and costing-based Profitability Analysis are active.

Activity-Based Costing

This indicator determines whether the Activity Based Costing component (CO-OM-ABC) is active or not.

" "

Activity Based Costing is inactive. You cannot use business processes as account assignment objects.

1

Activity-Based Costing is active, but can only be used as a parallel accounting system. The R/3 System does not post allocations as true debits and credits, but rather as statistical values in the delta version for Activity-Based Costing.

2

Activity-Based Costing is fully active. The R/3 System checks whether the business processes have valid master data records. You can use business processes as account assignment objects. For allocations, the given objects are truly credited and debited and updated with the corresponding posting transactions.

Profit Center Accounting

This indicator determines whether Profit Center Accounting (EC-PCA) is active or not.

If the indicator is not selected, Profit Center Accounting is inactive. If the indicator is selected, Profit Center Accounting is active.

Projects

This indicator controls whether the R/3 System checks for valid master data when you enter projects and networks as additional account assignments. You must have already defined the projects and networks. CO files are updated if such postings are made.

If the indicator is active, the SAP R/3 System checks whether valid network or project numbers exist in the master record for the given project or network. The CO files are updated when postings are made.

If the indicator is inactive, the R/3 System does not update CO files.

Sales Orders

This indicator controls the use of Sales Orders in make-to-order production.

If the indicator is active:

o You can post actual costs and actual revenues to the sales order item.o You can settle the costs of production orders, networks, and so on, to the sales order

item.o You can settle actual costs and actual revenues or data from the calculation of profits

to Profitability Analysis.

If the indicator is inactive, the system does not check the CO object for the sales order item, nor does it update the costs or revenues on the sales order item.

Cost Object Accounting

The Commitments management indicator lets you determine whether commitments are to be updated for sales orders.

This indicator controls the use of Cost Object Accounting. It specifies whether account assignments are allowed on a cost object identity number.

 

 Activating Subcomponents 

1. To activate subcomponents for an existing controlling area, select the controlling area in the Change Basic Data overview screen and choose Activate component/control indicator.

2. To activate subcomponents for a new fiscal year, choose New entries and enter the fiscal year and the desired subcomponent.

3. To activate subcomponents for an existing fiscal year, select the year, choose Detail, and activate the desired subcomponent.

The activation of subcomponents is fiscal-year dependent. This means that subcomponents are active as of the fiscal year entered.

 Control Indicators 

Use

You can store control information within a controlling area.

Features

Commitments Management

Commitments management determines how commitments are updated to CO objects such as cost centers and orders. The following values are allowed:

" "'

Commitment management is not active. Commitments are not recorded in this controlling area.

1

Commitments management is active for cost centers and orders in the controlling area as of the fiscal year entered. To update commitments on cost centers and orders, you must activate the functionality in the cost center/order master record.

Variances

If you select the Variances indicator, the system displays price variances arising from primary cost postings in the line items.

A wage posting of $3,000 includes a $50 price variance. Since variances are to be identified, the total amount of $3,000 and the $50 price variance are displayed as line items.

All Currencies

If you select All currencies, the SAP R/3 System updates all values in the controlling area currency, the transaction currency, and the object currency. If you do not select All currencies, the system updates the values only in controlling area currency.

If data was posted when the indicator was not active, activating the indicator later can lead to inconsistencies in the system.

This also applies when activating the indicator from one year to the next when using cost objects, orders, and projects, or when calculating cost estimates for any controlling objects.

If you are using different currencies for your company code(s) and controlling area, the All currencies indicator is automatically activated and cannot be deactivated.

Activating Company Code Validation

Company code validation in CO applies only to cross-company code cost accounting for postings from external accounting.

If the indicator is selected, you can only make postings to an account assignment object, such as a cost center or an order, from the company code stored in the master record of the account assignment object.

If Company code validation is not selected, you can make postings to an account assignment object from any company code assigned to the controlling area.

You assign company code 0001 and company code 0002 to controlling area 0012. Cost center COST-1 was assigned to controlling area 0012 and company code 0001.

If Company code validation is selected, you can make postings to COST-1 only from company code 0001.

If Company code validation is not selected, you can post to COST-1 from both company code 0001 and company code 0002.

Use in the Purchasing Component (MM-PUR)

A purchase order, which was created by the purchasing department for a cost center in another company code, can only be posted if the Company code validation indicator is not selected.

Use in the Inventory Management Component (MM-IM)

Materials consumed from the warehouse of a plant in company code 0001 by a cost center in company code 0002 results in the following postings:

If the Company code valuation indicator is selected, the R/3 System posts to both company codes

If the indicator is not selected, the R/3 System posts only to company code 0001

Account Assignment to Activity Types

If you select Account assignment to activity type, you can use the activity type as an account assignment object for actual postings in specific application areas (see:  Actual Postings to Activity Types).

You can only select Account assignment to activity types if Cost Center Accounting is active in the controlling area.

 

 

 Activating Control Indicators 

1. To activate control indicators for an existing controlling area, select the controlling area in the Change Basic Data overview screen and choose Activate component/control indicator.

2. To activate control indicators for a new fiscal year, choose New entries and enter the fiscal year and the desired control indicators.

3. To activate control indicators for an existing fiscal year, select the year, choose Detail, and activate the desired control indicators.

Activation of control indicators takes place every fiscal year. This means that subcomponents are active as of the fiscal year entered.

 

 

 

 Assigning Company Codes and Controlling Areas 

Assign one or more Company Codes manually to the Controlling Area.

1. To assign company codes to an existing controlling area, select the controlling area.2. Choose Assign company code(s).3. Then, choose New entries.4. Enter the company code(s) that you want to assign to the selected controlling area.

The company code(s) must be fully maintained before you can assign them to a controlling area.

When you are assigning company codes, you should keep in mind the controlling area attributes: Assignment Control, Currency Type, Chart of Accounts and Fiscal Year Variant.

 

 

 Selecting and Displaying the Current Controlling Area 

Use

You specify the Controlling Area with the first transaction called up in Controlling after you have logged on to the SAP R/3 System. You enter the required controlling area in a dialog box. The R/3 System stores this as a user parameter so that you do not need to enter the controlling area again during your work session if you call up another transaction in Controlling.

If you always work in the same controlling area, you can set up this controlling area as a user parameter: To do so, choose:

System  User profile  Own data

Enter CAC (controlling area) as the parameter ID and enter the required controlling area as the parameter value Save your entries At the next system logon, the R/3 System will automatically set the specified controlling area.

You can display and change the current controlling area from any Controlling transaction: Choose:

Extras  Set controlling area.

A dialog box appears displaying the current controlling area. You can overwrite this if you wish.

You can display and change the current controlling area from the area menus of the individual

Controlling components. Choose Environment  Set controlling area.

You cannot execute a transaction for more than one controlling area at the same time.

If you work with multiple sessions, remember that changing the controlling area setting in one session affects all other sessions. You cannot work with different controlling areas in different sessions.

 

 

 Currencies 

Use

In the SAP R/3 System you can post in different currencies.

Integration

You define the currencies allowed in the system and set exchange rates in the Implementation Guide

(IMG) under Global Settings  Currencies (see:  Currencies).

In the Financial Accounting component (FI) you use a company code currency (first local currency) and, if required, parallel currencies (second and third local currencies). These currencies also affect Controlling.

You define the Controlling Area Currency in Controlling. The R/3 System can derive the controlling area currency from the Company Code currency or from the currencies of other organizational units. You can also specify the controlling area currency yourself.

Prerequisites

Before you can post in different currencies, you must make sure to do the following:

Define a currency key with long text and short text for each currency.

To maintain the currency key, see the Implementation Guide (IMG) under Global

settings  Currencies  Check currency codes (see:  Transfer Currency Codes).

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies  Foreign

Currencies: Overview  Posting Requirements (see:  Posting Requirements).

Change the value in the number of decimal places if you do not want the currency displayed with two decimal places.

To maintain the number of decimal places, see the Implementation Guide (IMG)

under Global settings  Currencies  Set decimal places for currencies(see:  Set Decimal Places for Currencies).

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies  Foreign

Currencies: Overview  Posting Requirements (see: Overview Posting Requirements (see:  Posting Requirements).

The Exchange Rate Types you require have been stored. Exchange rate types enable you to record different exchange rates valid on the same date for different purposes. The SAP R/3 System uses exchange rate type M (= mean exchange rate) when actual values are posted. You can define other exchange rate types for different planning scenarios using different exchange rates, for example.

To maintain exchange rate types, see the IMG under Global settings  Currencies  Check exchange rate type.  Check Exchange Rate Types).

For each exchange rate type you can enter a basic currency through which you undertake the currency conversion. You would then no longer need to maintain translation factors and exchange rates in tandem between the currencies, but rather only in relation to the basic currency.

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies  Foreign

Currencies: Overview  Posting Requirements (see:  Defining the Exchange Rate).

Enter translation ratios for the required currencies for each exchange rate type in tandem. If you have established a basic currency for the exchange rate type, you need only define the translation ratios in relation to the basic currency. The translation ratios (such as 1:1 or 1000:1) form the basis of the exchange rates and simplify their display if there is a large difference in the currency units.

To maintain translation ratios, see the IMG under Global settings  Currencies Defining translation ratios for currency translations.  Defining Translation Ratios for Currency Translation.

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies  Foreign

Currencies: Overview  Posting Requirements (see:  Defining the Exchange Rate).

You must define exchange rates for each exchange rate type for the currencies you require. If you have established a basic currency for the exchange rate type, you need only define the translation factors in relation to the basic currency. Exchange rates are period-independent and valid from the date entered. You can maintain the exchange rates at regular intervals according to your own requirements or exchange rate fluctuations.

To maintain exchange rates, see the IMG under Global settings  Currencies  Entering exchange rates.  Enter Exchange Rate).

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign

Currencies  Exchange Rates  Exchange Rates: Definition (see:  Defining Exchange Rates).

The R/3 System requires these definitions to check whether a given currency is allowed and to translate the currencies on posting.

You must define a company code currency (= first local currency) for each company code in FI. If necessary, you can also define a further one or two currencies as parallel currencies (second and third local currencies) which are shown together with the company code currency on the posting documents. To maintain the currencies, see the IMG under Financial Accounting.

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies  Parallel Currencies (see:  Parallel Currencies).

You must define a controlling area currency for each controlling area. To maintain the currency, see the IMG under Controlling.

For more information, see the R/3 Library, under FI - Financial Accounting Accounts

Payable or Accounts Receivable  FI Cross Application Topics Foreign Currencies (see:  Foreign Currencies).

 

 

 Currencies in Controlling 

Use

You can use different currencies in the Controlling component (CO):

Features

The following three currencies are valid in the Controlling component (CO):

 Controlling Area Currency

The R/3 System executes cost accounting in this currency. This currency is set up when you create the controlling area. It is based on the assignment control indicator and the currency type.

 Object Currency

Each object in Controlling, such as cost center or internal order, may use a separate currency specified in its master data. When you create an object in CO, the SAP R/3 System defaults the currency of the company code to which the object is assigned as the object currency. You can specify a different object currency only if the controlling area currency is the same as the company code currency.

 Transaction Currency

The documents in the CO application component are posted in the transaction currency. This currency can differ from both the object currency and the controlling area currency. The SAP R/3 System automatically converts the values to the controlling area currency at the exchange rate specified.

The R/3 System always converts actual data at the mean exchange rate.

You can specify a different exchange rate for planning data in the version.

The SAP R/3 System stores all three currencies as both totals records and line items. This allows you to perform evaluations in any of the three currencies. This is only possible if you have defined that all currencies should be updated for the given controlling area (see: Control Indicators).

The transaction currency is USD, the controlling area currency is DEM and the cost center currency is SFR. The R/3 System converts the amounts as follows:

1. From transaction currency to controlling area currency (USD  DEM)2. From controlling area currency to cost center currency (DEM -> SFR), to

calculate the amount in Swiss francs.

For another example, see Example: Currencies in Controlling.

The following additional currencies may also appear as controlling area currencies in Controlling if you use cross-company code cost controlling:

Local Currency:

Company code currency (country currency) used for local ledgers in external accounting.

For each company code you can specify one or two parallel currencies (= second and third local currencies) which are stored in the documents and updated parallel to the local currency in the general ledger.

Group Currency:

Currency in which the group balance sheet is presented.

You can specify it as a parallel currency (additional local currency) for a company code.

Hard Currency:

Secondary currency for countries with high inflation. You can specify it as a parallel currency (additional local currency) for a company code. You must specify the hard currency in the detail screen for the given country.

Index-Based Currency:

Country-specific, fictitious currency stipulated in certain countries with high inflation for tax returns. You can specify it as a parallel currency (additional local currency) for a company code. You must specify the index-based currency in the detail screen for the given country.

Global Company Currency:

Currency used in a corporate group. In the CO application component you can create companies to represent divisions, regions, or product groups.

You can specify it as a parallel currency (additional local currency) for a company code. You must store the global company currency in the detail screen for the given company.

For more information, see the Implementation Guide (IMG) under Financial Accounting  Financial

Accounting Basic Settings  Company Code  Parallel Currencies  Define additional local currencies (see:  Defining Additional Local Currencies).

 

 

 

Example: Currencies in Controlling 

The controlling area currency is DEM, the cost center currency is SFR. You post two documents, one in USD and one in FFR, to the cost center. The R/3 System generates line items and totals records as displayed below.

 

 

 

 Controlling Area Currency 

Use

You set the Controlling Area Currency when you define the Controlling Area in the Implementation Guide (IMG) for Controlling. You can assign Company Codescarrying different currencies to one controlling area. The R/3 System can derive the controlling area currency automatically from the company code currencies or currencies of other organizational units. You can also specify the controlling area currency yourself.

A German corporation has subsidiaries in France and Italy. The French subsidiary produces a balance sheet in FFR for its own company code. The Italian subsidiary produces a balance sheet in ITL, also for its own company code. The corporation performs cost controlling on a global basis in DEM.

Integration

The controlling area currency is dependent on the assignment between company code and controlling area (as shown by the Assignment Control) indicator) as well as the Currency Type of the controlling area. You set these indicators under Basic data during controlling area definition.

Features

Controlling Area Currency Control

Assignment

CompCode-CO Area

Currency Type

 

Currency

Controlling area1 10 Adopt company code currency2 10 Adopt company code currency2 20 Independent controlling area currency2 30 Adopt group currency2 40 Adopt hard currency2 50 Adopt index-based currency2 60 Adopt global company currency

 

If the assignment indicator is 1, the SAP R/3 System automatically sets currency type 10. In other words, the controlling area is assigned to a corresponding company code, making the controlling area currency identical to the company code currency.

Assignment indicator 2 allows you to perform cross-company code cost controlling or to use a controlling area currency differing from the company code currency. The currency type then determines the controlling area currency.

If you use a controlling area currency differing from the company code currency, the SAP R/3 System automatically records the company code currency as the Object Currency for the CO objects. For example, when you create a cost center, the R/3 System automatically sets the currency of the company code to which the cost center is assigned as the object currency.

The R/3 System sets the following control indicators when you determine the currency type:

The Varying company code currency indicator shows that the controlling area currency is not the same as at least one company code currency and is set automatically if you select currency type 20, 30, 40, 50 or 60.

The all currencies indicator is set automatically if you are using different company code currencies. It shows that values are updated in the controlling area currency, the transaction currency, and the object currency.

Adopt Company Code Currency (Currency Type 10)

The controlling area adopts the local currency of the corresponding company code. If you assign more than one company code to the controlling area, all company codes must use the same currency. In this case any object currency can be used.

A German company owns a subsidiary in Mexico. The company code currency is MXP (Mexican pesos). The controlling area should be managed just as the company code (assignment indicator 1). This means that the controlling area currency is also Mexican pesos and you can define the object currency for CO objects as you wish.

Different subsidiaries of a German corporation produce balance sheets for two company codes in DEM. Joint cost controlling applies to both subsidiaries. Use currency type 10 to specify that the company code currency is the same as the controlling area currency.

Adopt Group Currency (Currency Type 30)

The controlling area can adopt the group currency provided the assigned company code is using the group currency as a parallel currency and the group currency is defined in the respective client.

If more than one company code is assigned to the controlling area, all these company codes must use the same group currency as parallel currency.

A German company owns a subsidiary in Mexico. The company code currency is MXP. The group currency DEM is used for external accounting, defined in the respective client. Cost controlling can therefore be carried out in DEM. In this case the company code currency MXP is the object currency.

A German corporation owns subsidiaries in Mexico and USA. The company code currencies are MXP and USD. The group currency DEM is the parallel currency for both company codes. You can therefore use the group currency DEM as the controlling area currency. The Controlling objects in the Mexican subsidiary must use MXP and the objects in the American subsidiary USD.

Adopt Hard Currency (Currency Type 40)

A hard currency can be the controlling area currency if the assigned company codes use the hard currency as a parallel currency and if you define the hard currency for the country where it applies.

If more than one company code is assigned to the controlling area, all company codes must use the same hard currency as a parallel currency. The company codes must be in the same country, or the countries where the subsidiaries are located must all use the same hard currency.

A German company owns a subsidiary in Mexico. The company code currency is MXP. USD is specified as the hard currency for external accounting and is defined for Mexico. The hard currency can be used as the controlling area currency. In this case the company code currency MXP is the object currency.

Adopt Index-Based Currency (Currency Type 50)

An index-based currency can be adopted as the controlling area currency provided the assigned company code uses the index-based currency as a parallel currency and the index-based currency is defined for the country for which it is to apply.

If more than one company code is assigned to the controlling area, these company codes must use the same index-based currency as a parallel currency. The company codes must all be in the same country, or the countries where their subsidiaries are located must all use the same index-based currency.

Adopt Global Company Currency (Currency Type 60)

A global company currency can be adopted as the controlling area currency provided the assigned company code uses the global company currency as a parallel currency and the global company currency is defined for the company for which it is to apply.

If more than one company code is assigned to the controlling area, these company codes must use the same global company currency as a parallel currency. The company codes must all belong to the same company, or the companies must be managed in the same hard currency.

Other Controlling Area Currency (Currency Type 20)

When configuring your R/3 System, you can specify any currency as the controlling area currency, regardless of the company code currency or currencies of other organizational entities. You must specify the currency manually.

A German corporation owns subsidiaries in Mexico and USA. The company code currencies are MXP and USD. The hard currency USD is specified as a parallel currency for the company code in Mexico. USD can be chosen as the controlling area currency. The CO objects in the Mexican subsidiary must be recorded in the object

currency MXP, and the CO objects in the American subsidiary must be recorded in the object currency USD.

By adopting the controlling area currency from the currencies of other organizational entities, you ensure that postings within Controlling appear using currencies relevant to external accounting (parallel currencies). This is not the case if you use a controlling area currency not dependent on other organizational entities.

You can only change the assignment control indicator or the currency type when you first create a controlling area or if no productive company codes have been assigned to it. Once an assigned company code is productive, the currency type cannot be changed.

 

 

 Number Ranges 

Use

Business transactions are classified according to CO transactions.

The business transaction Direct Internal Activity Allocation belongs to the Controlling transaction Actual Activity Allocation.

The system generates a document number for each business transaction. This means that you must assign each transaction to a number range interval. You can also define several business transactions in one number range interval.

The R/3 System offers a great number of transactions for each controlling area in the Controlling component.

 

 

 Business Transactions in Controlling 

Use

Each component in the CO application component uses specific business transactions. When you activate a CO component (this can take place gradually), you must make sure that all business

transactions used by the component have been assigned to number ranges. Otherwise you will not be able to call up the business transactions in the System.

You can use transaction OKC1 to display all CO business transactions.

You define number ranges for each controlling area. The sample client 000 contains defaults for number ranges.

You combine transactions into transaction groups.

Create the plan and actual business transactions in separate business transaction groups (see: Define Number Ranges).

Features

Business Transactions for Planning

The business transactions for planning are subdivided as follows:

Business-transaction-based Period-based

Business Transactions for Planning

Business Transaction NameCPPP ABC Process Assessment: PlanFIPA Automatic Payment ScheduleJVPL JV Planning Data DocumentKAZP Plan Cost Center AccrualKOAP Plan SettlementKPPB Standard Cost EstimateKSP0 Plan SplittingKSPB Plan assessment to PAKZPP Plan: Periodic overheadKZRP Plan Interest CalculationPAPL Plan Sales/ProfitRKP1 Planning Primary CostsRKP2 Planning ActivitiesRKP3 Plan Secondary CostsRKP4 Planning Statistical Key FiguresRKP5 Planning Revenue TypesRKP6 Planning Activity-Dependent Primary CostsRKP7 Planning Activity-Dependent Secondary CostsRKP8 Planning Settlement CostsRKP9 Planning Activity-Dependent Settlement CostsRKPB Plan Periodic RepostingRKPL Plan Indirect Activity AllocationRKPP Primary Planning with Template

RKPQ Manual Cost PlanningRKPS Secondary Planning with TemplateRKPU Plan Overhead Cost AssessmentRKPV Plan Overhead Cost DistributionRKPW Secondary Order Cost PlanningRKPX Activity-dependent secondary order cost planningRKPZ Planning Overhead Credits

 

The business transactions RKP1 through RKP9 and RKPW through RKPZ are business-transaction based. The other business transactions are period-based.

Business Transactions for Actual Postings

The business transactions for actual postings can be classified as follows:

Business-transaction-based Period-based

Business Transactions for Actual Postings

Business Transaction NameCOIN Through postings from FICPPA ABC Actual Process AssessmentJVIU JV Actual assessmentJVIV JV Actual DistributionJVU1 JV Reposting CostsKAMV Manual Cost AllocationKAZI Actual Cost Center AccrualKAZO Down paymentsKGPD Distribution acc. to pegKOAO Actual SettlementKPIV Actual Distribution to Cost ObjectsKSI0 Actual Split CostsKSII Actual Price CalculationKSOP Primary Target Cost CalculationKSPA Assessment to CO-PAKVAR Variance CalculationKZPI Actual Periodic OverheadKZRI Actual Interest CalculationRKIB Actual Periodic RepostingRKIL Actual Indirect Activity AllocationRKIU Actual Overhead AssessmentRKIV Actual Overhead DistributionRKL Actual Activity AllocationRKN Actual Non-Allocable ActivitiesRKLT Actual Process AllocationRKLX Predistribution of Fixed CostsRKS Enter Statistical Key FiguresRKU1 Repost CostsRKU2 Repost RevenuesRKU3 Repost CO Line Items

RRIB Segment Adjustment: Actual Periodic RepostingRRIU Segment Adjustment: Actual AssessmentRRIV Segment Adjustment: Actual Distribution

 

Business transactions RKL through RKS and RKU1 through RKU3 are business-transaction based. The other business transactions are period-based.

Other Business Transactions

The remaining business transactions cannot be classified as plan or actual transactions:

Other Business Transactions

Business Transaction NameKABG Automatic Accrual CalculationKABM Manual Accrual CalculationKAFM Payment DataKAUS Calculate ScrapKEKB Unit CostingKEKZ Unit Costing (Overhead)KFPI Fixed Price AllocationKFPP Fixed Price AgreementKPPZ Standard Costing (Overhead)KSOS Secondary Target Cost CalculationKSWP Primary Target Cost Calculation (WIP)KSWS Secondary Target Cost Calculation (WIP)

 

 

 

 Defining Number Ranges 

Process Flow

You define Number Ranges in two steps:

1. You can create individual Business Transaction Groups for each controlling area.

For example, you could combine all planning transactions in one business transaction group.

The business transactions RKP1 through RKPZ are summarized in the "Planning" group and assigned to one number range interval.

You can also create a business transaction group for each business transaction if you require a greater level of detail. If this is the case, you make assignments to the number range on the business transaction level.

2. Assign the business transaction groups to Number Range Intervals. This enables you to combine similar or related business transactions into one number range.

If all planning transactions are combined in one group, all the business transactions connected with planning are processed by the system in one number range.

The R/3 System includes standard default assignments of business transactions to number ranges for controlling area 0001. You can copy these assignments to other controlling areas if you wish. You then need only maintain the number ranges if you require other assignments or other number range groups.

The following graphic illustrates the steps required for defining number ranges.

 

 

 

 

Defining Number Ranges 

Prerequisites

To maintain Number Ranges see the Implementation Guide (IMG) under Controlling  Controlling: General Organization Maintain number ranges for CO documents (see:  Maintaining Number Ranges for CO Documents).

You can perform the following actions.

Create Business Transaction Groups Assign business transactions to business transaction groups Maintain Number Range Intervals for individual business transaction groups Maintain number range intervals and number range statuses in the controlling area

Creating Business Transaction Groups

1. In the Number Range Maintenance initial screen, choose Maintain groups .

2. In the Maintain Number Range Groups initial screen, choose Group  Insert.

3. Enter a name and the number range interval.

You can select internal or external number assignment.

The R/3 System controls internal number assignment automatically. For internal number assignment, you can also enter the number status.

With external number assignment, you manually enter the number for each business transaction.

Existing number ranges are displayed for information purposes. Ensure that the number range intervals do not overlap with those of other groups.

Assigning Business Transactions to Business Transaction Groups

1. Select a group in the Maintain Number Range Groups initial screen.2. Select an element (business transaction).3. Choose Assign element group.4. Save your entries.

Maintaining Number Range Intervals for Existing Business Transaction Groups

1. Select a group in the Maintain Number Range Groups initial screen.2. Choose Maintain.3. Change the intervals. Ensure that the number range intervals do not overlap with those of

other groups.4. Save your changes.

Changing Number Range Intervals in the Controlling Area

1. In the Number Range Maintenance initial screen, choose Change intervals.2. Change the intervals.3. Save the changes.

Changing Number Statuses in the Controlling Area

1. To change number statuses of existing intervals, choose Change status in the Maintain Number Range Groups initial screen.

2. Change the status.3. Save your changes.

Choose Utilities  Copy to transfer number ranges from other controlling areas.

 

 

 Account Assignment of Controlling Objects 

Use

For postings in external accounting that use a Cost Element as the Account you must a use a special account assignment logic so that the SAP R/3 System can ensure that data is reconcilable with all the relevant application components. These rules for the account assignment logic always apply for postings in internal accounting (Controlling).

Account assignment distinguishes between true and statistical Controlling objects.

You can use true Controlling objects as senders or receivers.

True Controlling objects, and therefore the account assignment objects, are:

Cost centers (for account assignment of costs) Orders (true) Projects (true) Networks Make-to-order sales orders Cost objects, Profitability segments

You can also specify Statistical Controlling objects as account assignment objects in addition to true Controlling objects. You cannot allocate costs on statistical Controlling objects to other objects. These account assignments are purely for informational purposes. You can assign statistically to any number of Controlling objects. Statistical Controlling objects include the following:

Cost centers (for account assignment of revenues) Cost centers, if a true account assignment object already exists Statistical orders Statistical projects Profit centers

Prerequisites

Note the following rules for account assignments:

You must specify a true Controlling object for each posting row.

You cannot assign to a statistical project without specifying a true Controlling object.

In addition to the true Controlling object, you can specify as many statistical Controlling objects in the posting row as you require.

You can assign to a cost center and additionally to a statistical order and a statistical project.

You may not assign to more than Controlling object of the same type in one posting row.

You cannot assign to a true order and a true project.

The only exception to this rule is that you can assign to a cost center and one other true Controlling object. In this case, the posting is true for the additional Controlling object and statistical for the cost center.

You cannot specify a Controlling object as being true and statistical in the same posting row.

You cannot post to a true order and a statistical order in the same posting row.

In Controlling, you can only post to profit centers in addition to true Controlling objects. This means that costs and revenues are only posted statistically to profit centers. Profit centers are derived from true Controlling objects.

You can post revenues as true postings to one profitability segment, one make-to-order sales order, one project, or to one revenue-carrying order.

You can only post revenues statistically to cost centers and profit centers.

If you specify a cost center or a profit center for a revenue posting, the R/3 System treats the object as a statistical Controlling object. This means that you must also specify a true Controlling object to which the revenues are posted.

The SAP R/3 System can automatically derive such an object if account-based Profitability Analysis is not active. The system logs the posting under the "Reconciliation object" object type. The reconciliation object is a summarized profitability segment with the characteristics "Company code", "Business area", "Plant", and "Profit center". The system also updates a reconciliation object by cost element for postings to a profitability segment with costing-based Profitability Analysis. In reconciliation ledger reports, however, the R/3 System does not display separately the revenue postings for profitability segments, cost centers, and profit centers.

The R/3 System does not post to reconciliation objects if you specify an additional Controlling object on which true revenue postings can be made.

If you use account-based Profitability Analysis, you cannot assign revenue postings only to cost centers or profit centers. In this case, your only option is to save a fixed account assignment for each revenue type during automatic account assignment. For more information, see the Implementation Guide (IMG) for Cost Center Accounting

under Actual Postings  Manual Actual Postings  Maintain automatic account assignment.(See:  Maintaining Automatic Account Assignments).

 

Example: Account Assignment Logic 

The following examples illustrate the account assignment logic for Controlling objects:

1. You enter costs of $100 for statistical order 40010. The order also stores the posting to cost center 2330. Cost center 2330 is assigned to profit center P100.

Because this is a statistical order, the cost center is the true account assignment object for this posting. In addition, the R/3 System posts the costs statistically to the order and to the profit center.

2. The system records costs of $100 on cost center 2330 and on the order 40020. Cost center 2330 is assigned to profit center P100.

Orders and cost centers are true Controlling objects. The R/3 System therefore posts the costs as true to the order and as statistical to the cost center. In addition, the system posts the costs statistically to the profit center.

3. You enter revenues of $200 on cost center 2330. Cost center 2330 is assigned to profit center P100.

Because the cost center is not a true account assignment object for revenues, the SAP R/3 System derives a summarized reconciliation object as the true account assignment object. In addition, the system posts the costs statistically to the cost center and to the profit center.

 CO Settlement 

Possible Uses

The various SAP components all handle settlement of business objects according to the same settlement logic.

During settlement, some or all of the plan or actual costs incurred on an object are allocated to one or more receivers. To do this, the system automatically generates offsetting entries to credit the sender object. The debit postings assigned once to a sender object remain in place even after settlement to a receiver (and can therefore be displayed). The costs settled are updated on the corresponding receiver object and displayed in reporting.

Settlement occurs in parallel in all valuations, with the exception of settlement to fixed assets and profitability segments. The system moves back the amount that is used in legal valuation for the settlement to fixed assets. The system moves back the leading valuation for the settlement to the profitability segment. The following graphic shows how the system debits the order with this amount in all valuations:

 

A line item settlement to a fixed asset is only possible, if the legal valuation is the leading valuation.

You can find further information on settlement of capital investment measures under  IM - Investment Management in the Capital Investment Measures (Orders/Projects), Settlement functions, Settlement sections.

 

 

Settlement Senders and Receivers 

Settlement sender (alphabetic) Notes on settlement receiver

Order items All correspond to the Settlement receiver table

as well as Material

CO Production orders All correspond to the Settlement receiver table

as well as Material

Production orders All correspond to the Settlement receiver table

as well as Material

Real estate objects All correspond to the Settlement receiver table

Internal Order All correspond to the Settlement receiver table

Maintenance orders All correspond to the Settlement receiver table

Capital investment order All correspond to the Settlement receiver table

Cost object All correspond to the Settlement receiver table

Sales orders, make-to-order production All correspond to the Settlement receiver table

Network headers All correspond to the Settlement receiver table

Network activities All correspond to the Settlement receiver table

Projects All correspond to the Settlement receiver table

 

Settlement receiver (alphabetic) Notes on settlement sender

Fixed assets All correspond to the Settlement sender table

Orders All correspond to the Settlement sender table

Order items All correspond to the Settlement sender table

Profitability segment All correspond to the Settlement sender table

Business process All correspond to the Settlement sender table

Real estate objects All correspond to the Settlement sender table

Cost center All correspond to the Settlement sender table

Cost object All correspond to the Settlement sender table

Sales order item All correspond to the Settlement sender table

Network All correspond to the Settlement sender table

WBS element All correspond to the Settlement sender table

G/L account All correspond to the Settlement sender table

Revenues can only be settled to revenue-carrying senders (sales documents), billing elements, internal orders with revenues, profitability segments) or to G/L accounts.

In cases where no revenue is posted to a revenue-carrying sender (sales order, billing element, or order with revenues), for example when a sales order becomes a warranty case, the sender can also be settled to a cost center, business process or asset. To be able to settle costs and revenues, you may need to create separate source structures for costs and revenues.

Multi-level settlement is not possible in such cases, because the information that revenue has been posted is not transferred.

 

Settlement rule 

Definition

Determines which portion of the costs on a sender should be settled to which receiver(s).

Usage

You need to create a settlement rule to settle the actual costs of a sender object. The settlement rule contains the distribution rules for the sender.

For some sender objects, the system creates the settlement rule automatically.

See also:

Distribution Rule

Structure

The settlement rule contains:

One or more distribution rules The settlement parameters for a sender object.

See also:

Create Settlement Rule

 

 

 Distribution Rule 

Definition

This is part of a settlement rule that specifies the following for a settlement sender:

which settlement receiver you settle to. which part of the costs you settle. when you make the settlement.

Normally there is one distribution rule for each receiver.

Usage

To settle objects from the SAP Controlling application, each settlement rule must have at least one distribution rule.

You need to define the settlement rule before the first settlement of the sender object. Subsequent changes are only possible to a limited extent.

The system creates automatic distribution rules for some sender objects, such as networks. The system always generates rules for settlement to materialsautomatically. You cannot enter them manually.

For example, when settling a production order for a self-produced stock item to the warehouse.

Structure

Settlement Receivers

You can settle costs to one or more receiving objects. You need to define a distribution rule for each settlement receiver. Statistical receivers (orders or WBS elements) are posted additionally to actual receivers, but are not debited with true costs.

You can also settle to each of the following statistical receivers:

True Receiver Cost center Order WBS element

G/L account - - -

Cost center - x x

Order x - x

WBS element x x -

Fixed assets - - -

Network/-activity x x x

Profitability segment x x x

Sales order item x x x

Cost object x x x

Business process x x x

Real estate object x x x

Settlement share

You can specify percentage rates or equivalence numbers. The system distributes the incurred costs to the individual settlement receivers accordingly.

You can also settle fixed amounts. You can only do this once costs have been incurred.

You can settle one fixed amount in each period. You may end up settling more costs than exist on the object. Therefore, your settlement rule should also contain percentage rules.

If you do not call up Percentage validation, the system checks automatically when you save the settlement rule.

You can specify an upper limit amount for all settlements for this sender. At the most, the system settles the costs which are on the sender in each period. The sender cannot receive a negative balance.

Settlement type

The following settlement types are defined in the SAP System:

Periodic Settlement (PER):

This settlement type settles costs by period. Therefore, the system only settles the costs for the settlement period.

 Full Settlement (FUL):

The system settles all the costs incurred by a sender object for all previous periods, that have not yet been settled. This settlement type only permits settlement of quantities for primary cost elements.

During full settlement you can settle more or less than the order balance, if:

You maintain distribution rules with an amount for the sender There are no FUL rules with percentage rates or equivalence numbers.

Additionally, Investment Management has the following settlement types:

Capitalization to asset under construction (AUC):

This settlement type is used to make periodic settlements from capital investment measures to assets under construction. The SAP R/3 system generates this settlement type automatically.

Investment measures are projects or orders used to process expenditure for fixed assets which cannot be posted as direct capitalization to fixed assets, either because they are too large or include too many internal activities.

Preliminary Settlement (PRE):

Preliminary settlement enables you to settle debits charged to investment measures to CO receivers before carrying out the periodic settlement to assets under construction. Preliminary settlement of given line items is a good idea if certain incidental costs for an investment have been assigned to an investment measure, but are not to be activated. This may be necessary so that the total costs for the measure can be monitored in Controlling.

For more information on settling investment measures, see  IM - Investment Management

Line Item Settlement for Assets-Under-Construction (LIS):

This type of settlement is used for the line item settlement of assets under construction. The SAP R/3 System sets it automatically (not for capital investment measures).

Validity Period

Enter a validity period for the distribution rule using the fields Valid from and Valid to. The Valid to period is the only specification that you can change once you have used the distribution rule. You can change the distribution rule as far back as the period in which the rule was last used.

 

See also:

Create Settlement Rule

Replacing an Existing Distribution Rule With A New Rule

You either corrected, changed, or specified a settlement rule. In this rule, you settle the collected costs on a sender object periodically to the "Purchasing" cost center and the "Sales and Distribution" cost center (50% to each). As of 1.1.99, you wish to replace the current receiver "Sales and Distribution" with "Vehicles". To do this, reset the Valid to period for the distribution rule to 31.12.98

 

Settlement parameters 

The settlement process is controlled using various parameters. These parameters include:

 Settlement Profile

 Allocation Structure

 PA Transfer Structure

 Source Structure

You can find out how to define these parameters in the Implementation Guide for the sender object.

Settlement profile

The settlement profile is defaulted on the basis of the entries you made in Customizing. For example, for Internal Orders, the settlement profile is transferred from the order type. You need a settlement profile for each settlement rule. Define the following in the settlement profile

to maintain it:

Permitted receivers:

This is where you define which receivers you can settle to. For example, for overhead orders, you can stipulate that settlement may be made to cost centers and orders, but not to fixed assets.

Document type for accounting relevant or balance-sheet relevant settlements Maximum number of distribution rules Residence time for the settlement document Whether the portion to be settled may be specified as a percentage and/or using equivalence

numbers or whether costs can be settled according to amounts Whether the total of the settlement percentage rates must be 100% during periodic

settlement, or whether the total can be less than 100% (in other words, that you do not need to settle a sender object completely).

Whether variances should also be recorded in the costing-based profitability analysis. Default values, which are transferred when you create the settlement rule:

Allocation Structure:

In the settlement structure you combine the primary and secondary cost elements into groups, in which debits are then posted to the sender objects. For each group, you specify whether (for settlement to a given receiver type) settlement is performed by cost element or using a settlement cost element.

For example, you might use settlement cost elements:

To document the purpose of an order (such as, repairs or maintenance)

To reduce data volumes (you can combine a number of debit cost elements under one settlement cost element).

PA transfer structure:

The PA transfer structure is only required when you settle objects to Profitability Analysis (CO-PA).

You can use it to assign the fixed and variable costs incurred under one cost element or cost element group to different value fields in the operating concern.

Account assignment default:

This enables you, for example, to go directly to the screen for entering a receiver cost center each time you create a settlement rule. You should enter the receiver type "Cost center" as the default account assignment.

Source structure:

In the source structure you group the primary and secondary cost elements into assignments, in which debits are then posted to the sender objects. When you enter a distribution rule, you can enter a different receiver for each assignment. You can, for example, use this to settle primary costs using different rules than those required for secondary costs.

Specifications for actual costs or cost-of-sales for the settlement:

For complete settlement:

When you try to close an object or set the deletion flag, the system generates an error message if the balance for the object is not zero.

Can be settled:

You can settle the actual costs, but are not under obligation to do so. When you try to close an object or set the deletion flag, the system displays a warning message if the balance for the object is not zero.

Must not be settled:

The actual costs for the object are not settled, even if you specifically trigger settlement for the object. However, WIP and variances can be settled. When you try to close an object or set the deletion flag, the system does not display any messages if the balance for the object is not zero.

The "Production" cost center makes a repair request to the "Work Center" cost center. The costs are distributed as follows:

The "Production" cost center bears all material costs.

The market price for the repairs totals $ 50.00 per hour, and the repairs usually take a maximum of five hours. Therefore, the "Production" cost center is liable for labor costs of up to $ 250.00.

The "Work Center" cost center is liable for remaining costs.

You create the "Repairs" source structure and define assignments, each with a cost element group.

For material costs

For repair hours

You enter the "Repairs" source structure in the settlement rules for the repairs request and define the following distribution rules:

You settle all of the material costs to the "Production" cost center.

You settle repair hours totaling $ 250.00 to the "Production" cost center.

You do not need a source structure if you want to settle all your cost elements using the same rules.

Actions

Choose Goto  Settlement parameters in the settlement rule, to maintain settlement parameters.

 

 Settlement Hierarchy 

Use

During a settlement run, a settlement object can pass on costs to a settlement receiver that is also settled during the run.

You have internal orders for repair or maintenance costs, as well as for each machine and each of your fixed assets. To receive summarized information on all suborders for your fixed assets, settle your internal orders with repair or maintenance costs to the orders that collect the costs for the relevant machines. Then settle these orders to the internal orders that collect the costs for your fixed assets.

To ensure that you have fully settled all objects following the settlement run, you must settle the objects in the correct sequence. No objects may be settled and later receive costs from another object during the same settlement run. The costs received later would not be settled in this run. For this reason, the system determines a settlement hierarchy.

Features

On the basis of your entries in the settlement rules, the system automatically determines the processing sequence for the settlement objects so that you can settle all objects completely. Each object is given a hierarchy number between 0 and 999. The object with the highest number is settled first and the object with the lowest number is settled last.

For example, repair or maintenance orders have hierarchy number 100. Orders for a turbine or refrigeration have hierarchy number 050, and the order for your power station has hierarchy number 000. Therefore, the system first settles the repair- or maintenance costs to the turbine or refrigeration, and then settles these orders to the power station.

If you settled the orders for the turbine or refrigeration first, these orders would still receive costs afterwards from the repair- or maintenance orders. These costs would not be settled during this settlement run.

If it is not possible for the system to determine a settlement hierarchy for a settlement run (in which all settlement objects can be completely settled), the system displays a message. In this case especially, you can enter a hierarchy number for your settlement objects if required. You can thus specify which objects in a settlement run are settled first, and, if required, debited later with costs from the same

settlement run. In this case you should start the settlement several times, until all objects can be settled down to zero.

Activities

For an overview of the settlement hierarchy, see: Settlement rule  Settlement hierarchy.

 

 

Creating a Settlement Rule 

Procedure

1. Choose Settlement rule in the master data maintenance for the relevant sender object.

If you have not entered an account assignment default in the settlement profile you are using, the system displays the Maintain settlement rulescreen. Distribution rules. The settlement receiver is the object type you stored as an account assignment default in the settlement profile .

If you have not entered an account assignment default in the settlement profile you are using, the system displays the Maintain settlement rule:Initial screen.

1. Enter the settlement receiver.2. Specify how the sender object costs are to be settled to the various settlement receivers:

By percentage

By equivalence numbers

For distribution rules of the same settlement type (periodical or total) you need to determine the portion using either percentage rates or equivalence numbers.

1. After you have distributed the costs in this way, check the percentage distribution of the costs

by choosing Settlement Rule  Percentage validation.2. If you wish to settle fixed amounts, choose Receiver. On the following screen you can edit a

distribution rule with amounts.

3. Specify the settlement type for each settlement rule.

The system defaults the settlement type depending on the receiver, for example PER for cost

center, FUL for fixed asset. You can overwrite the default value, if required. When you save the sender object, you automatically save the settlement rule.

See also:

Distribution rule

 

 

Settlement Methods 

For almost all sender objects there is an individual and a collective settlement.

You use individual settlement when you want to analyze the settlement results in greater detail.

You use collective settlement to process a large number of sender objects. This is generally used during period-end closing to start the settlement in the background.

You can choose to simulate settlement (test run) or start it as an update run. For given objects, you can run the settlement in the background or get the system to display the settlement results in a detailed list.

Repeating Settlements Within a Period

You can repeat settlement for a given period at any time. For example, because postings were made in that period after settlement had taken place.

Note the following:

If you have already settled for subsequent periods, you must first reverse the settlements for those periods.

You can only repeat settlements in a period if the settlement documents have not yet been

archived. See ( Settlement History). When you repeat settlement in a period, the system only considers the postings that you

made since the last settlement. This is also the case when you post this type of settlement in a later period.

You can also carry out settlement in a later posting period instead of within the settlement period. This is useful if the settlement period is already locked for the posting period, but not all costs have been settled for the settlement period. However, you must have performed the settlement within the current fiscal year.

Reversing Settlements

Settlements can be reversed both for individual settlement and collective settlement. However, you can only reverse the last settlement you performed for a sender. If you have settled a sender more than once within a period, you must also reverse the settlements one by one. First, you reverse the last settlement for the period, then the second-to- last, and so on.

If, within a given period, you want to reverse a settlement from a previous period, you must first reverse the subsequent settlements.

For example, you are in period 6 and you want to reverse the settlement for period 4. You first have to reverse any settlements for periods 6 and 5.

 

 

Settlement History 

Each settlement must be uniquely identified in the system. To ensure this, the system creates a settlement document each time a sender object is settled. This document is stored in the system under a unique number.

The settlement document is required for the following business transactions:

Reversing settlements Repeating period-end closing

You define number ranges for the settlement documents in the configuration menu of the sender object.

Define separate controlling areas and separate number range intervals for the settlement documents. If you want to perform settlement in different controlling areas at the same time (for example, on the same day), system performance is improved if you define separate number ranges for each controlling area.

The settlement documents use up additional storage space. Therefore, you should archive the settlement documents once a posting period has been locked against posting, both in Controlling (CO) and in Financial Accounting (FI). When you specify the residence time in the settlement profile, you should always keep to a security deadline.

In addition to the settlement document, the system creates an accounting document for the financial accounting part of the settlement. It also creates a controlling document for the cost accounting part.

 

 

Currency 

The settlement can be updated different currencies: It takes place in one of the following currencies:

Controlling area currency Object currency of the sender

This is the currency defined in the master record of the sender object. Credits for the sender are updated in this currency.

Object currency of the receiver

This is the currency defined in the master record of the receiver object. Debits for the receiver are updated in this currency.

The transaction currency for the settlement

The exchange rate type is used to store different exchange rates in the system. The system automatically uses exchange rate type M for settlement.

 

 

 

 Carrying Out Settlement 

Prerequisites

After you have created a settlement rule, actual costs have been incurred on the sender object, and all the settlement prerequisites for that sender have been met, you can settle the costs incurred.

You can use individual or collective processing.

Refer to the documentation on the various sender objects for details of what selection possibilities you have for each particular object.

This documentation also tells you what the sender-specific prerequisites are for the objects in question.

Procedure

1. Choose Settlement from the application menu of the object you want to settle.2. Make the relevant entries

for the order when you are in individual processing. for the selection variant when you are in collective processing.

In contrast to assessment, you cannot perform settlement across fiscal year boundaries.

The system automatically determines the posting date from the posting period and the fiscal year. The posting date is the last day of the posting period. There is no input field for this, but the date does appear, for example, in settlement documents.

o Asset value date

This is the date for valuation in Asset Management. You can enter the date in the initial screen in the settlement or derive it from the settlement rule for the sending or

receiving asset. In certain cases this field does not appear, for example the settlement of production orders

o Processing type

There are 3 processing types defined for settlement:

Automatic

The system selects all the distribution rules for a sender. Note the following special features:

If a sender only has distribution rules with settlement type PER, the system only selects and settles the costs of the settlement period.

If a sender has distribution rules with settlement type PER (PER rules) as well as distribution rules with settlement type FUL (FUL rules), the PER rules are applied first to the costs for the settlement period. If any costs are left after that, the FUL rules are applied.

A production order with the FUL settlement rule to materials is not settled until the final delivery is received. However, if any work in process is calculated for the order (results analysis for orders), the related values can be transferred to Financial Accounting.

For capital-investment measures, FUL rules are not applied until the measure is technically closed (compare "partial capitalization"). Assets under construction (AUC) are always settled, regardless of status.

Periodic

All distribution rules with settlement types PER and AUC are selected. PER rules are applied first. In capital-investment measures, this is followed by settlement to assets under construction.

Partial capitalization

Use this processing type if you want to partially capitalize a capital-investment measure which is not yet complete, that is, if you want to settle part of the total costs to finished assets.

Results

Settlement Log

The settlement log is divided into three main sections:

Basic list

In the basic list for collective processing, the system displays the results of the settlement, for example, the number of messages. It goes on to list the processing senders based on the following categories:

Category Number of senders

Fully settled that were correctly settled.

Fully reversed that were fully reversed.

Not to be reversed that were already fully reversed.

Zero balance that were already settled or senders that do not have inventory (actual costs).

Created/closed that have system status "Created" or "Closed".

Locked for settlement that are not planned for settlement A reversal is therefore also not possible.

In processing that are being processed. A sender is being processed, when a user changes the settlement rule during settlement.

Partially settled that were not completely settled. A settlement can be described as partial if an object is debited again by another sender during the same settlement run.

Incorrect Number of senders for which errors occurred. These might be, for example, senders which have been released, but for which no settlement rule was created.

Messages

You can display the messages issued during settlement by

choosing Messages. During background processing the messages are output in the settlement log.

Detail list

The system only outputs a detail list if you choose the corresponding option in the Settlement initial screen. Choose Detail list to see the list displayed. During background processing the messages are output in the settlement log if required.