SAP FI Notes

 Client  

Use

The client is the highest level in the SAP System hierarchy. Specifications that you make, or data that you enter at this level are valid for all company codes and for all other organizational structures. You therefore only need to make these specifications, or enter this data once. This ensures that the data is consistent. 

Users must enter a client key when they log on to the SAP System. This defines the client in which they wish to work. All the entries you make are saved per client. Data processing and analysis is also carried out per client. This means that you cannot include customer accounts from different clients in one dunning run. Access authorization is assigned per client. You must create a user master record for each user in the client where he or she wishes to work. The SAP System is delivered with the clients 000 and 001 - these clients already contain default settings. For more information, see Setting Up Clients in Customizing. These sections are automatically selected when you create your implementation projects (company IMG, project IMG).

 

Company  

Use

A company’s financial statements also form the basis of consolidated financial statements.

All of the company codes within a company must use the same chart of accounts and fiscal year. However, each company code can have a different local currency. 

To define a company, choose the following in Customizing for the Enterprise Structure: Definition  Financial Accounting  Define Company 

You must assign your companies to your company codes. To do so, choose Assignment  Financial Accounting  Assign Company Code to Company in Customizing for the Enterprise Structure. 

 

Company Code  

Use

The company code is the central organizational unit of external accounting within the SAP System. You must define at least one company code before implementing the Financial Accounting component. The business transactions relevant for Financial Accounting are entered, saved, and evaluated at company code level. 

You usually create a legally independent company in the SAP System with one company code. However, you can also define a company code according to other criteria. A company code could also be a separate, but not independent, commercial place of work. This is necessary for example, if the place of work is actually situated in a different country and evaluations therefore have to be carried out in the appropriate national currency and in accordance with other tax and legal specifications. 

If you want to manage the accounting for several independent companies simultaneously, you can set up several company codes in one client. You must set up at least one company code in each client. 

To define a company code, choose the following in Customizing for the Enterprise Structure: Definition  Financial Accounting  Define, Copy, Delete, Check Company Codes. 

 

Business Area  

Use

Business areas are used in external segment reporting (over and above company codes), based on the significant areas of operation of a company (for example, product lines, branches).

To define business areas, choose the following in Customizing for the Enterprise Structure: Definition  Financial Accounting  Define Business Area. 

If you have defined business areas, the transaction figures for the G/L accounts are managed separately for internal evaluation purposes. You can therefore create internal financial statements for business areas. 

If you want to create financial statements for business areas, you must make sure that the Business area field is ready for input in all the line items. To do this, proceed as follows in Customizing for Financial Accounting: Financial Accounting Global Settings  Business Area  Enable Business Area Balance Sheet. 

Chart of Accounts  

Use

You have to assign a chart of accounts to each company code. This chart of accounts is the operating chart of accounts and is used for the daily postings in this company code.

You have the following options when using multiple company codes:

• You can use the same chart of accounts for all company codes

If the company codes all have the same requirements for the chart of accounts set up, assign all of the individual company codes to the same chart of accounts. This could be the case if all company codes are in the same country.

• In addition to the operating chart of accounts, you can use two additional charts of accounts

If the individual company codes need different charts of accounts, you can assign up to two charts of accounts in addition to the operating chart of accounts. This could be the case if company codes lie in multiple countries.

The use of different charts of accounts has no effect on the balance sheet and profit and loss statement. When creating the balance sheet or the profit and loss statement, you can choose whether to balance the company codes which use different charts of accounts together or separately.

Fiscal Year  

Use

In order to assign business transactions to different time periods, you must define a fiscal year with posting periods. Defining the fiscal year is obligatory. 

You define your fiscal year as fiscal year variants which you then assign to your company code. One fiscal year variant can be used by several company codes. 

You have the following options for defining fiscal year variants:

• Fiscal year same as calendar year 

• Fiscal year differs from calendar year (non-calendar fiscal year). The posting periods can also be different to the calendar months.

You define your fiscal year variants in Customizing for Financial Accounting as follows: Financial Accounting Global Settings  Fiscal Year  Maintain Fiscal Year Variant (Maintain Shortened Fiscal Year) 

Shortened Fiscal Year  

Use

When you define a shortened fiscal year, you have to make the following specifications:

• A shortened fiscal year must always be defined as year-dependent, since it can only apply to a specific year and must be followed by a complete fiscal year. 

• You define a shortened fiscal year and the following or previous complete fiscal year in one fiscal year variant. 

You define a shortened fiscal year in Customizing for Financial Accounting as follows: Financial Accounting Global Settings  Fiscal Year  Maintain Fiscal Year Variant (Maintain Shortened Fiscal Year) 

 

Special Periods  

Use

Irrespective of how you have defined your fiscal year, you can also use special periods. Special periods subdivide the year-end closing period. They therefore merely divide the last posting period into several closing periods. This enables you to create several supplementary financial statements.

 

A fiscal year usually has 12 posting periods. In General Ledger Accounting, you can define up to four special periods. 

If you do not need 12 posting periods, you can use the posting periods that are not required as special periods. If you use these additional closing periods, you must specify the number you require in the field No. special periods. when defining the fiscal year variants. You cannot exceed a maximum of 16 periods.

Determining Posting Periods During Posting  

Use

When you record a document, you enter the posting date. When you post the document, the system uses the posting date specified to automatically determine the posting period. The posting period consists of a month and a fiscal year.

These are both displayed in the document overview. The posting period determined is entered in the document and the transaction figures for this period are updated.

If you want to display the balance of an account, the transaction figures are displayed separately according to posting periods. This process is illustrated below:

 

Opening and Closing Posting Periods  

Use

You define posting periods in your fiscal year variants. You can open and close these posting periods for posting. As many periods as you require can be open for posting simultaneously.

Usually, only the current posting period is open for posting, all other posting periods are closed. At the end of this posting period, the period is closed, and the next posting period is opened.

Special periods can be open for closing postings during the period-end closing.

 Opening New Fiscal Years  

Use

The new fiscal year is automatically opened when you make your first posting in the new fiscal year or once the balance carried forward program has been run. You do not have to close the old fiscal year before you can post data in the new one. You therefore do not need to create closing or opening financial statements.

Carrying Forward Balances  

Use

This process involves carrying forward account balances into the new fiscal year. The balance to be carried forward is shown in the account balance display. To carry forward balances, you can use separate programs for G/L accounts, and for customer and vendor accounts. 

You therefore do not even have to carry out the balance carry forward manually if you have already posted to the new fiscal year. 

The balance carry forward is executed as follows:

Balance Sheet and Customer and Vendor Accounts

• The balances on the balance sheet accounts are simply carried forward into the new fiscal year.

• Additional account assignments are transferred.

Profit and Loss Accounts

• Profit and loss accounts are carried forward to retained earnings accounts. The balances of the profit and loss accounts are set to 0.

• Additional account assignments are not transferred. 

• Transaction currencies are no longer applicable and the profit and loss accounts are summarized in local currency. 

Currencies  

Use

For each monetary amount that you enter in the SAP System, you must specify a currency. You enter currencies as the ISO standards, for example, USD for US dollar. 

You define currencies in Customizing. To do this, in Customizing choose SAP Net Weaver ® General Settings ® Currencies ® Check Currency Codes.

In Financial Accounting, you have to specify for each of your company codes, in which currency ledgers should be managed. This currency is the national currency of the company code, that is, the local currency (or company code currency). From a company code view, all other currencies are then foreign currencies.

You can manage ledgers in two parallel currencies in addition to the local currency, for example, group currency or hard currency. For more information, see

● General Ledger Accounting (new) under Parallel Currencies in Parallel Ledgers and

● classic General Ledger Accounting under  Parallel Currencies in Financial Accounting.

In order for the system to translate amounts into various currencies, you must define exchange rates. For each currency pair, you can define different exchange rates and then differentiate between them by using exchange rate types.

Exchange Rates  

Use

You define exchange rates in the system for the following purposes:

• Posting and Clearing

To translate amounts posted or cleared in foreign currency, or to check a manually entered exchange rate during posting or clearing. 

• Exchange Rate Differences

To determine gains or losses from exchange rate differences.

• Foreign Currency Valuation

To valuate open items in foreign currency and foreign currency balance sheet accounts as part of the closing operations. 

You define exchange rates in Customizing under General Settings  Currencies  Enter Exchange Rates. 

Exchange rates are defined at client level and therefore apply for all company codes. 

Exchange Rate Types  

Use

You can define different exchange rates for each currency pair. You then differentiate between these exchange rates using the exchange rate type. 

You need different exchange rates for the following purposes, for example:

• Valuation 

• Conversion 

• Translation 

• Planning

You define exchange rate types in Customizing under General Settings  Currencies  Check Exchange Rate Types. 

Reference Currency  

Use

You can assign a reference currency to an exchange rate type. For every other currency, you enter the exchange rate in the reference currency. All other translations are carried out using the reference currency. 

You can only use the reference currency for exchange rate type M (average rate), and not for buying or bank selling exchange rate types. 

You specify USD as the reference currency. To translate from GBP to DEM, the system uses the GBP/USD and DEM/USD exchange rate specifications.

You can specify several reference currencies for one exchange rate type. This may be necessary for example, to comply with legal regulations. 

To specify a reference currency for an exchange rate type, proceed as follows in Customizing: General Settings  Currencies  Check Exchange Rate Types. 

 

Exchange Rate Spread  

Use

For exchange rate types, you can define fixed exchange rate spreads between average rate and buying rate, as well as between average rate and bank selling rate. 

You then only have to enter exchange rates for the average rate. The system then calculates the exchange rates for the buying rate and bank selling rate by adding and subtracting the exchange rate spread for the average rate. 

SAP recommends defining a reference currency for the average rate and then entering exchange rate spreads for the buying and bank selling rates. This combination is particularly efficient since you only have to enter exchange rates for the individual currencies to the reference currency for the average rate exchange rate type. The system calculates all the other exchange rates. 

 

Parallel Currencies in Financial Accounting  

Use

In Financial Accounting, you can define up to two parallel currencies in addition to the local currency. Your ledgers are thereby managed in these parallel currencies in addition to the local currency. 

You can use various different currency types as parallel currencies. You define the currency for a currency type when you define the organizational units. 

• Group Currency

You define the group currency when you define your client. 

• Company Currency

You define the company currency when you define the company that is assigned to your company code. 

• Hard Currency

You define the hard currency when you define the country that your company code is assigned to. 

• Index-Based Currency

You define the index currency when you define the country that your company code is assigned to. 

You can use a maximum of two parallel currencies (second and third local currencies). 

If you have defined the group currency as the second local currency, this has no additional effects. In all other cases, in the application component  Special Purpose Ledger you have to define an additional ledger in which transaction figures are managed. 

TAXES (FI-AP/AR)  

Purpose

You can use the SAP System to manage various types of tax according to the legal requirements of a country or a region. The Financial Accounting components Accounts Receivable (FI-AR), Accounts Payable (FI/AP), and General Ledger provide the following comprehensive tax functions:

• Tax calculation

The system calculates tax amounts with or without cash discount based on the tax base amount. 

Tax codes are used to calculate and check the amounts. 

• Tax posting

The system posts the tax amounts to defined tax accounts. 

• Adjustments

The system corrects tax amounts, in the case of cash discount or other deductions, for example. 

• Tax reporting

You can use the system to create tax returns.

Local Taxation  

Use

In countries where taxes on sales/purchases are levied locally, the system allows you to post your taxes and to generate your tax returns below company code level.

 Business Place  

Use

The business place is used in countries that by law require returns for taxes on sales/purchases to be submitted at a level below the company code. For this reason, companies have to register each business place with the tax authorities as the unit responsible for tax reporting. 

In some countries, the business place is also used to assign official document numbers to outgoing documents and so it is the level at which these documents are issued. In most cases, these documents are concerned with value-added tax (VAT) or similar tax types. 

You can also use the business place for the  payment program, whereby you can make separate payments per business place, and separate house banks can be filtered per business place. This function is currently available for Brazil, South Korea, and  Thailand. 

SAP supports business place functions for the following countries; how it is used varies according to the country in which it is employed: 

1. Brazil

2. Philippines

3. South Korea

4. Taiwan

5. Thailand

You can activate the business place for other countries, but note that SAP does not support its usage.  

 Activation of Business Place  

Use

You activate the business place at the country level. 

SAP fulfills the legal requirements associated with the business place for the following countries: Brazil, Philippines, South Korea, Taiwan, and Thailand. Although you can activate the business place for other countries, SAP does not support its usage in those countries.

 Official Document Numbering  

Use

In some countries, you have to assign official document numbers to outgoing documents at business place level.

   How Taxes Are Recorded  

Purpose

In countries where taxes on sales/purchases are levied locally, you have to post your taxes below company code level in order to generate your tax returns locally. In order to do this, you assign your invoices to a business place. This means that the business place is the level at which vendor invoices are entered and customer invoices are issued.

 

 Entering the Business Place in Vendor Invoices (FI)  

Use

In financial accounting documents, the system has to capture the business place information at line item level. In order for this to happen, when you post a vendor invoice in Accounts Payable (FI-AP), you follow the  standard procedure and, in addition, you assign the invoice to the correct business place in the header.

 

 Entering the Business Place in Vendor Invoices (MM)  

Use

When you post a vendor invoice in Logistics Invoice Verification (MM-IV-LIV), the system has to capture the business place information at line item level for the financial accounting document it generates. In order for this to happen, you follow the  standard procedure and, in addition, you assign the invoice to the correct business place.

 Entering the Business Place in Customer Invoices (FI)  

Use

In financial accounting documents, the system has to capture the business place information at line item level. In order for this to happen, when you post a customer invoice in Accounts Receivable (FI-AR), you follow the  standard procedure and, in addition, you assign the invoice to the correct business place in the header.

 

 Posting Customer Invoices (SD)  

Use

When you post a customer invoice in Sales and Distribution (SD-BIL), the system has to capture the business place information at line item level for the financial accounting document it generates. This happens automatically when you follow the  standard procedure.

 Tax Returns  

Use

In countries where taxes on sales/purchases are levied locally, the SAP System allows you to generate your tax returns per business place.

Entering Taxes with Jurisdiction Code  

Use

The jurisdiction code is a key which (together with the tax code) determines the tax amount and the way in which payment of the total tax amount is divided between different tax authorities. Jurisdiction codes are used in the USA and Brazil.

Jurisdiction codes are made up of multiple levels. They can have three levels, for example:

250221105

25 = State code

022 = County code

1105 = City code

Advance Return for Tax on Sales and Purchases with XML  

Use You can use report RFUMSV00 to create your advance return for tax on sales and purchases in XML (Extended Mark-up Language). You get an XML file that you can process further as required to then submit the return to the local tax authorities. XML offers a flexible alternative to the static, proprietary formats currently used for data transfer in several countries.

In several countries, the national tax authorities are currently preparing to receive tax returns in XML in the future.

 Data Medium Exchange Engine  

Use

The Data Medium Exchange (DME) Engine enables you to define file formats that meet the requirements of your financial institution. By doing so, you model an externally defined bank format in the R/3 System, which allows you to send or receive data in the form of DME files in this format.

The ability to define these formats in the R/3 System is particularly important as there is no worldwide or regional standard format. In some cases, no country standard exists and the file must comply with bank-specific standards. Covering such numerous and varied local format requirements is very difficult in standard software, but the DME Engine now enables you to define your particular local format yourself – without any ABAP programming knowledge or coding. With this Customizing tool, in the form of a graphical editor, you can define new formats flexibly and, as format requirements change, modify existing ones efficiently. 

Plants Abroad  

Use

You can process tax returns for warehouses or sales and distribution centers abroad using domestic company codes.

These tax returns may be:

• Tax returns to a foreign tax authority

• EC sales list for another EU country

This procedure simplifies the process of making tax returns for companies with several plants or warehouses abroad. Note that these are not real operation centers abroad; you would have to create separate company codes for these.

You should only use this function if you have several warehouses, distribution centers, or plants abroad.

If however, you only have individual warehouses abroad for example, you should set up a separate company code for each warehouse. Otherwise the functions and scope of the Customizing settings for plants abroad would be too complicated for a single entity abroad.

For more information, see the Implementation Guide (IMG) for Financial Accounting under Financial Accounting Global Settings  Tax on Sales/Purchases  Basic Settings  Plants Abroad.

The Calculation Procedure  

The following topics describe the basic structure of a calculation procedure and how it is maintained, including the settings you need to make in Customizing. For detailed information on how to make these settings, see the Implementation Guide for Financial Accounting under Financial Accounting Global Settings  Tax on Sales/Purchases. See also Configuring the System Using the Implementation Guide.

Calculation Procedure: Overview 

The Condition Type 

The Process Key 

The Condition Type  

You define the following information for each condition type:

• Condition type and condition class. For example, where tax is to be calculated, the condition type might be "base amount" (K) or "tax" (D), and the condition class "base amount" (A) or "tax" (D).

• Calculation rule: Either "percentage included" (A) or "percentage separate" (I) 

• The side of the account to which the tax amount is posted. This need only be specified for additional taxes, since these (in contrast to input, output, and acquisition tax) can be posted to either side of the account. If you want tax to be posted to the opposite side of the account, select the +/- sign field.

• Whether it is possible to change the tax amounts and percentages (which are displayed on a special screen) when you enter a document. To make this possible, choose the Manual entries field, then choose either Rate/percent (to make the percentages changeable), or Value (to make the tax amounts changeable).

The Process Key  

The process key contains the following properties:

• Tax type. This is required for reporting purposes, to be able to determine where the individual tax line items in a document are to be displayed. As tax type you can specify either output tax ( 1 ), input tax ( 2 ), additional tax ( 3 ) or not relevant to tax ( 4 ).

• Non-deductible input tax. This specification is also required for reporting. When input tax and non-deductible input tax is posted, separate line items are created if the non-deductible part is not to be distributed to the G/L account line items and asset line items. For tax reporting, you must indicate the input tax line items that do not display the non-deductible portion of input tax.

• Posting indicator. You specify whether the tax amount is posted separately ( 2 ) or distributed between expense and revenue line items ( 3 ). 

The system posts tax to the tax accounts automatically. You can specify tax account numbers for each process key. This is not necessary for process keys for which it has been specified that the tax amount is to be distributed (posting indicator 3 ). Therefore, these keys are not offered in the function for entering the tax account numbers.

Withholding Tax  

Use

To calculate, pay, and report the withholding tax, the SAP System provides two functions:

1. • Classic Withholding Tax (all Releases)

2. • Extended Withholding Tax (from Release 4.0)

For each company code, you can decide whether you want to use classic or extended withholding tax. Since the extended withholding tax option includes all the functions of classic withholding tax, SAP recommends the use of extended withholding tax (see below: Table of Classic and Extended Withholding Tax Functions).

If you have previously used classic withholding tax, and now wish to change over to extended withholding tax, you must first convert the withholding tax data in all the company codes affected. Do not activate extended withholding tax before you have converted the data.SAP has developed a special tool to support the withholding tax changeover. For more information, see Withholding Tax Changeover 

Classic and Extended Withholding Tax Functions

Individual Functions Classic Withholding Tax Extended Withholding Tax

Withholding tax on outgoing payment X X

Withholding tax on incoming payment X

Withholding tax posting at time of payment X X

Withholding tax posting at time of invoice X

Withholding tax posting on partial payment X

Number of withholding taxes for each document item Max. 1 Several

Withholding tax base: Net amount X X

Modified net amount X

Gross amount X X

Tax amount X

Modified tax amount X

Rounding rule X

Cash discount considered X

Accumulation X

Minimum/maximum amounts and exemption limits X

Number assignment on document posting (certificate numbering) X

Calculation formulas X X

Country-Specific Requirements

Due to legal requirements, the following countries use extended withholding tax:

America Europe and Africa Asia/Pacific

Argentina United Kingdom India

Brazil Slovakia The Philippines

Chile Turkey South Korea

Colombia Thailand

Mexico

Peru

Venezuela

Entering and Posting Withholding Tax  

Two transactions are to be distinguished for withholding tax:

• Invoice entry

• Invoice payment

When you enter the invoice, the system determines the base amount for withholding tax and stores it in the document. You can also enter the base amount directly.

When the invoice is paid, the tax amount is calculated from the base amount and your specifications for the tax code. If the tax amount is to be paid to the tax authorities, the system automatically posts the amount to the tax account. The system reduces the payment amount to the vendor by the withholding tax to be paid. If the amount is only to be reported to the tax authorities, no posting is made and the whole invoice amount is paid to the vendor. 

Invoice entry

When you enter a document, the withholding tax code from the vendor master record is defaulted. You can overwrite this code. In addition, you can enter a withholding tax base amount and a tax-exempt amount. If you enter both amounts, the system checks whether the total of the amounts exceeds the invoice amount. If this is the case, a warning message is issued.

If you do not enter any amounts, the system determines them by means of the tax code. To do this, it determines the base amount. The withholding tax exempt amount results from the difference between the invoice amount and the withholding tax base amount.

All specifications for the withholding tax refer to the document currency.

Invoice payment

If the tax amount is to be paid to the tax authorities, the system automatically posts the amount when clearing the item to the tax account. The posting is made when using the payment program to make payment, or with manual payment settlement.

When using the general clearing function, you must select a clearing procedure. This transaction influences the posting of withholding tax. Withholding tax is posted for all transactions which are relevant for payment. For these transactions, at least one of the posting keys you specified for the transaction must be characterized as relevant for payment. Otherwise, no taxes are posted. See also Example: Posting Withholding Tax.

Generic Withholding Tax Reporting  

Use

You use this program to:

• Prepare withholding tax reports 

• Prepare withholding tax returns (either on paper or as a DME file) 

• Print withholding tax certificates for vendors or customers

You can use the program irrespective of whether you use Classic Withholding Tax or Extended Withholding Tax.

Extended Withholding Tax  

Use

With extended withholding tax, you can process withholding tax from both the vendor and customer view.

In Accounts Payable, the vendor is the person subject to tax, and the company code is obligated to deduct withholding tax and pay this over to the tax authorities on the vendor’s behalf. In Accounts Receivable, the company code itself is subject to tax, and the customers that do business with this company code deduct withholding tax and pay this over to the tax authorities on the company code’s behalf. In both cases, the business partner of the person/entity subject to tax deducts the tax and pays it over to the tax authorities.

Document Entry, Document Change, and Document Display  

Use

Withholding tax is taken into account in all normal posting transactions. The withholding tax information must therefore be entered here.

Clearing with Extended Withholding Tax  

Use

For withholding tax types with posting at time of payment, the withholding tax is calculated and posted when open items are paid. When you clear open items without a payment (transfer posting), no withholding tax is posted. 

If you implement extended withholding tax, you cannot carry out the following functions when processing open items or clearing items automatically:

• Distribution by age 

• Automatic search

If you select these functions, your selections are reset and the system displays an appropriate message.

Document 

Use

You can only check whether postings are correct in the compact journal and general ledger by means of documents. Every posting must therefore have a document.

Documents are the link between the business transaction and the posting in accounting.

Only complete documents can be posted. A document is complete when its debit and credit items balance to zero. You must enter the minimum account assignments designated by the system: For example, document date, posting date, document type, posting key, account number, and amount. Data must also be entered in all other fields that were defined as required fields when making system settings.

Entering Document Headers  

Use

The document header contains data that applies to the entire document. To enter a document, you must first enter the document header.

Line Items  

Use

You can enter terms of payment, a cost center, or an explanatory text in a line item for example.

Editing Line Items  

Use

Before you post a document, you can display the document overview and then edit one or more line items. In this way, you can correct any input errors.

See Document Overview

Generating Line Items Automatically  

Use

Depending on your system’s configuration, you can have the system generate and post line items automatically.

Document Types  

Use

The document type has the following functions:

• Differentiating between business transactions. The document type tells you instantly what sort of business transaction is in question. This is useful, for example, when displaying line items for an account.

• Controlling the posting to account types (vendor, customer, or G/L accounts). The document type determines which account types that particular document can be posted to.

• Assigning document numbers. A number range is assigned to every document type. The numbers for the documents you create are taken from this number range. The original documents from one number range should be stored together. In this way, the document type controls document storage.

For more information, see Document Number Assignment and Controlling Document Storage Using the Document Type 

• Applying the vendor net procedure. This means that any discount and the net amount are calculated (and posted) when the vendor invoice is posted.

Defining Authorizations for Document Types  

Use

You can define a special authorization for every document type. To do this, you need to determine what document types in which form employees are allowed to process.

Authorizations are checked for the following activities:

• Posting documents

• Document display and line item display

• Changing documents

• Programs that evaluate documents.

The system does not check the authorization for document types that are not assigned an authorization group.

Defining the Document Type for the Vendor Net Procedure  

Use

When you post a vendor invoice, you use the document type to specify whether you want to use the vendor net procedure. In this procedure, the system automatically splits the offsetting postings into the net amount and the cash discount due. This is done when the document is posted.

The vendor net procedure can be used for example, to post vendor invoices to assets. The exact acquisition amount, less any cash discount, is posted to asset accounts.

Document Number Assignment  

Use

In the SAP System, every document is assigned a number that identifies it uniquely within a fiscal year and company code. 

There are two types of number assignment:

• External (by the user)

The accounting clerk enters the number of the original document during document entry, or the number is transferred automatically from a pre-invoicing system. A prerequisite is that the document numbers are unique. The system checks whether the number entered already exists and prevents users from assigning the same number twice. Numbers assigned to documents that have been archived however, can be reused.

• Internal (by the system)

The system automatically assigns a sequential number. The accounting clerk transfers this SAP document number to the printed original document and then files it using this number. This method is used if the original documents do not have a unique document number. This is the case, for example, with vendor invoices. 

You use a number range to define how the document number is assigned. Each document type has a specific number range from which the document number is selected.

Defining Number Ranges  

Use

You can define number ranges as follows:

• You can define number ranges for each company code. Thus, each company code can use the same number interval. 

• You can define number range intervals as year-specific.

You define number ranges in the system separately for master records and documents. You can therefore use the same number range keys for both master records and documents.

In the Financial Accounting (FI) component, you can also define alphanumeric number ranges. In this case, however, the document numbers can only be assigned externally.

It is advisable to select year-specific number ranges. You therefore only need smaller intervals and can store the document numbers separately according to fiscal years. You therefore avoid documents from the old and new year alternating in January.

Defining Number Ranges for Recurring Entry and Sample Documents  

Use

Sample documents are used as a reference when you enter accounting documents manually. They simplify document entry. You can post regularly recurring entries using the recurring entry program. To do this, the program requires a recurring entry document. Transaction figures are not updated by a sample document or recurring entry document. They are special documents that are only used to create accounting documents.

For sample and recurring entry documents, you need to set up special number ranges in every company code in which these special documents are used.

Changing and Deleting Number Ranges  

Use

You can change the specifications for a number range, for example the number interval or the validity period.

Changes may be necessary if a number range is not large enough. In this case, you can

• Increase the upper limit of the number range or specify a new lower limit as long as another range does not already have the desired numbers 

• Assign a new number range to the document type

Organizing Document Storage  

Use

If you store your documents correctly, you can ensure a clear link between the original document and the processing document. Always store your original documents under the processing document number (see the following illustration).

Depending on whether you want to store customer or vendor documents, you can choose from different types of document storage.

For customer documents, you either use the document number created by a pre-invoicing system, or have the system assign numbers using the internal number assignment function. 

For vendor documents, have the system assign the processing document number. Record the processing document number in the original document (see the following illustration). Enter the number of the original document in the reference number field in the header of the processing document. The original document number can then be used in correspondence and system queries. You can use the reference number to search for the corresponding document in line item display.

Controlling Document Storage Using the Document Type  

Use

If you always store original documents under their processing document number, you can control how these documents are filed by using document types. All original documents that are posted with the same document type in the system are filed together. However, you also have the option to store several document types together.

You use document types to differentiate postings according to the different business transactions.

If you want to file documents separately by document type, you need to assign a separate number range to each document type.

In the following illustration, document type KG (vendor credit memo) was assigned to number range 02, and document type KR (vendor invoice) was assigned to number range 01. The original documents are stored accordingly.

If you want to file several document types together, you need to assign the same number range to them. For example, you can differentiate between the posting of vendor credit memos (document type KG) and vendor invoices (document type KR) using document types and then file these documents together using a joint number range

See also Document Number Assignment 

Document Entry  

Use

When you enter documents, the system checks whether the minimum account assignments have been made, for example, document date, posting date, document type, posting key, account number, and amount. If you enter a key that is not defined in the system, the system issues an error message. You have to correct your entry before you can enter any more documents. These checks prevent incorrect, inconsistent, or incomplete entries from being made.

To be able to post the document, the debits and credits must balance to zero. This updates the account balances. If the debits do not equal the credits, you can hold the document, or park it until it is complete, without updating G/L account balances.

Editing Options - Enjoy Transactions  

Use

You can use this function to make user-specific settings for:

• Document entry 

• Default document currency

In addition to the functions of the standard transaction, you can also use special options for the single screen transaction. 

Holding and Setting Data  

Use

You can hold (retain) or set (specify) data in various screens. The system then defaults this data when you re-enter the relevant screen. For example, you can hold the document date or a special G/L indicator.

Fast Entry of G/L Account Line Items  

Use

When you are entering line items in General Ledger, Accounts Receivable, or Accounts Payable, you can call up a special screen for fast entry of G/L account line items.

To do this, choose Got G/L item fast entry. On the next data entry screen, you can make entries in the following fields:

• Pk (Posting key)

• Account (account number)

• Amount

• Tx (tax on sales/purchases)

• BA (business area)

• Cost ctr (cost center)

• Order

Control Functions for Entering and Posting Documents  

Use

There are special check routines for the fields in the document header and the individual line items. Pure information fields, such as the text field in the document header are excluded. In addition, the system carries out checks on the entire document during posting. You cannot post the document until all the checks have been carried out successfully.

The following control functions are available:

• The checks that the system carries out automatically when you enter and post a document

• The control totals check that you select from the Financial Accounting menus.

Holding Documents  

Use

When you are entering data, you may be interrupted, or you may not have all the data you need for entering a document, for example bank charges or the appropriate cost center.

In this case, you can temporarily save the data you have entered, and then continue with the document entry at a later time. If you want the system to hold a document, it does not have to be complete. Account balances are not updated and the document data is not available for evaluation. A document number is not assigned.

Simulating Documents  

Use

You can simulate a document before you actually post it. This gives you an overview of the document items you have already entered, and you can check whether they are complete and correct. During simulation, the document goes through all the checks required for posting. For more information, see: Control Functions for Entering and Posting Documents

When you simulate a document, the automatically generated items, such as input tax and tax on sales and purchases, are displayed.

Parking Documents  

Use

You can use document parking to enter and store (park) incomplete documents in the SAP System without carrying out extensive entry checks. For more information, see Document Parking

Parked documents can be completed, checked, and then posted at a later date - if necessary by a different accounting clerk.

When documents are parked, data (for example, transaction figures) is not updated. The only exception to this is in Cash Management (TR-CM).

Data from parked documents can however be used for evaluations by the system. For example, amounts from parked invoices can be used for the advance return for tax on sales and purchases. Using payment requests, parked invoices can be paid punctually and without loss of discount.

You can use the tax amounts determined on the basis of the data in parked documents to apply in advance to the tax authorities for any tax receivables that are due to you. From the SAP Easy Access screen, choose Accounting  Financial accounting  General ledger  Reporting  Tax reports  General  Input tax from parked documents. 

Document Parking  

Use

You can park data relating to customer, vendor, G/L, and asset accounts. There is an additional fast entry function for G/L accounts. For assets, you can only enter acquisitions. In addition, you can park tax information and special G/L indicators, although you cannot park special G/L indicators for bills of exchange and down payments.

SAP provides two transactions for document parking: The standard transaction and the single screen transaction (Enjoy). 

You cannot switch between both transactions. 

Posting Parked Documents  

Use

Using the standard transaction, you can post parked documents individually our using a list selection. If you post several parked documents using a list, the system issues a list when you have finished. This list details which documents were successfully posted.

From this list, you can then carry out any necessary post-processing to parked documents that could not be posted due to missing information such as a cost accounting assignment. You can also create a batch input session to post the parked documents.

Changing Parked Documents  

Use

You can change a parked document and complete it step by step. A large number of header and item fields can be changed during this process, including the amounts.

You can make changes to:

• Individual documents

• Individual items

• Several documents simultaneously using a list

• Other values via the line items

However, you cannot change the currency and company code. 

The internal system change rules governing document entry are not used in document parking.

Document Parking and Release with Workflow  

Use

Standard Workflow Model

The standard system contains several workflow models for document parking: One workflow framework (WS10000051) and five sub-workflows. In Customizing for Financial Accounting, you define which sub-workflow model is used by the workflow framework at runtime. You can also enter your own sub-workflows. They must however send and receive the same data from the workflow framework as the sub-workflow models do. 

If you want to use the standard sub-workflow models for multi-level amount release (WS10000052, WS10000053, WS10000054), you can define between one and three levels for amount release. If you want to use more than three release levels, copy the workflow models for amount release and then expand them. If are not working with amount release, you can use a dummy sub-workflow model (WS20000006). You can use the fourth standard sub-workflow model (WS10000055) for the account assignment approval.

Standard Tasks

There are three standard tasks for document parking in the standard system. These can be triggered from the workflow inbox and used in the workflow models.

• Amount release

• Account assignment approval

• Changing a parked document after the release has been refused

You can search for these tasks using the short name "FIPP".

Displaying Documents  

Use

You can display posted or archived documents.

Line Item Display  

Use

In addition to displaying the entire document, you can also look at the individual line items posted to an account in the FI component. The document line items from the account view are called line items in the FI component.

The system already contains the required specifications for all these functions. Since these functions can greatly simplify the processing of line items, you should check whether the SAP settings fulfill your company’s requirements.

Defining Document Change Rules  

Use

You can define your own document change rules for selected fields.

Archiving Documents  

Use

You can archive documents that have already been posted. For more information, see the SAP Library under CA - Cross-Application Functions and the section Archiving FI Documents (FI-GL, FI-AR, FI-AP) 

You can display archived documents. See Document Display 

General Ledger Accounting (FI-GL)  

Purpose

The central task of G/L accounting is to provide a comprehensive picture for external accounting and accounts. Recording all business transactions (primary postings as well as settlements from internal accounting) in a software system that is fully integrated with all the other operational areas of a company ensures that the accounting data is always complete and accurate.

Cost of Sales Accounting  

Purpose

The profit and loss statement of an organization can be created according to two different procedures:

• Period accounting 

• Cost of sales accounting

Cost of sales accounting compares the sales revenue for a given accounting period with the manufacturing costs of the deducted activity. The expenses are allocated to the commercial functional areas (production, sales and distribution, administration, and so on). Expenses and revenues that cannot be assigned to the functional areas are reported in further profit and loss items, sorted according to expense and revenue type.

With this type of grouping, cost of sales accounting identifies where costs originate in a company. It identifies the economic reason for a particular expense.

Functional area  

Use

If you want to use cost of sales accounting, you have to use functional areas to sort your operating expenses.

You define your functional areas in Customizing under Financial Accounting  Financial Accounting Global Settings  Company code Cost of Sales Accounting  Define Functional Area.

Activating Cost of Sales Accounting  

Purpose

You can activate cost of sales accounting in your system.

Deriving the Functional Area  

Use

In order that expenses can be sorted according to corporate functions, the system derives the functional area for the following postings.

• Primary postings (postings in Financial Accounting) to a profit and loss account 

• Secondary postings (allocations in Controlling)

The functional area is derived for both objects involved in the allocation.

No functional area is derived in the following cases:

• Postings to balance sheet accounts 

• When creating statistical key figures in Controlling

The system derives the functional area after saving. The derived functional area is thus first available in the document created and not on the entry screen.

Reconciliation of Controlling and Financial Accounting  

Use

During allocations in Controlling, postings are created that do not affect Financial Accounting. These postings do not update any G/L account transaction figures, rather they are ordinary postings within Controlling.

If, however, an allocation in Controlling leads to a change in the functional area, a shift occurs in the affected items in the profit and loss statement. The change of functional area has therefore to be communicated back to Financial Accounting. This reconciliation between Controlling and Financial Accounting is effected with so-called reconciliation postings.

Creating a Profit and Loss Statement with Cost of Sales Accounting  

Use

You can create a profit and loss statement with cost of sales accounting. The profit and loss statement is organized according to your functional areas.

You can create a profit and loss statement with cost of sales accounting using the G/L account information system. The G/L account information system is based on the Drilldown Reporting tool and uses the G/L transaction figures from your cost of sales accounting ledger and your Financial Statement Versions. as data basis. The SAP R/3 System provides you with further evaluation tools such as the Report Writer. However, these tools do not support a financial statement version with functional areas. Using these tools to create a profit and loss statement is therefore more time consuming.

Parallel Valuation Methods  

Purpose

You have the option of depicting a parallel valuation method in your SAP system. This will allow you to carry out valuations and closing operations for a company code according to bother a local accounting principle and a second (parallel) accounting principle, for example the group accounting principle. You can depict more than two accounting principles in your SAP system. To simplify the description, however, the scenarios in this documentation use just two parallel accounting principles This is necessary, for example, for German subsidiaries of American groups. Here, the German subsidiary must provide financial statements according to both the German Commercial Code and the group accounting principle (such as US GAAP). 

Depiction Using Additional Accounts  

Use

You can depict a parallel valuation method in your SAP system by creating additional accounts. You thus have various account areas:

• A joint account area where postings are made that are the same for both accounting principle. 

• A separate area with specific accounts for each accounting principle. Each business transaction that leads to another posting is posted to the corresponding account area – depending on the accounting principle.

If you create a closing entry according to one of the accounting principles, both the joint accounts and the specific accounts are evaluated for this accounting principle. the procedure recommended by SAP is to depict a parallel valuation method using additional accounts. This procedure is particularly suitable if you want to depict a parallel valuation method where the two accounting principles do not differ in many cases with regard to the valuations. The number of additional accounts you require rises with the number of valuation differences between the accounting principles. If the accounting principles differ too strongly with regard to valuation rules, you are forced to create too many specific accounts, which in turn bloats the size of your chart of accounts.

With this procedure, all specific posting data for each accounting principle is stored in the general ledger. This serves to simplify reconciliation with or transfer to other SAP components. The disadvantage, however, is that items of data from various valuations are stored in one ledger.

Depiction Using an Additional Ledger  

Use

You can depict a parallel valuation method in your SAP system by storing posting data for the various accounting principles in separate ledgers.

• The data for one accounting principle is stored in the general ledger. This is known as the "leading" valuation view. 

• For each additional (parallel) accounting principle, you create an additional ledger in the Special Ledger component.

Depiction Using an Additional Company Code  

Use

You can depict a parallel valuation method in your SAP system by defining an additional company code. In this way, you post the valuation data for your parallel accounting principle to an additional company code.

 Parallel Valuation Methods in the Application Components  

Use

If you want to create your financial statements according to two parallel accounting principles, this means that you have to carry out different postings according to the accounting principle for certain business transactions. This means that various function and valuation reports in the individual SAP application components are affected by depiction of a parallel valuation method.

The following SAP application components support depiction of a parallel valuation method in their valuation reports and functions:

• Financial Accounting (FI) 

• Asset Accounting (FI-AA) 

• Corporate Finance Management (CFM) 

• Controlling (CO)

 Parallel Valuation Methods and Currencies  

Use

You can depict your parallel valuation methods in two parallel currencies. This means that you can carry out your valuations and closing operations according to two different accounting principles and in two different currencies.

 

Example of a parallel valuation method for a German subsidiary of an American group in two parallel currencies

Accounting principle Currency

HGB or German commercial code (Accounting principle for German subsidiary) EUR

US-GAAP (Group accounting principle) USD

The company code currency (local currency) must correspond to the national currency (local currency). This setting has to be made for various functions, such as for Reporting.

G/L Account Master Records  

Use

Before you can make postings to a G/L account, you have to create a master record in the system for the account.

Chart of Accounts List  

Use

You enter all the charts of accounts that you require for your company in this list. To do this, in the Financial Accounting Implementation Guide, choose General Ledger Accounting  G/L Accounts  Master Data  Preparations  Maintain Chart of Accounts List.

In the FI system, you can use as many charts of accounts as you require within a client. You can thus meet the varying needs of the individual company codes regarding the chart of accounts structure. The following characteristics of the individual company codes could, for example, place various demands on how the chart of accounts is set up:

• Location (country) 

• Branch 

• Corporate structure 

• Corporate size 

• Legal requirements

However, several company codes can also use a common chart of accounts if a different grouping of the chart of accounts is not required.

You must assign one chart of accounts to each company code. You therefore need at least one chart of accounts for your company in the system.

The chart of accounts is shared by Financial Accounting as well as cost/revenue accounting. The items in a chart of accounts can be both expense or revenue accounts in Financial Accounting and cost or revenue elements in cost/revenue accounting.

Chart of Accounts  

Use

You have to assign a chart of accounts to each company code. This chart of accounts is the operating chart of accounts and is used for the daily postings in this company code.

You have the following options when using multiple company codes:

• You can use the same chart of accounts for all company codes

If the company codes all have the same requirements for the chart of accounts set up, assign all of the individual company codes to the same chart of accounts. This could be the case if all company codes are in the same country.

• In addition to the operating chart of accounts, you can use two additional charts of accounts

If the individual company codes need different charts of accounts, you can assign up to two charts of accounts in addition to the operating chart of accounts. This could be the case if company codes lie in multiple countries.

The use of different charts of accounts has no effect on the balance sheet and profit and loss statement. When creating the balance sheet or the profit and loss statement, you can choose whether to balance the company codes which use different charts of accounts together or separately.

G/L Master Record in the Chart of Accounts  

Use

To make certain that company codes using the same chart of accounts can also use the same G/L accounts, a master record is created for the G/L account in the chart of accounts and in the company code-specific areas.

Account group  

Use

When you create a G/L account in the chart of accounts area, you must specify an account group.

Using the account group, you can group the G/L accounts according to functional area. 

For example, you can group all bank accounts, postal giro accounts, and cash in the account group FIN. for "liquid funds".

The account group also defines the set up when creating a G/L account in the company code and chart of accounts. By defining the number interval and the screen layout, you simplify G/L account creation by reducing the number of entry fields.

The account groups are entered in Customizing per chart of accounts. You do this in Financial Accounting Customizing under General Ledger Accounting  G/L Accounts  Master Data  Preparations  Define Account Group. 

Defining the Number Interval  

Use

Standard charts of accounts are recommended in most countries. These are generally created so that the numbers of accounts belonging to the same functional area begin with the same digits. You use the account group in the chart of accounts to indicate this grouping principle.

When you define an account group, you also determine the number interval in which the accounts of this group must lie. When creating a G/L account, the system checks whether the number you entered lies in the predefined number interval.

The account numbers of bank accounts, postal giro accounts, and cash accounts begin with the number 1. The accounts in account group "Liquid funds accounts", to which all of these accounts belong, all lie in the number interval between 100000 and 129999.

If you create a G/L account with this account group, you must select a number from this number interval. Account number 131000 for G/L account petty cash would be rejected as incorrect since it does not fall within the number interval of account group "Liquid funds". However, you could create this account using the account number 101000.

The number intervals for G/L account groups can overlap. As a result, for G/L accounts that you do not want to assign to any special functional area, you can create a separate account group that has a number interval already contained in a different account group.

Defining the Screen Layout  

Use 

The account group in which you can combine G/L accounts of a similar type determines the screen layout when creating G/L accounts in the company code-specific area. For each account group, you determine the screen layout, that is, you determine which fields are relevant for this group of G/L accounts.

For each field, you can assign the field status. This is important when creating G/L account master records in the company code-specific area. To preclude the need to give every field a status, fields are combined into field groups. 

You can assign the following field statuses to the fields of a field group.

Field status Description

Required entry This field requires an entry when creating a G/L account

Optional entry You may make an entry in this field when creating a G/L account

Display The field is displayed, but you cannot make an entry in it.

 You should not use this status, since the fields should be available for entry when creating

Suppressed The field is not displayed, that is, you do not see the field when creating a G/L account.

 

If you do not assign a field status, the field status "Suppress" is automatically used.

Field Status Definition  

Use

You have to define field status outside of the master record. Mark the field status you need for each field or field group under a field status group. Then assign the field status group to individual G/L accounts in the G/L account master records. 

Field status groups are independent of company code, attaching instead to the field status variant. A separate variant exists in each company code for field status groups in the standard system. The name of the variant is identical to the company code. Each company code is assigned to the variant with the same name. 

You can work with the same field status groups in more than one company code, as outlined below: Proceed as follows:

1. Maintain field status variants 

2. Assign a company code to the field status variant

Do not forget to maintain the field status. Otherwise, all fields are suppressed.

Changing the Account Group  

Use

You may need to change an account group, if fields do not have the necessary field status for creating G/L accounts.

You may need to change the account group, for example, if you want to implement a new application component that requires fields that originally were hidden. These fields now need an entry, that is, they have to be defined as required fields.

G/L Account Master Records in the Company Code  

Use

Before you can make postings to a G/L account, you have to create a master record in your company code for the account. The G/L account must already be in the chart of accounts. For more information, see G/L Account Master Records in Chart of Accounts.

Defining the Account Currency  

Use

When creating a G/L account, you must define the currency in which the account is to be kept.

This defines the following:

• The currency used for postings made to this account 

• The currency in which transaction figures are updated and the account balance is displayed

You specify the account currency in the company code area of the G/L account master data. This allows you to keep the G/L account in the local currency of each company code. This is especially useful for international groups that have all subsidiaries use the same chart of accounts but with the accounts kept in the local currency.

Defining "Balances in Local Currency Only"  

Use

When creating a G/L account in a company code, you can decide whether the transaction figures should only be kept in the local currency for this account.

You have to set this indicator for clearing accounts you use to clear line items in various currencies with one local currency amount and without posting any exchange rate differences that may occur.

Do not set this indicator for A/P A/R reconciliation accounts.

You have to set the indicator for the following accounts:

• Cash discount clearing accounts 

• Clearing accounts for goods receipt / invoice receipt

The indicator is usually set for the following balance sheet accounts:

• Accounts without open item management in which no foreign currencies are managed

You manage a clearing account for goods received and invoices received. This account is posted to manually. You post the incoming invoices in an invoice currency and the goods received in all cases in the local currency.

Foreign currency Local currency

Invoice receipt 1000 USD 1580 DEM

Goods receipt 1580 DEM

If the indicator is set, the two line items are cleared.

If the indicator is not set, the system also posts any exchange rate difference as well when clearing. The system then determines the DEM amount necessary to clear the 1000 USD amount. If the exchange rate is 1.60 for example, the system makes a posting of 20 DEM for the exchange rate difference to clear the two line items.

Defining the Tax Category  

Use

In tax accounts, you can specify the type of tax on sales/purchases (input or output tax) that can be posted to the account.

In rare cases, it is useful to assign a certain tax code to an account. You enter the tax code in the master record in this case. Only this tax code can be used when posting to this account. If a G/L account is not tax relevant, you may make no specification in this field. For more information on sales tax and other taxes in your system, see the documentation FI General Topics. 

Defining "Posting Without Tax Allowed"  

Use

If you select this indicator, no tax code needs to be entered when posting to this account. If a tax code is entered, it is checked according to the tax category for this account.

You use this indicator if taxable and non-taxable postings are to be entered to an account at the same time. In such a case, you normally set up your own tax code to allow for non-taxable transactions. However, this is not possible - for example - for tax entry with jurisdiction code, since no jurisdiction code can be specified for customers abroad. You would then allow postings without tax codes for the corresponding expense or revenue accounts.

This indicator is not needed for invoice verification postings, since the account assignments are generally derived from the purchase order. The indicator is therefore not checked by the system for these postings.

For items with no tax code, no tax information is created, and they are not contained in the tax report lists.

Define "Reconciliation Account for Account Type"  

Use

You use this field to indicate G/L accounts as being reconciliation accounts. For each subledger account , you must keep at least one reconciliation account in the general ledger. When you post to an account in the subledger, the system automatically posts to the corresponding reconciliation account. 

The "Receivables from goods and services" account is an example of a reconciliation account for customers. Enter Customer in the Reconciliation account for account type field. Enter a Vendor in this field for a vendor reconciliation account. 

Using the reconciliation account procedure, it is possible to create a balance sheet and a profit and loss statement at any time, since the amounts posted to subledger accounts are also posted automatically in the general ledger. 

During regular reconciliation, you check whether the balance of the reconciliation account matches the balance of the corresponding subledger account. 

You define reconciliation accounts by specifying in the G/L account master record the account type (such as fixed assets, vendor or customer) for which the account is to be used. In this way, the account can only be assigned to accounts in the corresponding subledger. You set the assignment of the subledger account to a reconciliation account in the master record of the subledger account. You cannot post to reconciliation accounts manually . 

You have created a reconciliation account "Receivables" for accounts receivable. You must specify the account number of the reconciliation account in the master records of the customer accounts. The system checks whether the named reconciliation account is permitted for the account type "customer".

More information on the reconciliation account can be found in the FI Accounts Receivable and Payable Accounting documentation in the sections on customer master records and vendor master records . 

Reconciliation operations are described in FI Closing and Reporting.

Defining "Open Item Management"  

Use

If you set the "Open item management" indicator in the master record for an account, the line items in this account is marked as open or cleared.

The balance of an account with open item management is equal to the balance of the open items. General ledger accounts are kept with open item management if you need to check whether there is an offsetting posting for a given business transaction. You should use open item management for bank clearing accounts, clearing accounts for goods receipt/invoice receipt, and salary clearing accounts. Bank accounts, however, do not use open item management.

If you subsequently define open item management for a G/L account, this entry only applies to the items which are posted afterwards. At the date of the change, the account must display a zero balance.

Also, when canceling this indicator, the balance must be zero. You therefore have to clear the remaining open items before making the change in the master record.

Defining "Line Item Display"  

Use

If you set the "Line item display" indicator in the master record for an account, all line items that have been posted to this account are displayed if they have not been archived.

You use line item display to display the document line items from the account. For line item display, the system lists all the line items for an account.

For accounts with line item display, the system uses special indices to define the link between the account and the document. For accounts with many transactions, a corresponding number of indices must be defined and read for line item display. This means that when posting items to such accounts and displaying line items, additional storage space and system time are required. Therefore, you should not use line item display for the following accounts:

• Reconciliation accounts (detailed information is contained in the subledger)

• Sales revenue accounts (detailed information in the Sales and Distribution application module)

• Material accounts (detailed information in the "Materials Management" application module)

• Tax accounts (detailed information is not needed since tax data is contained and checked in the document).

Defining the Field Status Group  

Use

You use this field to define which fields are displayed when you post accounting transactions to a G/L account. A field may have one of the following statuses:

• hidden (suppressed)

• Entry required (required field)

• Ready for input (optional field)

For additional information, see Field Status Definition.

Automatic Postings  

Use

When posting documents, the system automatically adds line items to manually entered items as needed. For example, the tax amount, the cash discount amount, and profits or losses from foreign currency translations (exchange rate differences) can all be calculated and posted automatically by the system. You can decide that accounts to which these automatic postings are made can only be posted to automatically. This will prevent any manual postings to such an account. A definition like this would be useful for tax accounts, if, for example, you had no subsequent tax debit to post. 

Creating G/L Accounts with Reference  

Use

You can create G/L accounts by using a G/L account master records as a reference. You can copy the G/L account master records from this reference company code and edit the data in your target company code before creating the master records.

When editing the copied G/L account master records, you can easily change the account numbers and names. To make additional changes to the G/L account master records, you can use the functions available for collective and individual processing.

Collective Processing of G/L Account Master Records  

Use

You can edit the master records of multiple G/L accounts in one step.

You should use this function is you want to make systematic changes to multiple G/L account master records, such as changing the P&L statement account type of multiple P&L accounts.

With collective processing, you can change the master records of existing G/L accounts. You cannot create G/L accounts.

Collective processing (also known as mass processing) contains various functions with which you can change G/L account master records. You can find documentation in the SAP Library under CA - Cross-Application Components  General Application Functions (CA-GTF)  CA Mass Maintenance  Mass Maintenance. 

Editing G/L Account Master Records Individually  

Use

You can edit the master record of a single G/L account.

The master records of G/L accounts consist of a chart of accounts section and a company code specific section. You can edit the master record of a G/L account centrally for both areas or for each area separately. For more information, see Functions for Editing G/L Account Master Records.

Displaying Changes  

Use

The system logs all changes to G/L master records. For each changed field, it stores the time of change, the user's name, and the current and previous field contents. 

You can display the changes to: 

• A certain field 

• A master record 

• All accounts for various master records

Blocking a G/L Account Master Record  

Use

You can block a G/L account in the chart of accounts area and in the company code-specific area. 

• In the chart of accounts area, you block

o A master record for creating in the company code 

o A G/L account for posting 

o A G/L account for planning

• In the company code, you can only block a G/L account for posting.

Search Function: G/L Account Master Records  

Use 

The search function allows you to search for the number of a G/L account. The system saves certain fields of the G/L master record in a match code. You can then search for the G/L account using the fields contained in the match code.

If you want to search for a number, you place the cursor on the field Account number. The Possible entries pushbutton (F4), provides an overview of the match codes available:

Match codes for G/L accounts

Match code searches for G/L accounts for

=K. Key words

=N. G/L account number in the company code

=S. G/L account name

=C. G/L account number in chart of accounts

The following figure shows the objects which are needed for a match code.

The match code object specifies the database tables and, based on this, all the fields that are required for the match code IDs. From the large number of fields available, only the desired ones are selected for the match code IDs.

The match code ID specifies the fields that are used for a match code and how these fields are stored and output for the match code. It is defined in the Data Dictionary.

The match code consists of a series of master record fields that are entered in the system for each G/L account master record. You can search for the master record using these fields. In other words, the match code is an extract from the master records used for searching.

The standard system contains match code IDs for G/L account master data and for sample accounts. You should check whether you can use these. Create your own match codes if necessary.

For further information, see the topic on Search functions in the General Ledger Accounting Implementation Guide and in the SAP Basis documentation.

Displaying Line Items from the G/L Account Balance Display  

Use

For accounts with line item display, you can display the line items, which compose the account balance, directly from the account balance display.

Changing the Currency  

Use

In the G/L account balance display, you can change the currency for the displayed balances.

Displaying Business Area Balances  

Use

The following options are available for displaying a G/L account balance for a specific business area:

• In the initial screen for the balance display, you can enter a business area. In this case, only the balances of this business area are displayed. 

• If you do not specify a business area, the total account balance is displayed. You can go to the balance display for a specific business area from the display of the total balance.

Displaying Account Line Items  

Use

On the initial screen of the line item display, you can use selection criteria to restrict the number of items displayed. You can also specify on this screen exactly how the line items are to be displayed.

You cannot enter selection criteria for special fields.

Displaying the Document for a Line Item  

Use

You can display all the account assignments for a line item. 

Displaying Account Master Data  

Use

From the line item list, you can also display the account master data. This applies for the following master data: 

• G/L Account Master Data 

• Customer Master Data 

• Vendor Master Data 

 Displaying List Levels  

Use

When the system searches for, or creates totals for line items, it creates list levels. List levels are levels or groups used to display line items. 

You can display an overview of these list levels and select a previous list level. The system then displays the line items in the list level that you selected.

Posting (FI)  

Purpose

Using this standard accounting function, you can enter business transactions in the general ledger and subledgers. In doing so, you create documents and save the data to the database.

Posting Key  

Use

When you enter a posting, enter a posting key for each item. This key determines how the item is posted. Posting keys are defined at client level and therefore apply to all company codes. The posting key determines:

• The data you can enter in the line item 

• How data you post is processed 

• How the system updates the data you enter

Posting keys are differentiated by customer, vendor and G/L accounts. Apart from the General Ledger Accounting (FI-GL) and Accounts Receivable and Payable (FI-AR/AP) components, there are also posting keys for asset and material accounts.

The following figure illustrates the posting key:

SAP delivers predefined posting keys with the standard system. The following table lists some of the posting keys in the standard system.

Posting keys in the standard system

Posting Key Description

40 G/L account debit posting

50 G/L account credit posting

01 Customer invoice

11 Customer credit memo

21 Vendor credit memo

25 Vendor payment

31 Vendor invoice

Screen Layout Using the Posting Key  

Use

The posting key determines what information is required for particular business transactions.

Linking Field Status Definitions  

Use

When you enter a business transaction, the system links the field status definitions of the specified account and the posting key. In this case the fields of a group assume the status with the higher priority.

Posting with a Sample Document  

Use

When you are entering data, you can save time by using a sample document, that is, a document you have previously posted.

 Cross-Company Code Transactions  

Use

Several company codes are involved in a cross-company code transaction. In a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes.

Individual documents are linked by a common cross-company code number. The system generates line items automatically (receivables and payables arising between company codes) in order to balance the debits and credits in each document.

You may use only one company code for offsetting entries. That is to say, regardless of the number of company codes involved, you must make one of the following entries:

• Only one company code on the debit side and the rest on the credit side.

• Only one company code on the credit side and the rest on the debit side.

Example from the G/L View:

This supports for example, central procurement or central payment transactions. In central procurement, one company code makes purchases for several others, while in central payment transactions, one company code pays for the others.

In central purchasing, the invoice item is entered in one company code, and offsetting entries are made in different company codes. The system generates a separate document for each company code. These documents are marked as related by a shared transaction number.

Example from the Vendor View:

A vendor delivers equipment to one company code and other equipment to a second company code, but sends only one invoice for all the equipment to the first company code. You enter part of the expense and post the invoice to the vendor account in the first company code. When entering the invoice, you have to post part of the costs in the second company code. Before you post the cross-company code transaction, the system generates line items automatically (receivables and payables arising between company codes). If you enter a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes. Although the document numbers are different, documents in both company codes have the same number for the cross-company code transaction, the same posting date, the same document date, and the same document type.

Example from the Customer View:

A customer buys a product from one company code and installation and service from another company code, but only receives one invoice for the product and installation from the first company code. The first company code sends and posts the invoice, while the second company code withdraws part of the revenue from the first company code.

Postings for clearing between the company codes involved are made automatically. These clearing entries identify the receivables or payables that arise between the company codes. Each company code-specific document states a zero balance.

Clearing Accounts for Cross-Company Code Transactions  

Use

You create clearing accounts to display receivables and payables between individual company codes. You define which clearing accounts to use in the system settings. There are two ways to do this:

• You specify clearing accounts for each possible combination of company codes.

• You use one company code for clearing. This company code is always entered first during document entry. In this case, you enter the clearing accounts for each combination of this company code with the other company codes.

Entering G/L Account Line Items (General Ledger)  

Use

You enter G/L account line items after you have entered the document header. The bottom line of each screen contains the following fields for the line items:

• Pstky (Posting key)

• Account

• Sp. G/L (Special G/L indicator; used when posting special G/L transactions such as down payments or bills of exchange)

• New co.code (new company code for cross-company code transactions)

You can suppress fields by selecting Environment  User parameters  Editing options in the General Ledger menu. For more information, see Editing Options

Posting Documents in General Ledger Accounting  

Use

If the balance of debits and credits in a document is zero, you can post the document. When you post the document, the system saves it and updates the G/L account balances. 

 Editing Line Items - Enjoy Transactions  

Use

You can enter line items in the tabular input area of the single screen transaction. The edition functions simplify working with line items.

Clearing  

Purpose

The SAP System offers the following procedures for accounts with open item management:

• Posting with clearing 

• Manual account clearing 

Clearing Functions in the General Ledger  

Use

You can use the following functions for clearing open items manually:

Posting transaction Example 

Business transaction Choose

Incoming payment Credit memo for a check deposited at the bank Document entry  Incoming payment

Outgoing payment Debit memo for an issued check Document entry Outgoing payment

Post with clearing Clearing the GR/IR clearing account Document entry  Post with clearing

Outgoing payment Debit memo for an issued check Document entry Outgoing payment

The following information is based on the Post with clearing function. For entering posting data, there are different screens for different clearing functions. Processing open items is however the same for all clearing functions.

Clearing Functions in Accounts Payable  

Use

You can use the following functions for clearing open items manually:

Clearing Functions in Accounts Payable

Posting transaction Example 

Business transaction

Choose

Outgoing payment Debit memo Document entry Outgoing payment  Post

Outgoing payment with printed form Immediate payment by check Document entry Outgoing payment  Post + print forms

Internal transfer posting Invoice cleared due to a product defect Document entry  Others  Internal transfer posting  With clearing

Incoming payment Refund from your vendor, for example, annual quantity discount Document entry  Others  Incoming payment 

The SAP System also supports the automatic entry of bank postings for outgoing payments by importing bank statement data using the Electronic Bank Statement function. 

For more information, see the FI Treasury and FI Electronic Bank Statement documentation.

Selecting and activating down payment requests during clearing triggers the system to post a corresponding down payment. This saves you from having to enter the down payment manually, as well as from having to switch between two transactions to process incoming payments.

You can also pay a down payment request with a form (check) online. 

Down payment requests are reset in the same manner as other documents by using the reversal function.

Clearing Functions in Accounts Receivable  

Use

The following functions are available for manually clearing items:

Posting transaction Example 

Business transaction

Choose

Incoming payment Customer payment Document entry Incoming

payment or Payment fast entry

Outgoing payment Debit memo procedure

Cash payments Document entry Other  Outgoing 

payment  Post

Outgoing payment with printed form Immediate payment by check Document entry Other Outgoing 

payment  Post + print forms

Internal transfer posting Invoice posted as credit memo

due to a product defect Document entry  Others Internal transfer posting  With clearing

Online check printing Automatically generated check

damaged during print Document  More

functions  Print payment forms

The system also provides the following additional functions for automatically posting incoming/outgoing payments and clearing open items.

Clearing Transactions  

Use

The following overview lists the clearing transactions in the standard system and the functions used to post them.

To clear items against an incoming payment, you would use the Incoming payment clearing transaction. If you make a payment to a vendor, you would use the Outgoing payment clearing transaction.

There are two separate functions specially designed for each of these clearing transactions: Incoming payment and outgoing payment. Special screens are used for these functions. This makes processing open items much simpler. The fast entry function enables you to enter payment lots quickly. This function uses the posting key defined for the incoming payment clearing transaction. 

Choosing the Selection Procedure  

Use

In the batch input procedure (for example, for account statement postprocessing), you can determine how open items are selected. You can choose from two procedures:

• "Or" selection: All items that fulfill at least one of the selection criteria specified are selected. This is the standard procedure. 

• "And" selection: Only those items that fulfill all of the selection criteria are selected.

Searching for Open Items  

Use

After you have entered an account with open items, you can search for specific open items to be cleared.

On the screen for selecting open items, you can search for specific open items to be cleared using the following additional selection fields:

• Gross amount

• Document number

• Posting date

• Other fields depending on the system configuration

Fast Assignment of Open Items (R/3)  

Use

The function for the fast assignment of open items allows you to assign a small quantity of open items quickly and intuitively. You can also use this function to request missing information about assignments from your business partners via the Internet. 

Processing Open Items  

Use

Processing open items involves choosing and then activating the open items. Processing is the last step before posting a clearing document.

Displaying Open Items  

Use

On the screen for processing open items, you can display an entire open item.

Editing the Open Item Display  

Use

After you have entered the document header and line item and chosen the open items, the screen for processing open items appears. You can edit the open item display. 

You can choose between various functions for searching for, sorting, and changing the specifications. 

Average Due Date for Cash Discount  

Use

You can determine a common due date for cash discount according to cash discount terms 1 (S1) and 2 (S2) for a group of open items. Both due dates (S1 and S2) are displayed in open item processing.

Reference Date for Cash Discount and Days in Arrears  

Use

To determine the due date for cash discount or days in arrears, you can use the following specifications:

• Document date of payment document (standard) 

• Value date of payment item

The system accesses the first line item for incoming and outgoing payments.

If the value date cannot be determined via the payment item, the document date is used to calculate the due date for cash discount.

Posting Partial Payments  

Use

A partial payment is a payment that is posted to an account without any open items being cleared. You assign this partial payment to an open item. When you post the partial payment, the system marks the document number of the original open item in the line item for the partial payment. The original open item and the partial payment remain open.

Posting Residual Items  

Use

A residual item results when a payment is made for less than the actual amount outstanding. You clear the original open item, and the system posts a new open item. This new open item is for the same amount as the original open item minus the amount paid.

Searching for Open Items  

Use

If the account has several open items, you can search for specific open items to clear. This avoids having to scroll through several screens of open items.

Processing Open Items According to the Payment Advice Note  

Use

For every payment advice note item, the system selects those items that fulfill the selection criteria. If a payment advice note item contains a document number, this has priority over other selection criteria. The number of items selected in this way is increased by all the items with an invoice reference, (invoice-related credit memos, partial payments), that belong to a previously selected invoice.

Payment Differences  

Use

Depending on the amount of the receivables, you define how payment differences should be treated.

Reason Codes  

Use

To use the clearing document to find out why a difference existed, you can assign reason codes to the line items. Reason codes are indicated by keys that you define in Customizing.

You can assign reason codes for the following:

• Partial payments made for open items. 

• Residual items created for an open item. Here you can assign one or more reason codes. In this case, you divide the difference amount into a corresponding number of partial amounts. 

• Differences posted on account without reference to an open item. 

• For each line item you enter in the clearing procedure, if the reason code field for the account is ready for input.

Differences Within Tolerance Limits  

Use

Differences within tolerance limits are posted automatically. The system can either adjust the cash discount amount or post the difference to a separate gain or loss account. When you define tolerance limits, you also specify how the system should post the differences.

You can define:

• The maximum difference amount for which the system should adjust the cash discount. The difference is added to or subtracted from the cash discount.

• The maximum amounts or percentages for which the system should automatically post any difference to a separate gain or loss account if the cash discount cannot be adjusted.

You define tolerance limits separately for your employees and business partners.

The system checks both limits when clearing open items. The lowest limit always has priority for the clearing transaction.

For one of your customers you set a maximum amount of two USD for adjusting the cash discount amount when a payment difference occurs. For the accounting clerk that processes this customer account however, you set a maximum amount of one USD. If differences occur when this clerk clears items from this customer account, the system can adjust the cash discount amount only up to a maximum of one USD.

Settings that you make for tolerance limits are valid in the currency of your company code (local currency). The currency is always displayed when you define the limits.

Differences Exceeding Tolerance Limits  

Use

Differences exceeding the tolerance limits set for clearing them automatically may still occur during a payment transaction. This may be the case for example, if a customer has told you in a payment advice note which items a payment relates to. The amount paid however, does not correspond to the amount of the receivables. 

When you process open items, you can have the following options for dealing with differences that exceed the tolerance limits:

• You can treat the payment as a partial payment. The system does not clear the original receivable. It posts the payment with an invoice reference, and enters the invoice number in the Invoice reference field in the payment items. To determine the due date of the payment, the system calculates the net due date for the invoice. This date is then entered in the Baseline date field of the payment. The payment is then included in the dunning program and in cash management at this date.

• You can use the payment to clear the original receivables and post the remaining amount to the customer account as a residual item. The payment amount is noted in the line item for the original receivable.

• You can clear the original receivables and post the difference to an expense account.

Automatic Posting for Clearing Transactions  

Use

During clearing, the system can automatically post:

• Cash discounts paid or received 

• Gains or losses from under/overpayments 

• Input/output tax and withholding tax 

• Bank charges 

• Gains or losses from exchange rate differences 

• Entries to clear the account for cash discount clearing in the net method of posting

Automatic Clearing  

Use

The clearing program also uses the clearing transactions provided for manual account maintenance. For example, automatic posting of exchange rate differences, or automatic generation of transfer postings if items from different business areas or trading partners are involved in clearing. Furthermore, the program can clear documents that were posted using the net method and documents that contain parallel currencies.

When you create clearing groups, the business area and trading partner are no longer automatically used as fixed grouping criteria. This enables you, for example, to carry out automatic cross-business area clearing. 

You must also specify a clearing date.

 Bank Subaccounts  

Use

Using bank subaccounts, you can reconcile the balance of the account at your bank with the balance of your corresponding G/L account. 

The subaccounts ensure that all incoming and outgoing payments are only posted to the G/L bank account when the money is actually debited from/credited to your bank account. Incoming and outgoing payments are posted to the main G/L bank account once you receive and enter the account statement from your bank.

Clearing Open Items in Foreign Currency  

Use

You can clear open items in any currency.

The amount of all the selected open items will automatically be translated into the currency in which clearing is to take place. The translation is executed as follows:

Item currency  Local currency  Clearing currency.

You are therefore not required to make additional entries in the exchange rate table for cross-currency clearing.

When clearing, you can only display the open items in either the clearing currency or the local currency. 

The amounts originally posted for items that were posted in a third currency are not displayed in the overview.

You no longer need to make a posting to an interim account (currency exchange account) for payments in a foreign currency that does not correspond to the currency of the paid items.

Clearing in a Third Currency

The local currency of a company code is DEM. An invoice was issued on 4/1/94 for 1000 SFR, and on 4/15/94 a payment for 685 USD was received. If the invoice had been created in USD, the amount due would be $687.14. In the local currency, there is a difference of 8.65 DEM. This difference is divided as follows: Unauthorized deductions of 3.66 DEM, and SFR exchange rate fluctuation 4.99 DEM.

If you want to clear cross-currency open items, it may be worth viewing the item currency keys in the overview. In 

Cross-Company Code Transactions  

Use

Several company codes are involved in a cross-company code transaction. In a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes.

Individual documents are linked by a common cross-company code number. The system generates line items automatically (receivables and payables arising between company codes) in order to balance the debits and credits in each document.

You may use only one company code for offsetting entries. That is to say, regardless of the number of company codes involved, you must make one of the following entries:

• Only one company code on the debit side and the rest on the credit side.

• Only one company code on the credit side and the rest on the debit side.

Example from the G/L View:

This supports for example, central procurement or central payment transactions. In central procurement, one company code makes purchases for several others, while in central payment transactions, one company code pays for the others.

In central purchasing, the invoice item is entered in one company code, and offsetting entries are made in different company codes. The system generates a separate document for each company code. These documents are marked as related by a shared transaction number.

Example from the Vendor View:

A vendor delivers equipment to one company code and other equipment to a second company code, but sends only one invoice for all the equipment to the first company code. You enter part of the expense and post the invoice to the vendor account in the first company code. When entering the invoice, you have to post part of the costs in the second company code. Before you post the cross-company code transaction, the system generates line items automatically (receivables and payables arising between company codes). If you enter a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes. Although the document numbers are different, documents in both company codes have the same number for the cross-company code transaction, the same posting date, the same document date, and the same document type.

Example from the Customer View:

A customer buys a product from one company code and installation and service from another company code, but only receives one invoice for the product and installation from the first company code. The first company code sends and posts the invoice, while the second company code withdraws part of the revenue from the first company code.

Postings for clearing between the company codes involved are made automatically. These clearing entries identify the receivables or payables that arise between the company codes. Each company code-specific document states a zero balance.

Clearing Accounts  

Use

This function differs from posting with a clearing transaction or posting with a payment in the following ways:

You do not need to enter a document header

• You can only clear open items from one account

Resetting Clearing  

Use

You can reset clearing transactions for individual documents. When clearing is reset, the clearing data is removed from the line items (and the reversal data, where it existed, is removed from the document header). The document changes are logged and can be displayed in the change documents.

REVERSAL

Negative Postings  

Use

Reverse and adjustment postings can also be marked as negative postings. Negative postings are used to reduce the transaction figures in G/L, customer, and vendor accounts. This allows you to give the transaction figures (following the reversal) the status they would have had without posting the reversed document and its reversal document. This type of reversal is called a negative posting.

Manual Accruals  

Purpose

The Manual Accruals component allows you to calculate and post accruals in General Ledger Accounting automatically. 

You enter the date once for a business transaction that you have to enter. On the basis of this data, the system calculates the amounts to be accrued. You can also simulate these amounts. In each period, you can start an accrual run, meaning that all accruals are posted for the various business transactions.

The functions in Manual Accruals support the use of parallel valuation methods. This means that you can also calculate and post accruals for a number of accounting principles.

The Manual Accruals component is based on the Accrual Engine tool. The transactions to be accrued are managed in Manual Accruals. The processes for calculating and posting accruals, on the other hand, are managed in the Accrual Engine. For more details, see Manual Accruals and the Accrual Engine.

Information System  

Purpose

With the G/L Account Information System, based on Drilldown Reporting, you have a dialog-oriented information system available. It is able to evaluate the dataset based on all characteristics contained in the data description.

G/L account transaction figures and the financial statement versions serve as the primary data source for the General Ledger Information System.

 Creating Key Figure Reports  

Use

In the G/L Account Information System, you can create two types of key figure reports:

• Reports with key figures that only calculate certain financial statement items without constants such as the debt/equity ratio from the financial statement items equity and liabilities. 

• Reports with key figures that are calculated from certain financial statement items with constants such as the key figure revenue per employee from the financial statement item sales revenue and the constant number of employees.

Financial Statement Analysis  

Use

You can carry out financial statement analyses for the following time periods:

• Year comparisons 

• Half-year comparisons 

• Quarterly comparisons 

• Monthly comparisons

You can use both actual and plan data as the basis for these reports, that is, you can execute actual / actual comparisons as well as actual / plan comparisons.

The SAP System includes sample reports for financial statement analysis. You can use these reports as templates for your own reports.

 

The SAP standard reports have the naming convention 0SAPBLNCE-01 to 0SAPBLNCE-NN. For your own reports, use a technical name that does not lie within this name range.

Creating a Report for Financial Statement Analysis  

Use

In a report for financial statement analysis, you can compare the development of the financial statement values. You can make a comparison for the following time periods:

• Yearly comparisons 

• Semi-annual comparisons 

• Quarterly comparisons 

• Monthly comparisons

In a report, you can valuate both actual and plan data. That is, you can run actual/actual comparisons as well as actual/plan comparisons.

Creating Key Figure Reports  

Use

In the G/L Account Information System, you can create two types of key figure reports:

• Reports with key figures that only calculate certain financial statement items without constants such as the debt/equity ratio from the financial statement items equity and liabilities. 

• Reports with key figures that are calculated from certain financial statement items with constants such as the key figure revenue per employee from the financial statement item sales revenue and the constant number of employees.

Closing and Reporting (FI)  

Purpose

Closing operations recur periodically and can be subdivided as follows in Financial Accounting:

• Day-End Closing 

• Month-End Closing 

• Year-End Closing

You can use the closing operations component to support the preparation and carrying out of activities required for closing. For this purpose, the system provides various standard reports that you can use to generate evaluations and analyses directly from the posted account balance. The system supports the following closing operations:

• Periodic accrual and deferral of expenditure and revenue 

• Creating the financial statements 

• Documenting the posting data

Day-End Closing  

Use

You can use the following valuations for day-end closing:

• Correspondence with business partners 

• Document journal

To monitor the updating of data in the database, you should generate a list of all the terminated updates each day. For more information, see Documenting Posting Data.

Month-End Closing  

Use

You can carry out the following activities as part of month-end closing:

• Open and close posting periods

You close one or more posting periods in the past for posting, and permit posting to be made to one or more current or future posting periods. See Fiscal Year

• Create external reports 

You can use report programs to create the following reports, for example:

o Financial statements 

o Advance return for tax on sales and purchases 

o Report required by German Foreign Trade Regulations

• Document the posting data

This includes the following reports:

o Compact journal 

o Balance audit trail 

o Accounting reconciliation 

o Account balances 

o Open item list

• Carry out internal evaluations, such as extracts for downstream applications 

• Reorganize and archive documents

Periodically, you should archive documents no longer needed in the online system. How often you do this (for example, monthly or less frequently) will depend on the volume of data in your system. For more information, see Archiving FI Documents (FI-GL, FI-AR, FI-AP)

 Year-End Closing  

Year-end closing is split into two phases:

• At the beginning of the new fiscal year, you open the new posting periods and carry forward the balances from the previous year.

• You then prepare and create the financial statements, document the business transactions using the balance audit trail, and archive those documents you no longer need online.

Special Financial Statement Items  

In a financial statement version there are certain items that are of special significance in the financial statement program and the general ledger information system. 

If you are creating a new version, the system automatically creates a separate item for the following special items in the version:

• Assets

• Liabilities

• Net result: Profit

The balance calculated for the financial statement result is displayed here if it is positive.

• Net result: Loss

The balance calculated for the financial statement result is displayed here if it is negative.

• P&L result

Here the system displays the balance of all accounts that can be assigned to an item but which are not found under assets or liabilities. 

• Not assigned

Here the system displays all accounts which cannot be assigned to a particular item.

The balance sheet net result and the P&L statement result are calculated by the program that creates the financial statements. This program also lists, under the item "Not assigned", those accounts that could not be assigned to an item in the financial statement version. 

The financial statement profit or loss is determined from only those accounts assigned to assets or liabilities. The accounts that cannot be assigned are not used to determine the profit or loss. The balance of all the other accounts produces the P&L statement result.

The program that creates the financial statement does not carry out any postings. It is restricted to calculating the balance sheet and P&L statement profit or loss and displaying this in the financial statements.

Defining Financial Statement Versions  

Use

In a financial statement version, you define the format for displaying your accounts. You assign your accounts hierarchically in a tree structure. 

Financial Statement Versions with Group Account Numbers  

Use

You can define a financial statement version by assigning the group account numbers to the items. This gives you the option of creating group financial statements.

The group account number allows you to group together all the accounts from different charts of accounts which are to be displayed under a certain financial statement item. Using the group account number therefore assigns a group of accounts to the same item. 

Financial Statement Versions with Functional Areas  

Use

You can define a financial statement version by assigning functional areas to the P&L items. 

This gives you the option of creating financial statements in accordance with cost of sales accounting.

You cannot use a financial statement version with functional areas in the following cases:

o As a basis for planning in General Ledger Accounting 

o As a basis for creating financial statements using report RFBILA00.

Functions for Editing Financial Statement Versions  

Use

You edit financial statement versions in a tree structure. Various functions are available in the tree structure.

Changing a Financial Statement Version  

Use

You can change all entries except for the key of the financial statement version.

You can only change the explicitly entered chart of accounts to the use of a group chart of accounts if the following condition is met: No accounts may be assigned to the financial statement items. 

Deleting a Financial Statement Version  

Use

Financial statement versions consist of general specifications and the items you have defined. 

If you want to delete a financial statement version, you can:

• Delete the entire structure with all its items in a single step

• Delete some of the items from the structure

Creating Financial Statement Forms Automatically  

Use

It is possible to generate a form from the financial statement version and print the financial statements on a SAPscript form. To do this, you must generate a target form from the source forms provided with the standard system. You can modify this target form according to your requirements. Once the modified form is activated, you can use it to print the financial statements.

Balance Confirmation  

You can check the accuracy of your accounts payable to vendors and your accounts receivable from customers using balance confirmations. These enable you to detect and correct any discrepancies which may exist between your records and those of your business partners and to make any necessary individual value adjustments.

In the R/3 System, there are several different methods of confirming balances, depending on the purpose of the confirmation. These are:

• Balance confirmation

Here you notify the business partner of the individual amounts for which you require confirmation. You ask for a reply, irrespective of whether the amounts correspond or not. 

• Balance notification

Here, as above, you notify the business partner of the individual amounts to be confirmed. However, the partner sends a reply only if he or she does not agree with the balance stated.

• Balance request

Here, you ask the customer or vendor to notify you of the amount on your account according to his records. 

GR/IR Clearing Account  

Use

Before creating the financial statements, you need to analyze the GR/IR clearing account so that the transactions posted to it are properly displayed. 

The program used for this analysis determines an item balance for each reconciliation account and each assignment number. If the account has a credit balance, goods have been received but not invoiced; if the account has a debit balance, goods have been invoiced but not yet received. The program places any necessary adjustment postings in a batch input session. These postings are made separately per company code, GR/IR clearing account, reconciliation account, and business area. They are then reversed on the day you specify in the program run. 

You have received goods from one of your vendors. The vendor has invoiced only part of the delivery. 

In this example, you would make the following postings:

1. You post $2000 of goods received to the inventory account. The system automatically posts the transaction to the GR/IR clearing account. 

2. You have been invoiced $1000 for part of the delivery. You post this amount to the vendor account and to the GR/IR clearing account.

In this example, the program would create the following postings:

1. On the balance sheet key date, transfer postings are required to identify the portion of goods delivered but not yet invoiced. To adjust the GR/IR clearing account, the program used in analyzing the GR/IR clearing account posts $1000 to the relevant adjustment account. The offsetting entry is posted to the account used for presenting goods delivered but not invoiced (target account).

2. These postings are reversed after the financial statements have been created. 

Posting Acquisition Tax  

Use

You have to post acquisition tax for deliveries which originated in another EU country. You usually do this when you post the invoice. However, if you have posted a goods receipt without an invoice receipt, you can post the acquisition tax based on the goods receipt. This is done using the program which analyzes the GR/IR clearing account.

Foreign Currency Valuation  

Use

In order to create your financial statements, you have to carry out a foreign currency valuation. This valuation covers the following accounts and items: 

• Foreign currency balance sheet accounts, that is, the G/L accounts that you run in foreign currency. 

The balances of the G/L accounts in foreign currency are valuated. 

• Open items posted in foreign currency.

The line items in foreign currency are valuated. 

You have the following options for the foreign currency valuation:

• You can carry out the valuation in local currency, (company code currency), or a parallel currency (for example, group currency). 

• You can also use different valuation methods (for example, lowest value principle). 

• In addition to the foreign currency valuation, you can also carry out a currency translation in accordance with FASB 52 (US GAAP). You can thereby translate your account balances from local currency into group currency, for example. 

Transferring and Sorting Receivables and Payables  

Use

Before creating your financial statements, you have to order your receivables and payables according to their remaining term so that they can be displayed correctly. You need to enter adjustment postings to do this. 

Adjustment postings are necessary in the following circumstances:

• If you have customer accounts that are in credit. You cannot display this balance as a receivable; it must be displayed as a payable. 

• If you have vendor accounts which are in debit. You cannot display this balance as a payable; it must be displayed as a receivable. 

• If you have changed the reconciliation account for a customer or vendor, and the payables and receivables posted to the old reconciliation account are to be assigned to the new account before they are displayed in the financial statements. 

• In certain countries (France, for example), investments must be displayed separately.

Planning  

Purpose

The planning function in the General Ledger enables you to enter plan data based on your financial statement versions. You can use a budgeted financial statement to compare plan data with actual data.

Entering Plan Data  

Use

You can enter plan data in the following ways:

• By entering plan totals and distributing them to the individual plan periods by means of a distribution key 

• By entering plan data for the individual plan periods and having the system total these amounts 

• By entering plan totals and plan periods

Creating Budgeted Financial Statements  

Use

You can use report program RFBILA00 to create a budgeted financial statement in which your plan data is compared with the actual data.

You can restrict the report to a certain period if, for example, you report on a quarterly basis.

Creating the Financial Statements  

Use

You create financial statements as part of the year-end closing in accordance with country-specific legal requirements in order to report assets, liabilities, accruals and deferrals, and revenues and expenses. 

Business Area (FI)  

Purpose

Business areas are primarily used to facilitate external segment reporting across company codes, covering the company's main areas of operation (product lines, branches).

You can assign all balance sheet items, such as fixed assets, receivables, payables, and material stock, as well as the entire P&L statement directly to business areas. You can only assign banks, equity, and taxes manually to business areas indirectly. For this reason, it is not possible to create the legally-required financial statements and tax reports at business area level. Financial statements at business area level are therefore only suitable for internal reporting.

Customer Master Data  

Purpose

In the SAP System, all business transactions are posted to and managed in accounts. You must create a master record for each account that you require. The master record contains data that controls how business transactions are recorded and processed by the system. It also includes all the information about a customer that you need to be able to conduct business with him. 

Customer  

Use

A customer is represented in the SAP System by means of a master record.

Defining an Account Group  

Use

You must assign each account to an account group. The account group ensures that only the relevant screens and fields are displayed and ready for input for each of the customer’s different partner functions. For example, the address, communication, and bank data fields are omitted for the account group for one-time accounts.

Numbering Master Records  

Use

Each master record has a unique number. You need this number to call up the master record or to post to the customer account.

Defining Screen Variants  

Use

The Accounts Receivable (FI-AR) application component is delivered with predefined screens on which to enter your master data. You can configure these screens by specifying which fields should appear on the screens, and how those fields are to be processed. You do so by specifying the status of the fields. The following statuses exist:

• Hidden field (not visible) 

• Required entry field (the field contains a question mark and an entry has to be made) 

• Optional entry field (you can make an entry)

• Display field (cannot be changed)

the screens for master records of one-time accounts should have a different layout to the screens for all other master records. Fields for address, communication, and bank data are not required in the master record for one-time accounts since you enter this information directly in the document. You should therefore hide these fields for one-time accounts.Example:Some fields are grouped together so that you do not have to make a separate setting for each of them.Fields for interest calculation are grouped together. If you hide this field group, the fields for interest calculation frequency and the last key date are not displayed on the master record screen.

When defining or changing an account group, you specify the status of a field group by simply selecting the required status for the fields or field groups as shown in the illustration below: The layout of screens can be affected by several field status definitions. Usually you define the status of a field based on the account group. You can, however, also define the status of a field based on the activity or company code. 

Defining Reconciliation Accounts  

Use

You must specify a reconciliation account in the master record so that all postings made to a subsidiary ledger are also posted to the general ledger.

Customer Master  

Use

You must create a master record in the system for each account that you require.

Creating a Customer Master Record Centrally  

Use

You wish to create a customer master record for both Financial Accounting (FI-AR) and Sales and Distribution (SD) at the same time.

Creating a Customer Master Record for a Company Code  

Use

You wish to enter a customer master record for accounting (FI-AR) only.

Creating a Customer Master Record Using a Reference  

Use

You wish to create a master record by referring to an existing master record.

Entering Bank Details  

Use

For each customer, you can specify as many banks as you require. You need the bank details of a customer if you intend to use the payment program to collect payment from your customer (for example, if you have automatic debit authorization).

To enter bank details in the customer master record, enter the bank country, the bank key, and the bank account number in the general data area. For control purposes, the system then displays the name of the bank.

The fields Country and Bank key serve to clearly identify a bank in the SAP system. With these keys you can enter further bank data, such as the address.

Normally banks are managed by bank number. This is entered as the bank key. In certain countries, for example, the Netherlands, the account number is used for this function. In this case, you should enter the account number as the bank key. 

Entering Payment Methods  

Use

You enter payment methods in the master record so that the system can process payments automatically.

Entering a Dunning Procedure  

Use

You enter a dunning procedure which the system uses for automatic dunning. This dunning procedure is used for the standard dunning area. You can divide your company into dunning areas, such as wholesale transactions and retail transactions. If you use other dunning areas in your company, you must enter them in a separate entry screen.

Assigning Documents to a Customer  

Use

You can assign to each customer documents that have been scanned into the system, such as business reports, newspaper articles, or graphics.

One-Time Accounts  

Use

For customers whom you only supply once or rarely, you can create a special customer master record, the master record for "one-time accounts". In contrast to other master records, no data specific to a single customer is stored in the one-time master record, since this account is used for more than one customer. The customer-specific entries such as address and bank details are not entered until the document for the transaction is entered into the system.

You invoice a customer who purchased goods from you because his main vendor could not supply them. In this case, you post the invoice to a one-time vendor account instead of creating a separate master record.

Setting Up Head Office and Branch Accounts  

Use

Customers in some industries place orders locally (i.e. via their branches), but pay invoices centrally (from headquarters). You can represent this business relationship with head office and branch accounts. 

Displaying a Customer Master Record  

Use

Both the accounting and sales departments use a customer master record. You can display either the general and company code data (the accounting data) or the entire customer master record (with sales data). Employees in the sales department can display the data about order processing, shipping, and billing for a customer. 

This topic describes how you display a customer master record either centrally or for accounting. You can find further information on the sales functions and data in the Sales and Distribution (SD) documentation.

There are a number of maintenance functions that you can use to maintain the master data. For more information, see Maintenance Functions for Customer Master Data: Overview 

Blocking a Customer Account Centrally  

Use

When you block an account centrally, you can prevent both posting and order processing, if you have installed the Sales and Distribution (SD) application component. 

Blocking a Customer Account for Posting  

Use

You wish to block a customer account so that postings are no longer made to that account.

Blocking a Customer Account for Payments and Dunning Notices  

Use

You wish to block a customer account for payments and dunning notices. To block a customer account for the payment program or for the dunning program, you must change the customer master record. 

Archiving and Deleting a Customer Master Record  

Purpose

You can archive customer master records that you no longer need. When data is archived, it is extracted from the SAP database, deleted, and placed in a file. You can then transfer this file to an archive system. 

For more information on archiving customer master data, see the CA - Application Data Archiving and Reorganization documentation. 

The following section explains how to mark master records and their customer accounts for deletion. The deletion process is described in the FI - Closing and Reporting documentation.

Special Fields in Vendor Master Records  

The following fields in vendor master records have special functions:

• Search Term: Vendor Master Records

• Alternative Payee

• Affiliated Companies: Vendor Master Records

• Clearing Between a Customer and Vendor 

• Group: Vendor Master Records 

• Accounting Clerk: Vendor Master Records

Functions for Maintaining Vendor Master Data  

The following functions are available for processing vendor master records:

• Create

• Change

• Display

• Block/unblock

• Mark for deletion/remove mark

If your company also has the Materials Management (MM) application component, you can create and maintain vendor master records either together or separately as follows:

• Separately for the company code

• Separately for the purchasing area

• Centrally for both the company code and purchasing area at the same time

To enter data in the purchasing area, you need the Materials Management (MM) application component. There are three different ways to process master records since they are often created and maintained by different departments. In some companies, accounting and purchasing personnel maintain the general area together and their own areas separately. In other companies, vendor master records are maintained centrally.

Depending on how your company organizes its vendor information, authorizations will be assigned for creating and maintaining vendor records. This means that not every user may be able to use every function.

See also:

Selecting Screens to Display Vendor Master Data

Additional Functions for Maintaining Vendor Master Data

Creating a Vendor Master Record: Overview  

Before you create a vendor master record, you will have to make and check over some system settings. For more information, see the activities under Preparations for Creating Vendor Master Records in Customizing for Accounts Receivable and Accounts Payable. For more information on configuring the system, see Configuring the System Using the Implementation Guide.

Vendor master records are used by both the Accounting component and the Purchasing component. Before you create a vendor master record in Accounting, you need to make sure that the master record is not already created in Purchasing. You can use the system’s search facilities to do this. See the document Getting Started with the R/3 System for more information about these search facilities. You can also switch on the automatic duplication check to ensure that users do not create the same master record twice. For more information about this system check, see the Change message control for vendor master data activity in Customizing for Accounts Receivable and Accounts Payable. For information about system configuration, see Configuring the System Using the Implementation Guide.

The following topics explain how to create a vendor master record centrally for both Accounting and Purchasing and how to create a master record for just Accounting. Creating a vendor master record centrally involves entering data for both Accounting and Purchasing in one step. This method is possible only if you have purchased and installed the Materials Management (MM) application component. See the Materials Management (MM) documentation for more details about this.

To enter master data for the accounting department only, use the corresponding functions in Accounting.

See also:

Creating a Vendor Master Record Using a Reference

Creating a Vendor Master Record Centrally

Creating a Vendor Master Record for a Company Code

Special Features in Data Entry

Creating Head Office and Branch Accounts

Creating One-Time Accounts 

Creating a Vendor Master Record Using a Reference  

You can create a master record by referencing an existing one, in which case the system copies certain data from the reference master record. However, the system does not transfer all data; which data is transferred depends on several factors:

• The system only transfers data that is not vendor-specific. For example, the address or a block indicator is not transferred from the reference master record.

• The transfer of data depends on the data you have already entered for your vendor. In general, if you have already maintained data, the data is not overwritten with data from the reference record.

o For example, if you have already created the general data, such as the name, address, and phone number, only the company code data is transferred when you enter the company code data. To transfer the company code data only, you must specify the company code of the reference master record. When you create the data for the purchasing department, again only the corresponding data is transferred from the reference master record. 

o If you have not yet created the general data, only the language and the country are transferred from the reference master record.

• You determine which data is transferred by specifying which areas are to be transferred from the reference master record. If you do not specify a purchasing organization for the reference, for example, the purchasing data is not transferred.

When you create a new vendor master record in this way, you can choose whether you want to use the account group of the reference master record. In this case, do not enter an account group for the master record to be created. The system automatically transfers the account group from the reference master record.

You can use a vendor master record from any company code as a reference. The data from the reference is used merely for default values. You should check each screen before saving and, if necessary, add data or change the default data. 

Creating a Vendor Master Record Centrally  

If you have purchased, installed, and configured MM Materials Management, you can create a vendor master record centrally as follows:

1. From the Accounts Payable menu, choose Master records  Maintain centrally  Create. 

The initial screen for creating the vendor appears.

2. If you use external number assignment , enter the vendor's account number. 

If you use internal number assignment , the system assigns a number when you save the vendor master record. Until then, the word "INTERNAL" appears on the screen in place of the account number.

3. Enter a company code and a purchasing department, depending on the data areas you want to maintain. 

You can only enter data in a company code or a purchasing department, if you specify one or the other. Otherwise, you can only enter the general data of the vendor master record.

4. Enter an account group and select ENTER . 

The first screen for entering vendor master data appears.

 

When you create a vendor master record for which the general data has already been created, the first screen for the company code or purchasing department data appears.

5. Enter the vendor data and select ENTER to reach the next entry screen. 

In each screen the system displays, in the upper left-hand corner, which data area you are entering data for. When you enter company code or purchasing data, the company code or the purchasing organization is displayed. If neither of these is displayed, you are in the general area.

6. In the last screen, save your master data by choosing Vendor  Save.

The system displays the initial screen again, with a message confirming that the data is saved. 

Creating a Vendor Master Record for a Company Code  

Create a master record for accounting only as follows:

1. From the Accounts Payable menu, choose Master records  Create. 

The initial screen for creating the vendor appears.

2. If you use external number assignment , enter the vendor's account number. 

If you use internal number assignment , the system assigns a number when you save the master data.

3. Enter the company code and the account group and select ENTER . 

The first screen for entering master data appears.

4. Enter your vendor data and then select ENTER to reach the next entry screen. 

5. Save your master data by choosing Vendor  Save.

The system displays the initial screen again and a message that confirms that the data is saved.

If you have created master records in one company code and require exactly the same master records in another company code, you can distribute the newly created master records to other company codes via the following menu path in the Financial Accounting Configuration screen: Tools  Data distribution  Accounts payable  Send.

For more information on this topic, consult the Implementation Guide. 

Special Features in Data Entry  

When you create a vendor master record, you must enter certain data in special entry screens. This is data you need to enter in exceptional cases only. This data includes:

• Bank data, in cases where there is no bank master data yet

• Dunning procedures

• Texts

• Documents

The system also offers a special selection function for entering payment methods. This function is described below. 

See also:

Entering Bank Details

Entering a Payment Method

Entering a Dunning Procedure

Entering Text

Assigning Documents 

Classifying Vendors 

Displaying a Vendor Master Record  

Both the accounting and purchasing departments can have access to a vendor master record. You can display either the general and company code data (the accounting data) or the entire vendor master record (with purchasing data). Personnel in the purchasing department can display the data about purchasing, invoice verification, and inventory control for a vendor.

This topic describes how you display a vendor master record either centrally or for accounting. You can find further information on the purchasing functions in the MM Materials Management documentation.

Display a Vendor Master Record Centrally

If you have purchased, installed, and configured the MM Materials Management application component, you can display a master record centrally as follows:

1. From the Accounts Payable menu, choose Master records  Maintain centrally  Display. 

The system displays the initial screen for displaying master data, Display Vendor: Initial screen.

2. Enter the account number, the company code and the purchasing organization. 

Depending on the data you want to display, you can omit the company code or the purchasing organization.

A vendor master record spans several screens. If you want to see particular data only, you can select the screens you want to see in the initial screen. The system then shows you the corresponding screens only.

3. Select the screens you wish to display. 

4. Select ENTER . 

The vendor master record is displayed.

5. To leave the display, choose Vendor  Exit.

You return to the area menu.

Display a Vendor Master Record for Accounting

If you want to display only that vendor master data required by the accounting department, proceed as follows:

1. Choose Master records  Display. 

The system displays the initial screen for entering a vendor master record.

2. Enter the vendor account number and the company code. 

A vendor master record spans several screens. To display particular data only, select the screens in the initial screen. The system then displays the corresponding screens only.

3. Select one or more screens to display by clicking in the field before the name of the screen. 

4. Select ENTER to reach the next screen. 

The system displays the next screen that you have selected in the vendor master record.

5. To leave the display, choose Vendor  Exit. 

This returns you to the Accounts Payable menu.

 Changing a Vendor Master Record Centrally  

Change a master record centrally as follows:

1. From the Accounts Payable menu, choose Master records  Maintain centrally  Change. 

The system displays the initial screen for changing master data.

2. Enter the vendor account number, the company code and the purchasing organization. 

3. Select which screens of the vendor master record to display by clicking in the field next to the name of one or more screens. 

Depending on the data that you want to change, you can omit the company code or the purchasing organization.

Vendor master records span several screens. Generally speaking, you will want to change only certain fields. You can select the screens to make changes directly on the initial screen.

4. Select ENTER to reach the next screen. 

The system displays the vendor master record.

5. Change the required data by overwriting it or adding to it. 

6. Save your changes by choosing Vendor  Save.

You return to the area menu. The system confirms that the data has been saved with a message. 

 Changing a Vendor Master Record for Accounting  

If you want to change only the accounting data in a vendor master record, proceed as follows:

1. Choose Master records  Change from the Accounts Payable menu. 

You reach the initial screen for changing master data.

2. Enter the vendor account number and the company code. 

Vendor master records span several screens. Generally, you wish to change certain fields only. You can select the screens to make changes directly in the initial screen.

3. Select which screens of the vendor master record to display by clicking in the field before the name of one or more screens. 

4. Choose ENTER. 

The master data from the account is displayed.

5. Change the required data by overwriting it or adding to it. 

6. Save your changes by choosing Vendor  Save.

You return to the area menu. The system generates a message, confirming that the data has been saved.

If you have changed master records in one company code and want to make exactly the same changes in other company codes, you can distribute these changes to the required company codes using the Send function. To access this function, choose Master records  Compare  Company codes  Send from the Accounts Payable menu. For more information on this topic, refer to the Implementation Guide. 

Displaying Changes to Vendor Master Records  

When you change a master record, the system logs these changes and generates change documents. For each field, it stores the time of change, the name of the user, and the previous field contents.

You can display all the changes for the following:

• A certain field

• A master record

• For several vendor master records

The following changes are displayed separately:

• Overwritten field contents

• Any bank details and/or dunning areas entered after the master record was created

• Any bank details and/or dunning areas that have been deleted

Using the change documents, you can see which changes were made when.

From the Accounts Payable menu, you can display changes to a vendor master record as follows:

1. Choose Master records  Maintain centrally  Display changes. 

The system displays the initial screen for displaying changes.

2. Enter the vendor's account number and the company code and, optionally, a dunning area, a purchasing organization, a date after which the account was changed, or a user that made the changes. 

You can limit the changes display by specifying a change date and a user name.

3. Choose ENTER . 

The system displays a list of types of changed fields.

4. Select the changes you want to display: 

– To display a field change, place the cursor on the required field and select it.

– To display all changes, choose Got  All changes.

– To display the entered bank data or dunning areas, choose Got  Entries.

– To display deleted bank data or dunning areas, choose Got  Deletions.

– To display the change document, choose Got  Change document.

5. Leave the display of changes by choosing Account changes  Exit.

Displaying Changes in Several Vendor Master Records

You can use program RFKABL00 to produce a list of the changes made to a certain specified number of vendor master records. To start this program, proceed as follows:

1. Choose from the Accounts Payable menu Periodic processing  Info system  Report selection  Adequacy and documentation  Master data  Changes. 

2. Choose Program Execute. 

 Blocking a Vendor Account Centrally  

When you block an account centrally, you can prevent both posting and order processing, if you have purchased, installed, and configured the Materials Management (MM) application component.

Block a vendor account centrally as follows:

1. Choose Master records  Maintain centrally  Block/unblock. 

The system displays the initial screen. On this screen, you can specify the areas that you need to block by entering the company code and purchasing organization. If you do not specify the key for an area, the corresponding block fields are not set.

2. Enter the vendor's account number and the company code. Optionally enter the purchasing organization. 

3. Select ENTER . 

The Block/Unblock Vendor: Details screen is displayed.

4. To block posting, select the company code of the displayed vendor master record or select all company codes by clicking in the corresponding field. 

5. To block purchasing, select either the displayed purchasing area or all purchasing organizations by clicking next to the corresponding field. 

6. Save your entries by choosing Vendor  Save.

The system displays the initial screen and a message that confirms that the data has been saved. 

 Blocking a Vendor Account for Posting  

When you block a vendor master record for posting, you prevent the system from posting to this account.

Block a vendor account from posting as follows:

1. Choose Master records  Block/unblock. 

The system displays the initial screen.

2. Enter the vendor's account number and, if required, the company code. 

If you do not enter a company code, you can only block posting for this vendor in all company codes.

3. Select ENTER . 

The system displays the entry screen for the block indicators.

4. Select for blocking either all company codes or the specified company code by clicking the appropriate field. 

5. Save your entries by choosing Vendor  Save.

The system displays the initial screen and a message that confirms that the data has been saved. 

 Blocking a Vendor Account for Payments  

To block a vendor master record for the payment program or for manual payments, you have to change the vendor master record. When you block the vendor account for the payment program, the payment program still processes the open items in the account during the payment run, but it does not pay any open items from the blocked accounts. You can display a list of vendors blocked from the payment program.

To block a vendor for the payment program, enter a block key in the vendor master record. These keys represent reasons for blocking. You use them to show why an account was blocked.

Block the account for the payment program as follows:

1. Choose Master records  Change. 

The system displays the initial screen for changing a vendor master record.

2. Enter the vendor account number and the company code. 

3. Select the payment transaction data screen in the company code data area by clicking in the appropriate field and then selecting ENTER . 

4. To block this vendor for the payment program (or manual payments), enter the appropriate blocking key in the Payment block field. 

5. Choose Vendor  Save to save the vendor master record.

The system displays the initial screen and a message that confirms that the data has been saved. 

 Archiving and Deleting Vendor Master Records  

You can archive vendor account master records that you no longer need. Archiving data entails it being extracted from the SAP database, deleted and placed in a file. You can then transfer this file to an archive system. For more information on archiving vendor master data, see the manual Application Data Archiving and Reorganization.

Vendor master records may not be archived immediately. For you to archive a customer master record, the following requirements must be met:

• The account cannot contain any transaction figures in the system. Transaction figures from prior years that have not been archived will prevent the system from deleting the account master record. 

• The account must be marked for deletion in its master record.

You should block an account for posting before you mark it for deletion. The only effect this deletion indicator has is to cause a warning to be issued every time you subsequently try to post to this account. 

Prior to going live with your system, you can delete the test data. For more information, see the activity Delete customer master data in Customizing for Accounts Receivable and Accounts Payable.

The topics in this section explain how to mark master records and their accounts for deletion. The deletion process is described in the document FI Closing and Reporting.

The organization of master data in your system is also an important part of marking master records for deletion. You can set the deletion flag for all company codes or just one specific company code.

You can reset a deletion flag at any time as long as the master record has not been physically deleted from the system.

If all open items in the vendor account you are deleting are cleared, you should block it for posting so that other users cannot post to it. For more information on this, see Blocking a Vendor Account for Posting 

See also:

Marking a Master Record for Deletion Centrally

Marking a Master Record for Deletion for Accounting 

 Automatic Transfer of Vendor Master Data  

You can transfer vendor master data automatically using batch input. The system carries out the function of creating a vendor master record for each master record. By doing this, the data is transferred to the screen fields and checked.

You should first maintain in the system all the appropriate keys and indicators, and any other master records which are referred to. If you do not do so, errors may occur when you transfer data.

You should check in any case whether the field status definitions are correct. Errors occur if you suppress fields via the field status definition and then provide field contents when you transfer data.

For more information, see the Data Transfer section in the document General FI Topics. 

Business Partner Master Data (LO-MD-BP)  

Purpose

The following types of business partner are defined in the R/3 System:

• Partner type customer

A customer is a business partner with whom you exchange goods and services. Two types of customer are defined in the R/3 System:

o Internal customers (own sites) 

o External customers

• Partner type vendor

A vendor is a business partner from whom goods and services can be procured. Two types of vendor are defined in the R/3 System:

o Internal vendors

Normally you only maintain distribution centers as internal vendors.

o External vendors

You select external vendors from companies offering an assortment of goods and services on the market, with the help of guidelines drawn up by your Purchasing department.

• Other partner types

A contact person is an example of another business partner in the R/3 System.

.

Data on business partners is stored in master records. The system uses this data in a number of business transactions, proposing the data in the appropriate fields when, for example, you create sales or purchase orders.

 Business Partners  

Use

Business partners have a number of different functions, described as partner functions, in connection with your company. You use partner functions to define the rights and responsibilities of each partner type in a business transaction. When you sell or order goods, for example, your business partners can assume partner functions such as:

Customer Partner Functions Vendor Partner Functions

Sold-to party Ordering address

Ship-to party Goods supplier

Bill-to party Invoice presented by

Payer Alternative payee

Different business partners may carry out one or more partner functions. For this reason, you can assign individual business partners a number of partner functions.

You manage data on business partners in master records. Data on partner functions is stored in these master records and used in Financial Accounting and Logistics.

 Business Partner Master Data Structure  

Use

You enter data on business partners with whom your company has a business relationship in master records. Master records contain all data necessary for processing business transactions. This is known as master data.

If you enter all master data, you spend less time processing business transactions because the system proposes the master data in these transactions. 

Financial Accounting and Logistics use master data. General data and data relevant to both departments is stored in shared master records to avoid duplication.

 Partner Functions  

Use

Use partner functions to define the rights and responsibilities of each business partner in a business transaction. You assign partner functions when you create a master record for a business partner.

 Creating and Changing Business Partner Master Data  

Use

Business partner master data from Financial Accounting and Logistics is stored in shared master records that can be accessed from both views. This function lets you create and change master records for business partners centrally, that is, including the following data: 

• Customer master records and vendor master records 

o General data

General data is independent of company code, sales area, and purchasing organization and is therefore valid for business partners for all company codes, all sales areas, and all purchasing organizations.

o Company code data

The company code data is defined separately for individual company codes. You can only bill for a transaction if the payer has been maintained from a Financial Accounting view (company code data).

• Customer master records only

o Sales area data

• Vendor master records only

o Purchasing organization data

 Blocking Activities with Business Partners  

Use

There can be many reasons for blocking certain activities with business partners, for example: 

• Your business partner has outstanding debts or goes into liquidation 

• You want to stop all deliveries to or from a business partner 

• Your business partner fails to reach agreement with you on conditions 

• Your business partner repeatedly issues incorrect invoices

 Account Balances and Line Items  

Purpose

When you post business transactions to accounts, the system automatically updates the account balance, and notes which items from the document were posted to the account. It is therefore possible to view the account balance and line items for every customer account.

 Line Item Display  

Use

You can display the line items for one or more accounts.

Line items are document items that were posted to a specific account. In contrast to a document item, a line item only contains the information from the document that is relevant from the account view.

You can display the following line items:

• Open items 

• Cleared items 

• Noted items 

• Parked items 

• Items with special G/L transactions (in Accounts Receivable and Accounts Payable) 

• Items with customer or vendor items (in Accounts Receivable and Accounts Payable)

You can display the line items for the following account types:

• Customer accounts 

• Vendor accounts 

• G/L accounts

 Displaying Line Items via the Internet  

Use

You can use the Internet to log on to your business partner’s system and display the line items in your accounts.

 Posting Business Transactions in Accounts Receivable  

Purpose

You post accounting data for customers in Accounts Receivable. From there, the data is sorted by customer and made available to other components, for example Sales and Distribution. When you post data in Accounts Receivable, the system creates a document and passes the data entered to the general ledger. General ledger accounts are then updated according to the transaction concerned (receivable, down payment, bill of exchange, and so on). 

 Parking Invoices/Credit Memos - Enjoy Transaction  

To make entering invoices/credit memos accessible, use the alternative standard transactions F-64 and F-67.

Use

You can park invoices/credit memos before you post them. This is useful for example, if the data you want to enter is incomplete, or the parking and posting functions are carried out by different accounting clerks (dual control principle). To use the single screen transaction for invoice/credit memo parking, choose Accounting  Financial Accounting  Accounts Receivable/Accounts Payable  Document Entry  Document Parking  Park/Edit Invoice/Credit Memo. 

For more information about the standard and the single screen transaction, see Document Parking 

 Entering Customer Account Line Items  

Use

Once you have entered the data for the document header, you can enter the line items for the customer account.

 Terms of Payment (Accounts Receivable)  

Use

If you have maintained a key for the terms of payment in the customer master record, the system automatically defaults this key whenever you enter an item for this customer. The terms of payment key can determine the following:

• The valid cash discount rate for an individual payment with a maximum of 3 payment terms (first cash discount period, second cash discount period, and due date for net payment) and also a baseline date for the payment

• The terms of payment for installment payments.

 Terms of Payment for Installment Payments (Accounts Receivable)  

Use

For more information about entering the key for installment payments, see Terms of Payment (Accounts Receivable) When you enter a key for installment payments, the text Due in is displayed as well as the Payment terms field and the Days/Perc. fields remain empty.

 Dunning Data  

If a dunning procedure has been entered in the customer master record, you see the following dunning fields when you enter a customer line item and choose Extras  More data:

• Dunning block

• Dunning key

The dunning block field prevents the automatic dunning program from dunning the item. The Dunning key field determines whether dunning this item is restricted or whether the item is listed separately in the dunning notice.

 Entering Payment Requests (Accounts Receivable)  

Use

A payment request is a noted item and it triggers a dunning notice through the dunning program. You can enter payment requests both for invoices that have already been posted and invoices that have been parked.

To enter a payment request, choose Document entry  Others  Payment request from the Accounts Receivable menu.

No transaction figures or other totals are updated.

See FI- Accounts Receivable and Accounts Payable for more information on payment requests.

 Posting Documents in Foreign Currency (Accounts Receivable)  

Use

When you post a customer document (invoice) in foreign currency, the system stores the amount in both local and foreign currency for each line item.

 Special Features of One-Time Accounts (Accounts Receivable)  

Use

A one-time customer is a customer with whom you do business once or rarely. Therefore you create a common master record for all of these customers, which does not, however, contain data specific to one single customer, such as name and address. You enter this information when entering a document. The appropriate entry screen is automatically called up when you post to a one-time account.

For more information about one-time accounts, see "Customer Master Records" in the SAP Library FI Accounts Receivable and Accounts Payable.

 Special Features of One-Time Accounts (Accounts Receivable)  

Use

A one-time customer is a customer with whom you do business once or rarely. Therefore you create a common master record for all of these customers, which does not, however, contain data specific to one single customer, such as name and address. You enter this information when entering a document. The appropriate entry screen is automatically called up when you post to a one-time account.

For more information about one-time accounts, see "Customer Master Records" in the SAP Library FI Accounts Receivable and Accounts Payable.

 Posting Business Transactions in Accounts Payable  

Purpose

You post accounting data for vendors in Accounts Payable. From there, the data is sorted by vendor and made available to other areas such as the purchasing system. When you post data in Accounts Payable, the system creates a document and passes the data entered to the general ledger. General ledger accounts are then updated according to the transaction concerned (payable, down payment, and so on). 

 Parking Invoices/Credit Memos - Enjoy Transaction   

To make entering invoices/credit memos accessible, use the alternative standard transactions F-64 and F-67.

Use

You can park invoices/credit memos before you post them. This is useful for example, if the data you want to enter is incomplete, or the parking and posting functions are carried out by different accounting clerks (dual control principle). To use the single screen transaction for invoice/credit memo parking, choose Accounting  Financial Accounting  Accounts Receivable/Accounts Payable  Document Entry  Document Parking  Park/Edit Invoice/Credit Memo. 

For more information about the standard and the single screen transaction, see Document Parking 

                  “SAME LIKE CUSTOMER”

See the accounts payble some of are different from a/c receivable.

 Payments  

Purpose

You can use the payment program to process international payment transactions with customers and vendors. 

Information on payment transactions in Euro can be found by choosing "Cross-application components" and then "European Monetary Union", and also in the SAP Library under European Monetary Union: Euro (CA-EUR)

 How the Payment Program Works  

Purpose

With the payment program you can process international payment transactions involving your customers and vendors.

 Bank Chains (Multi-Stage Payment Methods)  

Use

Bank chains are used to make payment via more than one bank, for example via the correspondence banks of the house bank, the recipient bank, or the intermediary banks. You can define up to three banks. 

Before the advent of this function, when making a payment to a business partner abroad, you had to specify your house bank and the business partner’s bank when processing payments. These two banks represented the start and end of the payment cycle and it was down to the house bank to determine via which banks the payment should be made. Using the bank chain function, you can now specify this bank chain yourself, leading to faster payment transaction processing and considerable cost savings through reduced bank charges.

 Defining Bank Chains for Customers and Vendors  

Use

The purpose of this activity is to specify which bank chain is to apply for a given customer or vendor.

 Defining Bank Chains for House Banks  

Use

Here you define which bank chain applies for incoming or outgoing payments for a given house bank.

 Defining Bank Chains for Cash Management  

Use

To define bank chains for Cash Management.

 Including Bank Chains on Payment Lists  

Use

In the standard system, the bank chain is not printed on the payment list or the exception list. If you want the system to include the bank chain on the printout, carry out the technical modifications detailed below.

 Selecting Open Items  

Use

The payment program identifies the open items and selects the items to be paid. Items are always paid as late as is possible without losing cash discount. You specify the exact time of payment when configuring the payment program. 

 Grouping Open Items and Individual Payments  

Use

Wherever possible, the payment program will always group items together for payment. However, you can also specify that an individual payment (a separate payment) is made for a particular item. Indeed, for certain payment methods such as the POR procedure in Switzerland and the PBC procedure in Denmark, only individual payments are possible. 

 Specifications for Posting Payments  

Use

The payment program posts payments and related postings such as those for tax, tax adjustments, exchange rate differences, or cash discount) automatically. 

 Posting Separately by Business Area  

Use

If you have determined that the payments for a certain company code should be made separately per business area, then the bank posting is made to the business area of the paid items. 

If you do not separate the payments by business area, you can specify that the bank postings should be made to one certain business area. To do so, specify the required business area for the bank account (see the figure above). 

This specification is only effective if you do not already pay separately by business area.

In all other cases the postings to the bank subaccounts are carried out without reference to business areas.

 Document Type for Payments  

Use

You specify the document type which the payment program should use for posting the payments when making the country-specific specifications for the payment method. The document type must be defined using internal number assignment.

You can specify two document types for cross-company code payments. One document type is used for the document in the paying company code, the other for the clearing postings in the other company codes. 

 Posting Exchange Rate Differences: Payment Program  

Use

Unless you specify otherwise, the payment program posts the exchange rate differences arising from foreign currency items. It does this by determining the difference between the rate at the time of posting and that when the item is paid. In order to determine the local currency amount at the time of payment, the payment program uses the exchange rates defined in the system.

If you do not want the exchange rate differences to be posted, you should specify this for the paying company code. See Specifications for the Paying Company Code. If you do so, the payment program calculates the equivalent payment amount in local currency on the basis of the local currency amounts in the paid items. 

If the items to be paid have been reevaluated in the course of balance sheet preparation work, the adjustment postings to the receivables and payables accounts are reversed when the item is paid. At the same time, in order to determine the payment amount in local currency, the system also reads the valuation difference noted in the item.

 

If the payment program posts exchange rate differences, these actual exchange rate differences are noted in the cleared item. Such exchange rate differences are only temporary because the final difference can only be calculated when the bank statement is posted. It follows that you may have two exchange rate difference postings. If the payment program does not post any exchange rate differences, the cleared item does not then contain any information on realized differences. The exchange rate differences are not posted until the bank statement is posted. This method does not allow you to assign the differences to affiliated and non-affiliated companies for example. Further, it is not possible to retroactively assign the exchange rate variances to the business areas or cost centers which generated them. 

 Consistency Checks: Payment Program  

Use

During configuration of the payment program the checks usually carried out in the SAP System are performed. This includes a check as to whether the keys entered are defined in the system. If necessary the system issues a warning or error message.

You enter a document type for the payment postings that has not yet been defined. The system will issue an error message. If, however, you have specified for the bank posting a bank subaccount that has not yet been created, the system merely warns you.

After configuration of the payment program, you can have the system run a consistency check. During this, the system checks whether keys were entered during the configuration of the payment program that have since been deleted from the system. 

You enter a business area for the bank posting. If you then delete this business area, you should also remove the corresponding entry from the payment program configuration. The consistency check shows you the appropriate key.

During the consistency check, the system runs the same checks as it did for the configuration. 

You can request an additional log for the payment run. If the program did not settle certain open items, the reasons for this are detailed in this log. You can decide how to rectify the situation on the basis of this information. 

 Payment Currency  

Use

You use this function if you wish to use the automatic payment facility to make payments in which the currency of the items to be paid is different from the currency of the payment.

This enables you, the payer, to fulfill your obligations to pay in any of the currencies currently at your disposal.

You can either come to a general agreement with your vendor about which alternative currencies can be used, or make separate arrangements for individual cases about the payment currency and, if necessary, the payment amount.

You can specify an alternative payment currency in the open item. You can also specify an amount. This states the equivalent of the gross amount of the open item in the payment currency.

 Special Features When Paying by Bill of Exchange  

Use

Payment by bill of exchange varies from country to country. Two different procedures can be distinguished:

• Bill of exchange issue before due date

• Bill of exchange issue on due date

Bill of exchange issue before due date

In countries such as France, Spain, and Italy, bills of exchange are issued directly after the invoice is issued. The drawer (payee) is thus able to pass on the bill of exchange to a bank for refinancing as early as possible. He pays the bill of exchange charges. 

When settling payables by bill of exchange, the bill of exchange payable is drawn up at an early stage and sent to the vendor. 

For bills of exchange receivable (bill of exchange is drawn on the customer), the bill of exchange is printed by the payment program and then either:

• Sent directly to a bank for refinancing. This bill of exchange receivable is referred to as a bank bill.

• Sent to the customer for acceptance. This bill of exchange receivable is referred to as a bill of exchange payment request. 

Bill of exchange issue on due date

In Germany and Austria, bills of exchange are not issued until the invoice is actually due (the due date of the bill of exchange will be later than the due date of the invoice). The payer thus gains from the fact that his receivables are paid later on the bill due date. He is liable for the bill charges, though. In the payment program, this procedure is only used for bills of exchange for outgoing payments.

If you use this procedure, bills of exchange payable and bills of exchange for the incoming check/bill of exchange procedure are printed.

The special features to be noted for the above-mentioned procedures during the payment program are described below. 

The preparations necessary for posting bills of exchange and the procedure to be followed is described in Special G/L Transactions: Bills of Exchange

 Entering Payment Parameters  

Use

Before you can start the payment run, you first have to enter the payment parameters. You use these payment parameters to define when, for which period, which company code, which business partners, and so on should be considered by the payment program.

 Payment Medium Workbench  

Purpose

The Payment Medium Workbench (PMW) is a tool used to configure and create payment media sent by organizations to their house banks. This generic tool will gradually phase out the classic payment medium programs (RFFO*) due to the range of advantages that it provides.

• Superior control and verification of payment procedure 

• Improved performance with mass payments (> 50,000) 

• Better sort functions with payment advice notes 

• Clearer to work with than the myriad previous payment medium programs 

• Easier to maintain and to extend

 Payment Requests  

Use

Payment requests are used mainly in France. Instead of a payment form, a letter is sent to the debtor, requesting him/her to settle the listed items. 

You must define a separate payment method for the payment request.

The items to be paid are selected in the same way as items for bill of exchange payment requests or bills of exchange generated before the item due date. 

 Paying by Payment Card  

Use

Payment card data is transferred to the Financial Accounting (FI) application component from the Sales and Distribution (SD) application component or from the SAP Retail industry solution via interfaces.

Payment card data is not entered or changed in the accounting document. When data is transferred from Sales and Distribution (SD) or SAP Retail, the system copies payment card information to the financial accounting document. Payment card data is transferred only to accounts receivable line items and to those G/L items that contain the receivables due to the payment card institute. Accounts payable line items are not affected.

 Resetting Cleared Items with Payment Card Information  

Use

You use this function to reset cleared items with payment card information

Prerequisites

 Dunning  

Purpose

Sometimes your business partners may fall behind on payments. You can send them a payment reminder or a dunning notice to remind them of their outstanding debts.

The SAP System allows you to dun business partners automatically. The system duns the open items from business partner accounts in which the overdue items create a debit balance. The dunning program selects the overdue open items, determines the dunning level of the account in question, and creates a dunning notice. It then saves the dunning data determined for the items and accounts affected.

You can use the dunning program to dun both customers and vendors. It may be necessary to dun a vendor if he or she has a debit balance as a result of a credit memo. If a customer is also a vendor, you can offset the account balances against one another.

Dunning is also used in the Real Estate components.

• For more information about Real Estate (RE), see Dunning Procedure for Rental Agreement

• For more information about Flexible Real Estate (RE-FX), seeDunning.

  Dunning Process  

Purpose

The automatic dunning program runs according to the dunning process described below. It enables you to regularly check your ledgers for overdue receivables, and then create payment reminders for these business partners. 

 Creating Dunning Proposals  

Purpose

During the dunning run, the dunning program determines all customer (and vendor) items and accounts for which dunning notices can be issued. This is the basis of the dunning proposal. 

The dunning proposal is output in the form of a list that contains all items and accounts for which dunning notices can be issued (that is, they are overdue). The list is sorted according to account and dunning level.

You can process the dunning proposal further. 

Prerequisites

Make sure that you have made the settings for the following features: 

• Dunning procedure 

• Company code data 

• Dunning data in the customer master record (or vendor master record) 

• Blocking of open items (if required)

• Dunning parameters

For more information about preparing and starting the dunning run, see Setting Dunning Parameters and Creating Dunning Proposals.

Process Flow

You control the dunning program via the settings you make for the dunning procedure. Further control can be exercised via the settings you make in the customer or vendor master record, via the open items, and by the parameters for the dunning run.

You control dunning via:

• Company Code-Specific Specifications:

One of the factors these specifications determine is which company codes are dunned.

• Dunning Procedure

This contains the most important specifications for controlling dunning. These include the dunning frequency, the dunning levels, and the grace days for the due date determination. 

• Customer/Vendor Master Record

In the master record, you specify which dunning procedure should be used for that account. The dunning program stores the date of the last dunning run and the dunning level in the master record. If an account is not to be dunned, enter a dunning block. 

• Open Items

You can block items from being dunned, or specify that an item is only to be dunned up to a certain dunning level. The dunning program notes the date of the last dunning run for the item and the dunning level. 

• The Parameters for the Dunning Run.

These include the company codes and accounts that are to be checked during the dunning run, and the posting date up to which documents should be taken into account.

The automatic dunning program uses these criteria to check the items and accounts for the following: 

• Whether they are overdue 

• Charges and interest

• Dunning levels

For more information about the technical process flow of the dunning program and the program's special functions, see Controlling the Dunning Run and Special Functions in Dunning.

Result

The program produces a dunning proposal. You can process this proposal further if required, and then print the dunning notices.

 Editing Dunning Proposals  

The dunning selection run generates a dunning proposal. This contains the open items that the dunning program has selected for dunning. You can either accept or change the dunning proposal. If you change the dunning proposal, these changes are recorded in an additional log.

You can view or edit dunning proposals. You can:

• Raise or lower the dunning level of an item

• Block an item from being dunned

• Block an account for the current dunning run or remove the block

• Block an account in the master record for dunning or remove the block

• Block a document for dunning or remove the block

To edit a dunning proposal, proceed as follows:

1. When the status display Dunning selection is complete appears on the Dunning screen, choose Dunning notices  Change dunning notices. 

2. Choose Enter to display all the accounts to be dunned. 

Alternatively, select the accounts to be dunned by entering the following criteria: 

a. A single customer or a range of customers 

b. A single vendor or a range of vendors 

c. Company code 

d. Accounting clerk 

e. Dunning areas 

f. A dunning level or range of dunning levels 

g. Dunning block

Choose Continue. 

The dunning proposal is displayed with the account overview.

3. Select an entry from the list and edit it. You can: 

• Block an account for the current dunning run or remove the dunning block

From the account overview, you can prevent an account from being dunned or remove the dunning block by changing the entry in the Dunn.block field. If you set an account dunning block, then you can no longer edit the relevant dunning items. However, this dunning block only applies for the current dunning run. If you want to change the dunning block for the account permanently, you have to do this in the customer master record. 

• Block an account for dunning or remove the block in the master record. 

From the account overview, you can branch directly to the master record in order to make a permanent change to the dunning block for an account. To do this, position the cursor on the relevant account and then choose the Master record function. This takes you directly to the dunning data within the master record where you can change the dunning block. This dunning block change is, however, not valid for the current dunning run. If you want it to apply to this run as well, then you must also make the change in the account overview.

• Change the dunning level of an item

From the account overview of the dunning proposal, you can branch to the item overview by choosing Dunning items. This overview then displays the individual documents for the account selected. 

Here you can change the dunning level by making an entry in the Lv (dunning level) field.

• Block a document for dunning or remove the block

From the item overview, you can also branch to the document. To do so, select the document - either by double clicking, or selecting F2. You can change the dunning block in the document. This dunning block change however, is not valid for the current dunning run. If you want it to apply to this run as well, you must also set the dunning block in the item overview for the dunning proposal. 

4. Save your changes.

 Dunning Forms  

For information on how to create and change forms, refer to the documentation on SAPscript word processing. The following is only a description of the special features to be observed regarding dunning forms. 

To ensure that the forms are printed correctly by the print program, the position of each group of data in the form is predefined in the system. The form layout is defined with SAPScript. 

You can use just one form or several different forms for the dunning notices in your organization. You specify the form when you configure the dunning program, depending on the dunning procedures, the company code, and the account type involved. You can further differentiate selection by dunning level (see the figure below, (1)) and dunning area (see the figure below, (2)), and separately for legal dunning proceedings (see figure below, (3)).

 

You need different dunning forms if you

• Use dunning procedures with different dunning levels. You have defined a one-level dunning procedure and a multi-level dunning procedure, for example. In this case, you need one form for each dunning procedure. 

• Require different line layouts. This is the case, for example, if you want to print the line items in the dunning notices without interest for lower dunning levels and with interest for higher dunning levels.

• Require different totals layouts. This might be necessary if, for example, you need one form on which both the item totals and the account balance are printed, and one form on which only the item totals are printed. 

You do not need different dunning forms if, for example, you have defined the dunning procedure so as to dun with different dunning frequencies. You can also use the same form if you want to dun in different languages. You only need to translate the texts of the form to do this. The forms are stored by language key. In each case, the print program selects the form in the language entered in the master record of the business partner. If the form is not available in this language, the system uses the default language of the form. In this case, the dunning program issues an error message in the log for the dunning run.

If you use the same form for several company codes and dunning procedures, you only have to specify the form once. For the company codes and dunning procedures that use the same form, refer to the reference company code (see Company Code-Specific Specifications: Figure (3)), or the reference dunning procedure (see Entering Grace Days and Minimum Days in Arrears) . 

The form can only be maintained for this company code or this procedure. 

 

The reference dunning procedure for the forms should only be used for procedures that have the same number of dunning levels.

You can enter one list name per dunning level. The dunning notices are then stored under this list name in the SAP spool. This makes it possible to store dunning notices from different company codes or with different levels separately in the spool. 

Form Components 

Letter Header, Sender, and Footer - Dunning Notices 

Text Elements in the MAIN Window - Dunning Notices 

Data from the Dunning Run for the Form Printout 

Dunning Form: Example 

Sorting Dunning Notices, Dunning Lists, and Open Items 

Modifying the Forms 

 Special G/L Transactions: Down Payments and Payment Guarantees  

The following topics explain the basic principles behind special G/L transactions including information on down payments and payment guarantees. They also explain which default settings you need to make in Customizing.

For detailed information on Customizing settings, access the Financial Accounting Implementation Guide and read the information about the activity Business Transactions to be found under Accounts Receivable and Accounts Payable.

Special G/L Transactions: Overview

Down Payment Requests

Down Payments

Guarantees

Creating Own Special G/L Transactions

  The Basic Principles of Special G/L Transactions  

Special G/L transactions are special transactions in accounts receivable and accounts payable that are displayed separately in the general ledger and the subledger. This is achieved by posting to alternative reconciliation accounts, instead of posting to the reconciliation accounts for receivables and payables.

The following special G/L transactions are available:

• Down payments and down payment requests

• Bills of exchange receivable, bills of exchange payable and checks/bills of exchange

• Bank bills

• Payment requests

• Guarantees

• Reserves for bad debt

• Security deposits

These special procedures are displayed separately from other receivables and payables on the balance sheet either for legal reasons, such as with down payments, or for control reasons, such as with guarantees received. A separate special G/L account is created for each special G/L transaction. As a result, it is possible to display each transaction in the balance sheet without having to carry out any transfer postings and to receive an overview via the account limited to this procedure only. 

  Down Payment Requests  

If you use the payment or dunning programs for posting or dunning of down payments, you need to use down payment requests. These are special documents that serve as a reference for posting a down payment or as a document for the dunning program. They do not update the account balance. 

When entering a down payment request, you enter the information required by the payment or dunning program. For example, you must enter a target special G/L indicator. The special G/L indicator is used later to post the down payment. The system requires this indicator to determine the correct special G/L account for down payments. Via the master record of this down payment account, the system determines which fields are relevant for entering a down payment request and how entries are treated. 

You enter a down payment request. To do this in the standard system, you enter the target special G/L indicator A. The system calculates the corresponding down payment account and determines how the tax is displayed in the open item and down payment accounts and which information is required in the down payment request. The corresponding fields are ready for input. Therefore, the last posted down payment accounts determine the specific adaptation of screens and not the request accounts.

Down Payment Requests, Payment, and Dunning Programs

The payment and dunning programs only process down payment requests if you specify this explicitly. For the payment program, you must specify the special G/L transactions to be processed when you make your company code specifications for the payment program. For the dunning program, you must specify per dunning procedure which special G/L transactions are to be dunned. You can find further information on the payment and dunning programs in this documentation. 

When you enter a down payment request, the Block indicator and Due date fields are always ready for input. The fields are used in order to release and schedule a down payment for posting by the payment program.

Special G/L Accounts for Down Payment Requests

You require a special G/L account for both outgoing and incoming down payment requests. You should manage these accounts with line item display since neither the transaction figures nor the account balance are managed in them. Only with line item display do you have an overview of down payments outstanding or to be made. 

If you enter a field status group or tax category in the account master record, it does not effect the entry of a down payment request since the system transfers this information from the down payment accounts that are determined via the target special G/L indicator. 

See also:

Special Features of Down Payment Requests

Entering and Posting a Down Payment Request

Reversing a Down Payment Request 

Displaying a Down Payment Request 

Changing a Down Payment Request 

Payment Requests

    Down Payments  

Down payments are used for short or medium-term financing. Generally the vendor or manufacturer does not have to pay interest on the down payment. In some lines of business, it is common to make a down payment if a manufacturer is not able to finance the production of goods alone because of a long production period, for example. Down payments are generally made before production begins or after partial completion. 

Down payments must not be balanced with other receivables or payables and must be displayed separately on the balance sheet. A receivable or payable results from the delivery of a tangible asset or the performance of a service. 

On the balance sheet, down payments made are displayed on the assets side and down payments received on the liabilities side. Down payments made are further divided, depending on whether they are:

• Down payments on tangible fixed assets

• Down payments on intangible fixed assets

• Down payments on inventory stocks

• General down payments.

Once you have received the goods or services for which you made a down payment, you need to clear this payment for the final settlement either manually or using the payment program. The down payment must no longer be displayed as such. 

See also:

Processing Down Payments in the R/3 System

Posting Down Payments

Special G/L Accounts for Down Payments

Integrating Other Applications

Down Payments and Tax

Transferring Postings for Down Payments

Clearing Down Payments

Down Payments and Cash Discount

Down Payments and the Dunning Program

Down Payments and Credit Limits

Net or Gross Display of Down Payments

Entering and Posting Down Payments

Processing Down Payments

Reversing a Down Payment

Displaying a Down Payment Request

Changing a Down Payment Request

  Guarantees  

Guarantees made are shown in the notes to the balance sheet. Guarantees received, however, are not displayed on the balance sheet. Nevertheless, it is a good idea for internal purposes to have an overview of the guarantees that you have received. In the SAP System, therefore, you can manage guarantees made and received separately from other business transactions - as special G/L transactions. 

The following describes the preparations for entering and posting guarantees made and received. 

Also described below is how payment guarantees made and received are posted and processed (as special G/L transactions). 

See also:

Processing Guarantees in the R/3 System

Clearing Accounts

Payment Guarantees Made and Received

   Payment Guarantees Made and Received  

Guarantees made are shown in the notes to the balance sheet. They are posted in the standard system as special G/L transactions. You do not need to make any further transfer postings to create the balance sheet, but can enter the account directly on a balance sheet item.

Although guarantees received are not shown on the balance sheet, you can still post them as special G/L transactions. By means of the special G/L account, you are then able to display all your guarantees (for internal purposes for example). By accessing the respective vendor account, you can also display an overview of the guarantees for each business partner. 

See also:

Posting a Guarantee Made

Reversing a Guarantee Made 

Posting a Guarantee Received 

Reversing a Guarantee Received 

Entering and Posting a Guarantee 

Reversing a Guarantee 

Displaying a Guarantee 

Changing a Guarantee

 Special G/L Transactions: Bills of Exchange  

The following topics explain how to post and process bills of exchange. For detailed information on Customizing settings, access Configuring the System Using the Implementation Guide and read the information about the activity Business Transactions to be found under Accounts Receivable and Accounts Payable.

Bills of Exchange: Overview

Bills of Exchange Receivable 

Bank Bills and Bills of Exchange Payment Requests 

Bill of Exchange List

Bills of Exchange Payable

Check/Bill of Exchange Procedure

 Bills of Exchange Receivable  

Bills of exchange receivable are managed using the special G/L method in the SAP System. When posting a bill of exchange receivable, you normally clear open items or post the payment as a payment on account. The system posts a bill of exchange receivable to the customer account and reduces the receivables from goods and services on the reconciliation account. The bill of exchange receivable is also automatically posted to the special G/L account for bills of exchange receivable in the general ledger. Information on posting a bill of exchange receivable can be found in Posting Procedure for Bills of Exchange Receivable

You can monitor the existing bill of exchange receivable at any time via the customer account. The special G/L account for bill of exchange receivables shows you the total amount of bill of exchange receivables that exist for the customers represented in this account. Bills of exchange receivable are not canceled until they have been cleared. 

For information on the specifications to be made when posting bills of exchange, refer to Posting a Bill of Exchange Receivable

Once you have presented the bill of exchange to a bank for financing, you post the bill of exchange usage. You now have a bill of exchange liability since, as a drawer, the bank has liability to recourse if your customer fails to honor the bill. This potential liability is posted to a bank subaccount and deleted once it has expired. 

If you wish to pass on bills of exchange to a bank, the presentation list required can be created automatically. If you like, you can also arrange for bill of exchange usage to be posted automatically or for posting to be prepared. This only applies to bills of exchange posted before the due date of the invoice, as is the case in Italy.

You can find out what preparations are necessary for bill of exchange usage in Posting the Usage of a Bill of Exchange Receivable

Once the bill of exchange is due for payment and any protest period has elapsed, you can cancel the bill of exchange receivable and the bill of exchange liability. You can define a country-specific bill of exchange protest period in Customizing. 

Bill charges are normally passed on to the customer. The system posts these amounts to the customer account and the corresponding revenue accounts. You can find out what preparations are necessary for the bill charges statement by referring to Bills of Exchange Receivable: Bill Charges

For bank bills and bill of exchange payment requests, there are certain special features that must be borne in mind when drawing-up and posting these items. Bank bills and bill of exchange payment requests are most common in Spain, France, and Italy. For further information, refer to Bank Bills and Bill of Exchange Payment Requests.

See also:

Bills of Exchange Receivable: Introduction

Posting Procedure for Bills of Exchange Receivable

Posting a Bill of Exchange Receivable

Bills of Exchange Receivable: Bill Charges

Posting the Usage of a Bill of Exchange Receivable

Bill of Exchange Liability at the Bank

Payment Period for Bills of Exchange

Entering and Posting Bills of Exchange Receivable

Entering and Posting Bill of Exchange Usage

Reversing Bills of Exchange

Displaying Bills of Exchange Receivable

Changing Bills of Exchange Receivable

 Bank Bills and Bills of Exchange Payment Requests  

Bank bills and bill of exchange payment requests are special bills of exchange receivable that are not issued by the customer but by you. Bill of exchange payment requests are sent to the customer for acceptance, and bank bills are passed directly on to a bank for financing. Bank bills are subject to a general agreement with the customer whereby the customer’s acceptance is not required. Both payment procedures are common in Italy, France, and Spain.

Types of Bill of Exchange Payment Request

Country Name of the Bill of Exchange

France Lettre de change classique

Lettre de change relevé

Italy Ricevuta bancaria

Spain Solicitud letra de cambio

Types of Bank Bill

Country Name of the Bill of Exchange

France Lettre de change relevé

Lettre de change classique

Billet à ordre classique

Billet à ordre relevè

Italy Ricevuta bancaria

Spain Letra de cambio

Recibos

These bills of exchange are normally issued immediately following posting of the invoice, and are due on the same date.

The procedure of posting and the information that needs to be defined in the system for these bills of exchange is the same as for bills of exchange receivable, with the exception of the way they are drawn up and posted. The bill of exchange usage and the clearing of the bill of exchange liability is dealt with in exactly the same way as for bills of exchange receivable. The same preliminary steps are necessary.

See also:

Posting Procedure for Bank Bills and Bill of Exchange Payment Requests

Bank bills

Bank Bills: Special Features

Posting a Bank Bill

Posting Bank Bills of Exchange: Requirements

Bank Bills: Bill Charges

Bank Bills: Preparations for the Payment Program

Posting Bank Bills 

Bill of Exchange Payment Requests

Bill of Exchange Payment Requests: Special Features

Posting a Bill of Exchange Payment Request

Requirements for Posting Bill of Exchange Payment Requests

Defining Bank Bills and Bill of Exchange Payment Requests

Dunning Bill of Exchange Payment Requests

Posting Procedure for Bill of Exchange Payment Requests

 Bills of Exchange Payable  

You will normally use the payment program to post bills of exchange payable. All the subsequent postings, such as the payment of a bill of exchange by the bank and the cancellation of the bill of exchange payable and the bill of exchange liability, have to be made manually. 

When posting a bill of exchange payable, the payment program clears the open items and posts a bill of exchange payable to the vendor account and to the special G/L account for the bill of exchange payable. 

If you so wish, the program can also post to a bank subaccount that displays the bill liability for each bank. This enables you to monitor when bills of exchange are due at which bank. This posting is particularly useful for cash management and forecast.  

The bill of exchange payable remains on the accounts until the bill of exchange is paid. 

Your vendor calculates the costs arising from the bill of exchange charges and sends you an invoice. It is posted and processed in the same way as any other invoice. You only need special G/L accounts for the bill of exchange charges. 

For information on the preparation to be made when posting bills of exchange, refer to Posting Bills of Exchange Payable: Preparations

After the bill of exchange due date is reached, your bank pays the bill of exchange. You post the payment of a bill of exchange and so clear the bill of exchange payables on the vendor and special G/L accounts. In addition, you must clear the bill of exchange liability on the bank subaccount. 

See also:

Posting Procedure for Bills of Exchange Payable

Posting Requirements for Bills of Exchange Payable

Posting Bills of Exchange Payable: Preparations

Entering and Posting a Bill of Exchange Payable

Entering and Posting the Payment of a Bill of Exchange

Reversing a Bill of Exchange Payable

Displaying Bills of Exchange Payable

Changing a Bill of Exchange Payable

 Check/Bill of Exchange Procedure  

Under the check/bill of exchange procedure, the customer and not the vendor uses the bill of exchange for refinancing. This is shown in the figure below:

The chain of events is as follows:

1. The customer pays for goods with a check. At the same time, he draws a bill of exchange on which he is named as the drawee and the vendor as the drawer. He sends the check and the bill of exchange to the vendor. 

2. The vendor signs the bill of exchange as the drawer and returns it to the customer. 

3. The customer passes on the bill of exchange to his bank to be discounted. Although the bill of exchange is drawn on him, he uses it himself for refinancing: he is credited with an amount that he himself owes to his vendor. The bank credits him with the bill of exchange amount minus the charges and discount interest. 

See also:

Check/Bill of Exchange in Accounts Receivable 

Check/Bill of Exchange in Accounts Payable 

 Check/Bill of Exchange in Accounts Receivable  

A check/bill of exchange in Accounts Receivable is referred to in the system as a reverse bill of exchange. Under this procedure, your customer pays an invoice by sending both a check and a reverse bill of exchange on which you are entered as the drawer. At the same time, your customer sends you a check/bill of exchange. You are entered as the drawer on the bill of exchange. 

You post the check to the incoming checks account, clearing the receivable. You also post the bill of exchange to the customer account since a bill of exchange receivable now exists against your customer. The system creates the offsetting entry on a clearing account and automatically posts it to the special G/L account "Contingent claims from check/bill of exchange". The bill of exchange liability which might arise if the bill of exchange is protested is shown on the special G/L account.

Once the due date and any country-specific protest period have elapsed, you cancel the bill of exchange receivable and the bill of exchange liability. To do this, you select the bill of exchange from the special G/L account. The system makes the postings to the customer account and the clearing account.

See also:

Posting a Check/Bill of Exchange in Accounts Receivable 

Canceling the Liability of a Check/Bill of Exchange in Accounts Receivable 

Requirements for Posting a Check/Bill of Exchange in Accounts Receivable 

Specifications for the Bill of Exchange Posting 

Entering and Posting a Check/Bill of Exchange in Accounts Receivable 

Reversing the Bill Liability of a Check/Bill of Exchange in Accounts Receivable 

Displaying a Check/Bill of Exchange in Accounts Receivable 

Changing a Check/Bill of Exchange in Accounts Receivable 

 Check/Bill of Exchange in Accounts Payable  

Under the check/bill of exchange in Accounts Payable, you pay an invoice with a check. At the same time, you send a bill of exchange to your vendor. The vendor is recorded on the bill of exchange as the drawer, and your company code is entered as the drawee. Your vendor returns the bill of exchange to you signed, enabling you to pass it on for bill of exchange usage.

See also:

Payment by Check and Bill of Exchange 

Check/Bill of Exchange: Bill of Exchange Usage 

Requirements for Posting a Check/Bill of Exchange in Accounts Payable 

Bill of Exchange Payable Arising From Bill of Exchange Issue 

Entering and Posting a Check/Bill of Exchange in Accounts Payable 

Check/Bill of Exchange in Accounts Payable and the Payment Program 

Posting the Bill of Exchange Usage for a Check/Bill of Exchange in Accounts Payable 

Posting the Payment of a Check/Bill of Exchange in Accounts Payable 

Reversing the Bill Liability of a Check/Bill of Exchange in Accounts Payable 

Reversing an Accounts Payable Check/Bill of Exchange 

Displaying an Accounts Payable Check/Bill of Exchange 

Changing an Accounts Payable Check/Bill of Exchange 

 Payment Release  

Purpose

You can set a payment block for any accounting line items. You then run a payment release. If this is completed successfully, the payment block is reset and the line items can be paid. 

Features

This enables you to carry out a check of individual line items and then release them for payment.

The payment release procedure uses the Workflow component. For information on the SAP Workflow, see the WF - SAP Business Workflow documentation.

 Payment Release Process  

Purpose

For each workflow variant, you can specify the amount from which a payment release should be triggered.

You can differentiate between one, two, and three-level release. This enables between one and three people to be involved in the release procedure, thus supporting both dual and triple control.

 Cross-Company Code Correspondence  

Use

You can combine data from several different company codes in one letter, and you can also use the sender details from an alternative company code.

You can use one or more correspondence company codes. The selected correspondence company code provides the sender details.

Cross-company code correspondence is supported for the following correspondence types: 

• Payment notification 

• Account statement 

• Bill of exchange charges statement 

• Internal document 

• Individual letters 

• Document extracts

 Document Reconciliation  

Use

You use the document reconciliation to reconcile posting documents in different company codes within a company. This is necessary to correct posting differences resulting from posting errors or different posting times.

 Customer-Vendor Relationship  

Use

Use this relationship to define partner relationships in which business transactions to be reconciled with each other can arise. 

You can also specify the customer-vendor relationships in the selection options Customer as partner, Vendor as partner, Customer in company code, Vendor in company code. 

 Parameters for Document Reconciliation  

Use

• Time-based parameters: Open at key date 

You can use this parameter to display all the documents open at a specific point in time. 

• Partner-based parameters

You can use this parameter to display all the details of a specific business relationship between companies in a consolidation group. 

• Currency translation-based parameters

You can use the parameters Exchange rate type and Key date for translation to define which exchange rate should be used for displaying translations. 

 Carrying Out Document Reconciliation  

Use

You can use this procedure to carry out a regular document reconciliation between the company codes for which Accounts Receivable Accounting and Accounts Payable Accounting are carried out in the same client. 

 Financial Information System  

Purpose

The financial information system enables you to run evaluations for the general ledger, accounts receivable, and accounts payable. 

  Displaying Payment History  

Use

You wish to display payment history evaluations. The display options are explained using the "country" grouping criterion at "group" level.

 Maintaining Evaluation Types  

Use

When you maintain evaluation types, you enter a key for the corresponding evaluation view and account type in the same way as you define evaluation views.

Check Management  

Check management is used in cases where, when issuing your checks, you do not want to use the payment document number as the check number, but a different numbering method instead. 

The check management functions help you to manage both prenumbered checks and those checks assigned numbers from your own number ranges.

Prenumbered checks are an accepted form of payment in countries such as the USA, the United Kingdom, France, Canada, and Australia. The numbers for these checks are determined by the bank and printed on the check itself.

You can define your own check number ranges in the following circumstances: If the bank defines a certain number interval; If the payment document number cannot be used for other reasons (it is too long or you want to define ranges big enough to last for several years, and so on); or if you want to use aspects of the functionality in check management described below.

Check management functions can be accessed from the Accounts Payable or Accounts Receivable menu by choosing Environment  Check information.

Those functions relating to the automatic payment program can also be accessed from the Automatic Payment Transactions screen by choosing Environment  Check information.

This section contains the following topics:

Check Management Configuration

Maintaining Check Lots

Defining Void Reason Codes

Check Management Functions

Program Run

Printing Checks Online

Entering Manually-Created Checks in Check Management

Supplementing Check Information/Cashing Individual Checks

Cashed Checks

Displaying Check Information

Displaying the Check Register

Creating a Check Extract

Archiving Checks

Rectifying Problems in Check Management

Check Management: Problems and Solutions in Overview

Renumbering Checks

Reassigning Checks to Payments

Reprinting Checks

Restart

Voiding Checks 

Cancel Check Payment

Deleting or Resetting Check Information

Canceling the Reprinting of Checks

Lengthening Check Numbers

 FI/SD - Credit Management/Risk Management  

Purpose

A large number of outstanding receivables or bad debts can have a not inconsiderable impact on company performance. Using Credit Management, you can minimize your credit risk by defining a credit limit for your customers. This is especially important if you do business with customers in financially unstable sectors or countries, or trade with countries that are politically unstable or that adopt a restrictive exchange rate policy.

Monitoring Credit During Sales and Distribution Processing  

Purpose

This process enables you to monitor credit when processing customer orders. 

 Credit Control Area  

Use

Credit and risk management takes place in the credit control area. According to your corporate requirements, you can implement credit management that is centralized, decentralized, or somewhere in between.

• For example, if your credit management is centralized, you can define one credit control area for all of your company codes. 

• If, on the other hand, your credit policy requires decentralized credit management, you can define credit control areas for each company code or each group of company codes. 

Credit limits and credit exposure are managed at both credit control area and customer level.

You set up credit control areas and other data related to credit management in Customizing for Financial Accounting. For more information, see the Implementation Guide under Enterprise Structure  Definition or  Assignment  Financial Accounting and then Maintain credit control area. You assign customers to specific credit control areas and specify the appropriate credit limits in the customer master record.

See also: Specifying Credit Limits by Credit Control Area 

Credit and Risk Management Settings: Overview

 Postings Without Credit Limit Checks  

Use

You can exclude the following postings from the credit limit check:

• Special G/L transactions 

• Postings with an alternative reconciliation account

 Credit Management in Distributed Systems  

Use

You can carry out credit checks from Sales and Distribution (SD) in the following scenario:

Central Financial Accounting and decentralized SD processing

The decentralized Sales and Distribution units all have independant credit management. This means maintenance of credit master data, checks in SD, and realeasing via the credit manager are all carried out decentrally.

As only credit-relevant data for the corresponding Sales and Distribution unit is available for credit checks on the decentralized Sales and Distribution units for the sales order, delivery and goods issue, and credit account data is also needed from the head office (for example, sum of open items, oldest open item, maximum dunning level), Financial Accounting (FI) makes the A/R Summary available.

With the help of the A/R Summary, the credit data can be collected in the central system, and sent, via ALE distribution functions, to decentralized Sales and Distribution processing, and can be evaluated. The A/R summary presents the inquiry in Financial Accounting for credit checks.

As the credit-relevant SD data (open sales order, delivery and billing document values) is not distributed, there are specific prerequisites for working with distributed systems.

 Risk Management for Receivables in SD  

Purpose

As well as Credit Management, there are several other ways to guarantee payments including letters of credit, export credit insurance, and payment cards. These forms of payment guarantees are all integrated in the Risk Management for Receivables component, providing you with an efficient tool for guaranteeing the payment of all billing values that arise in sales and distribution processes.

 Bank Accounting (FI-BL)  

Purpose

This component is used to handle accounting transactions that you process with your bank. 

 Bank Master Data  

Purpose

In the R/3 System, bank master data is stored centrally in the bank directory.

The following sections describe how you maintain bank master data and outline the factors you should consider when transferring bank master data automatically. 

In addition to defining bank master data, you also define your own bank details (house banks) and those for your business partner (entered in the business partner's master record). 

See Bank Selection for details on the settings required for the payment program, under Payments in the Accounts Receivable and Accounts Payable documentation. 

The following topics cover basic information on bank master data, including the settings to be made in Customizing.

 Bank Directories  

Use

The bank directory can be created in two ways:

• Automatic Transfer of Bank Master Data

Using program RFBVALL_0, you can import a bank directory into the SAP system from an ASCII file. You usually obtain a national bank directory on a data medium at a banking organization in your country. You should regularly update the bank directory.

Using program RFBVBIC_0, you can import a bank directory that you have created using the BIC Database Plus into the SAP system.

• Creating, Changing, or Displaying Bank Master Data

To create master data for all banks, proceed as follows from the initial screen: Accounting  Financial accounting  Banking  Master data  Bank master record  Create. 

You can enter the master data for your business partners' banks when you are editing the master data. When you are entering customer or vendor master data, or entering a document in a one-time customer account, the system automatically branches to bank directory editing if you enter bank details that do not exist in the directory. 

 Bank Distribution  

Use

When you create and change bank data and associated organizational addresses in different systems belonging to an SAP system group, every system displays the current bank data. As soon as you have saved bank data in one system, the data is sent on to other systems.

With the ALE business process, all changes to bank data are handled using a consolidation system. The local systems send all changes to the consolidation system and the consolidation system sends all changes back to the local systems. Bank data can also be edited in the consolidation system.

 Maintain Repetitive Codes  

Use

You can use this function to maintain the master data of repetitive codes in accordance with the company code and the house bank. You choose between the target account assignments:

• Bank-to-bank transfer 

• Business partners 

• Vendor

 Bank Chains (Multi-Stage Payment Methods)  

Use

Bank chains are used to make payment via more than one bank, for example via the correspondence banks of the house bank, the recipient bank, or the intermediary banks. You can define up to three banks. 

Before the advent of this function, when making a payment to a business partner abroad, you had to specify your house bank and the business partner’s bank when processing payments. These two banks represented the start and end of the payment cycle and it was down to the house bank to determine via which banks the payment should be made. Using the bank chain function, you can now specify this bank chain yourself, leading to faster payment transaction processing and considerable cost savings through reduced bank charges.

 Defining Bank Chains for House Banks  

Use

Here you define which bank chain applies for incoming or outgoing payments for a given house bank.

 Defining Bank Chains for Cash Management  

Use

To define bank chains for Cash Management.

 Defining Bank Chains for Customers and Vendors  

Use

The purpose of this activity is to specify which bank chain is to apply for a given customer or vendor.

 Including Bank Chains on Payment Lists  

Use

In the standard system, the bank chain is not printed on the payment list or the exception list. If you want the system to include the bank chain on the printout, carry out the technical modifications detailed below.

 Cashed Checks  

Use

If you receive data on cashed checks electronically from your bank - for example, as a file on a disk - you can use program RFEBCK00 to import the data into the SAP System, having converted it to SAP format first. 

Manual Bank Statement  

Use

With this function, you can manually enter bank account statements you receive. 

 Cash Journal  

Use

The cash journal is a subledger of Bank Accounting. It is used to manage a company's cash transactions. The system automatically calculates and displays the opening and closing balances, and the receipts and payments totals. You can run several cash journals for each company code. You can also carry out postings to G/L accounts, as well as vendor and customer accounts.

You should run a separate cash journal for each currency.

 Lockbox  

Purpose

You use this component to collect and process incoming payments using the lockbox procedure. This is a service offered by banks in the USA.

Instead of sending your payments and payment advice notes to your bank’s office, you send them to a central bank (normally a P.O. Box). Once the payments have been received, the bank creates a data file from the payment advice data and payment amounts of the customer. The check amounts are credited to your bank account. The file itself is sent to you at regular intervals to enable you to update your ledgers.

 Payment Request  

Use

You can create payment requests from various applications (such as FI, Treasury, HR). They must not necessarily be linked to an accounting document. The modules for generating and changing payment requests also incorporate the Cash Management update. Since payment requests have different origins, you access the functions for generating, changing and reversing them in the applications. The same applies for the lists of "open payment requests". When a payment request is generated, the payment data (payment amounts and due dates) is already known. This data is expected by the payment program, which does not support due date calculation and cash discount processing.

If you make a payment via a G/L account, you must specify all the data relevant for the payment in the payment request. If you make a payment via customer or vendor account, you can let the payment program determine the payment control parameters, the payment method, and the bank details.

Procedure: Payment Program for Payment Requests  

Use

The payment program covers the whole process of handling of payments from contolling the selection of payment requests up to the creation of payment media.

 Customizing of the Payment Program  

Use

Before you can use the payment program, you need to define your house banks and accounts at your banks, the required payment methods and the necessary payment forms. The standard system has predefined payment methods and forms which you can adapt to meet your own requirements.

In large parts, you use the same Customizing functions as in the standard payment program. This is particularly the case for controlling payment medium creation, company codes, payment methods and house banks. 

Some additional functions for controlling the payment program for payment requests are provided e.g. when defining house bank accounts and G/L account determination. The user can define the number of accounts per bank, currency and payment method for settling G/L account payments (e.g. bank account transfers).

 Fast Entry with Repetitive Code  

Use

This function speeds entry of payments with repetitive codes. It includes:

• Bank-to-bank transfers 

• Payments to business partners

  Processing Returned Debit Memos  

Purpose

This process describes how the electronic account statement processes returned debit memos. 

The file that the electronic account statement imports contains a returned debit memo. The returned debit memo has an amount, comprising of the debit memo amount and bank charges. In addition to the business transaction code, a reason for the returned debit memo is often specified. The note to payee contains the bank collection payment document.

  Asset Accounting Overview  

Purpose

The Asset Accounting (FI-AA) component is used for managing and supervising fixed assets with the SAP R/3 System. In SAP R/3 Financial Accounting, it serves as a subsidiary ledger to the FI General Ledger, providing detailed information on transactions involving fixed assets.

 Organizational Elements and Structures  

Purpose

In addition to providing for the management of assets and their values, asset accounting should offer an organizational structure for assets that reflects the organizational structure of the enterprise. For this reason, the FI-AA component uses the various SAP organizational units. An asset is clearly assigned to these organizational units at any given point in time. 

In addition, you need to classify assets according to various accounting criteria (such as depreciation methods). This classification assists in management-accounting-oriented tasks, and in the summarization of asset values in the general ledger. 

  Chart of Depreciation  

Use

SAP supplies typical reference charts of depreciation for each country. They have different depreciation areas and depreciation keys depending on that country’s specific requirements. You cannot use these charts of depreciation directly. You must create your own chart of depreciation by copying the reference chart of depreciation. Delete any depreciation areas that are not needed.

You can document the meaning of any chart of depreciation you set up in the system by writing a description for it. 

The graphic below shows the standard chart of depreciation for the USA.

  Chart of Accounts  

Use

In the General Ledger, you can define different charts of accounts. Each company code is assigned to exactly one chart of accounts. The chart of accounts is used for the account assignments within Asset Accounting. 

The account assignment is controlled by means of the asset class in Asset Accounting (refer to Account Assignment). You have to specify an account determination in each asset class. In this account determination, you specify the G/L accounts in which automatic posting takes place for different transactions.

 

  Assignment of Company Code  

Use

Asset Accounting uses the same company codes as the General Ledger. However, you need to define these company codes further with the specifications needed for Asset Accounting. An FI company code is not usable in Asset Accounting until it has been defined in this way.

FI-AA Company Code Definition

   Assignment of Business Area  

Use

The business area is another organizational criterion for General Ledger Accounting, in addition to the company code. 

  Assignment to Plant/Location/Address  

Use

The meanings of the plant and location organizational units are primarily specified in the SAP R/3 logistics components.

 Assignment to Cost Center and Profit Center  

Use

For internal accounting, you generally need to assign asset costs to cost centers. Therefore, you can assign each asset in Asset Accounting to exactly one cost center. You make this assignment in the asset master record. At the level of the cost center, you can then

• Post all depreciation and interest for the asset (see System Settings for Depreciation Posting )

• Plan all future depreciation and interest (for primary cost planning, see Primary Cost Planning )

• Statistically post gain or loss from the sale of assets (see Additional Account Assignment ) 

  Structuring Fixed Assets  

Use

It is possible to structure fixed assets at several different levels in the system:

• Balance Sheet Level

• Classification Level 

• Asset-Related Level

Structuring of Fixed Assets

  Functions of the Asset Class  

Use

Asset classes are the most important means of structuring fixed assets. You can define an unlimited number of asset classes in the system. You use the asset classes to structure your assets according to the requirements of your enterprise. Asset classes apply in all company codes. The asset class catalog, therefore, is relevant in all company codes in a client. The preceding is also true when the company codes have different charts of depreciation and therefore different depreciation areas. 

  Asset Types (General)  

Use

Fixed assets as a whole is made up of a variety of different types of assets. The balance sheet represents this variety using the balance sheet items

• Intangible assets

• Fixed assets

• Financial a ssets 

It is generally desirable to provide for a more detailed classification of assets according to asset types. The FI-AA component does not provide predefined asset types. There is no object or control indicator in the system called asset type.

Every asset type is represented by one or more asset classes that you define. These asset classes contain certain control indicators. The asset class can serve as a kind of sample master record for the assets in that class. Generally, all the asset classes for an asset type will use the same

• Account Determination 

• Screen Layout Control

 Assets under Construction  

Use

Assets under construction are a special form of tangible assets. They are usually displayed as a separate balance sheet item and therefore need a separate account determination in their asset classes. 

  Low-Value Assets (LVA)  

Use

In general, LVAs are fully depreciated in the year of purchase or in the period of acquisition. This can be achieved by using the special depreciation key GWG and the expected useful life of 1 month (period). In order to ensure that depreciation is fully posted in the acquisition month during the monthly depreciation posting, activate the catch-up method for the depreciation posting run (see System Settings for Depreciation Posting). 

  Leased Assets  

Use

Leased assets create special accounting requirements for the lessee. During the term of the lease, leased assets remain the property of the lessor or manufacturer. They represent, therefore, a special form of rented asset. Such assets are legally and from a tax perspective the responsibility of the lessor, and are not relevant for assessing the value of the asset portfolio of the lessee. However, in certain countries, you are nonetheless required to capitalize leased assets, depending on the type of financing. 

  Intangible Assets  

Use

You can manage intangible assets, such as patents, the same as tangible assets in the system. There are no special system functions for handling the needs of intangible assets. 

 

  Financial Assets  

Use

The SAP R/3 Treasury (TR) component offers special functions for managing financial assets. 

  Technical Assets  

Use

Technical data can only be managed to a limited extent in the asset master record. 

  Real Estate  

Use

The FI-AA Asset Accounting component is not intended for rental contract management of residential buildings, or detailed land register management for real estate. For these types of activities, use the SAP R/3 Real Estate (IM-RE) component. 

  Representing Fixed Assets  

Use

The term "asset" is used for simple assets, as well as for complex large-scale assets that consist of a number of component assets. The data structure of the system, with a 12 character alpha-numeric main asset number and a 4 character sub-number, allows both. The main asset number represents the asset as a whole. Parts of assets can be represented by different sub-numbers. 

   Simple Asset  

Use

A simple asset is represented by only one asset master record. This master record has sub-number "0000". Subsequent acquisitions are posted to this master record. You can meet the most essential business and legal demands with year segments (provided they have not yet been reorganized) and transaction data. 

  Group Assets  

Use

In the FI-AA component, the calculation and posting of depreciation generally takes place at the level of the individual asset. The system is fundamentally conceived so that depreciation is calculated for each main number or sub-number. To meet certain tax reporting requirements (such as ADR in the United States), which require depreciation at a higher level than the individual asset (for example, all assets in a given class in a given vintage year).

 

   Technical Structuring for Plant Maintenance Purposes  

Use

The structuring of assets from a bookkeeping perspective in the Asset Accounting (FI-AA) component is independent of the technically-oriented structure in the Plant Maintenance (PM) component. The PM component has its own structural organization (functional locations, equipment). This structure enables you to organize fixed assets according to maintenance requirements (in Plant Maintenance, refer to Technical Objects (Fixed Asset Structuring)).

  Basic Functions for Asset Valuation  

Use

The component "Basic Function for Asset Valuation" is used to determine the values of all fixed assets at a given point in time, based on the demands of governmental authorities, or based on your own rules that meet your individual needs.

  Depreciation Areas  

Use

You use depreciation areas to calculate different values in parallel for each fixed asset for different purposes. For example, you may require different types of values for the balance sheet than for cost accounting or tax purposes. You manage the depreciation terms and values necessary for this valuation in the depreciation areas of each asset. Since the system allows you to define up to 99 depreciation areas, you can manage many different types of valuation (Customizing: Valuation). Depreciation areas are grouped together, according to the requirements of a specific country or economic area, into a chart of depreciation (refer to Chart of Depreciation). 

 Features of a Depreciation Area  

Use

The depreciation areas in a chart of depreciation have no automatically defined features. You determine the features of each area individually, based on the basic structure, which is the same for all depreciation areas. You can make specifications for the following levels for each depreciation area:

• At the chart of depreciation level (see Features at Chart of Depreciation Level)

• At the company code level (see Company Code-Related Features)

• For legacy data transfer (see Legacy Data Transfer )

  Subsequent Creation/Deletion of a Depreciation Area  

Use

It is recommended that you define all the depreciation areas you might need before the production start of the system. Creating a new depreciation area after the production start can really only represent a compromise. 

 Showing Investment Support on the Assets/Liabilities Side of the Balance Sheet  

Use

Representing investment support measures in the balance sheet is analogous to the representation of special reserves for tax depreciation. To show investment support on the liabilities side of the balance sheet, you need depreciation area 51. For each investment support measure, you need to specify the liability accounts that will be posted. 

If you treat the support measure as a reduction of the APC on the assets side of the balance sheet, you do not necessarily need a separate depreciation area. You can deduct the investment support measure from the acquisition and production costs in any depreciation area. However, if you manage more than one investment support measure for a given asset, and you want to display the values separately, use a separate depreciation area for each additional support measure. Depreciation area 41 is defined explicitly for the management of support measures handled as reduction of APC. 

For more information, see Special Valuation.

  Parallel Currencies in the General Ledger  

Use

You can use the FI general ledger function described below, if you do not need valuation parameters (APC/depreciation terms) for the group consolidation that are different from the local valuation, but only need amounts in a foreign currency. 

The R/3 FI (Financial Accounting) component enables you to manage all values in one company code, on the same accounts, in up to two additional parallel currencies. In order to do this, you can define two parallel currencies for each company code in FI Customizing. Make the following specifications for each parallel currency: 

• Currency type, according to the function of the currency (for example, group currency) 

• Exchange rate type for the currency translation 

• Source currency for the currency translation 

• Date (for example, the document date) for the currency translation

It is also possible to update values that are posted in Asset Accounting in parallel currencies. The asset values can be updated in Financial Accounting in parallel in several currencies in the same FI document as the amount posted in local currency. 

  Integration (General)  

Use

The FI-AA component is integrated in numerous ways with other R/3 components. The integration of Asset Accounting with the FI (Financial Accounting, including Accounts Payable and Accounts Receivable) component makes it possible to carry out

• Posting of asset acquisitions and retirements that are integrated with accounts payable and accounts receivable 

• Account assignment of down payments to assets when you post down payments in the Financial Accounting (FI) component 

• Posting of depreciation from Asset Accounting to the appropriate general ledger accounts

In addition, the integration with certain components allows you to make account assignment to assets from transactions that have to do with assets. These components are:

• These components are: MM (Materials Management) and 

• PM (Plant Maintenance)

  Account Determination  

Use

Using the FI-AA component, you can automatically update all relevant transactions to the general ledger. These include all accounting transactions that are posted to assets, and all changes to asset values that are automatically calculated by the system (particularly depreciation). This update takes place immediately online for one depreciation area, or as part of periodic processing for all other depreciation areas. (refer to Updating Values in the Depreciation Area ). 

  Additional Account Assignment  

Use

If you use Asset Accounting in conjunction with cost accounting and/or FI General Ledger, the following additional account assignments are possible, depending on the business transaction to be posted:

• Business area

• Cost Center/Internal Order 

• Real estate object 

• WBS element

• Profit Center

• Funds center/financial budget item (see Budget Monitoring Using Statistical Orders or WBS Elements)

For more information on additional account assignments in fund accounting, refer to the "Fund Accounting" section.

  Fund Accounting  

Use

For public administration agencies, fund accounting is sometimes the foundation for financial accounting and reporting. Using this function, you can perform all activities — creating external financial statements, including balance sheets, profit and loss statements and cash flow statements — based on funds while meeting requirements such as US GAAP.

Fund accounting is supported in the SAP System in Controlling (CO), the General Ledger (FI-GL) and various subsidiary ledgers. This simplifies reporting on financial activities that fulfills a number of different requirements.

In Asset Accounting, when you post to fixed assets, you can automatically post to account assignment objects of fund accounting (funds, functions and grants) at the same time. In all reports, you can restrict selections to specific account assignment objects.

  Automatic Posting from Depreciation Areas to the General Ledger  

Use

Depending on the specifications in the chart of depreciation and in the asset class, you can manage any number of depreciation areas per asset in the FI-AA component (see Depreciation Areas). Often you are required to post all of these different parallel asset valuations to the general ledger, in order to have these parallel values available at the general ledger level. 

 Posting Depreciation  

Use

Every asset transaction in the R/3 Asset Accounting (FI-AA) component immediately causes a change of the forecasted depreciation. However, it does not immediately cause an update of the depreciation and value adjustment accounts for the balance sheet and profit and loss statements. The planned depreciation is posted to the general ledger when you run the periodic depreciation posting run. This posting run posts the planned depreciation for each posting level for each individual asset as a lump sum amount.  

When the system posts depreciation, it creates collective documents. It does not create separate documents for each asset. 

  System Settings for Posting Depreciation  

Use

The following is a detailed description of the possible Customizing settings for posting depreciation. (Implementation Guide: Integration with the General Ledger.)

  Depreciation Types  

Use

You specify the depreciation types and valuation types allowed for each depreciation area in FI-AA Customizing (Depreciation). The system then issues an error message and rejects posting when you try to use a type of depreciation 

that is not explicitly allowed.

  Valuation Methods  

Use

In FI-AA Customizing, you can define your own calculation methods for the valuation of fixed assets (Depreciation  Valuation Methods  Depreciation Key  Calculation Methods). These calculation methods are not hard-coded in the system. They are based on a number of flexibly-definable calculation keys. By defining your own calculation methods and control parameters, you can represent your specific depreciation methods in the system. 

There are pre-defined calculation methods and parameters in the system for the most commonly used depreciation methods.

  Depreciation Keys  

Use

The depreciation key contains the value settings which are necessary for determining depreciation amounts. It represents a combination of calculation rules, which are used for the automatically calculated depreciation types

• Ordinary depreciation

• Special depreciation

• Imputed interest

  Changeover Method  

Use

Certain depreciation methods necessitate a changeover to another calculation method for mathematical reasons in order to depreciate the asset completely within the period of use. An example is the declining-balance method of depreciation, which never results in a net book value of zero. Apart from this, there may be legal regulations that allow or necessitate the changeover to another method.

Therefore, when you assign calculation methods to a depreciation key, you can enter a changeover method. The changeover method specifies when the system should change over to a different calculation method (for example, Changeover when net book value percentage is reached). The changeover method also specifies the conditions under which the changeover takes place. You can also enter a net book value percentage for certain changeover methods.

You can divide the duration of depreciation into several phases in the depreciation key. If you enter a changeover method for one of these phases, the system changes over to the next phase as soon as the event defined in the changeover method occurs. Then the system uses the type of depreciation calculation that is specified for that next phase. 

  Other Features of Depreciation Key  

Use

The depreciation key offers further settings for depreciation calculation, in addition to the settings already discussed.

  Calculation Methods (Control Functions)  

Use

The system uses calculation methods for the calculation of depreciation and imputed interest. You assign calculation methods to depreciation keys. The calculation methods provide the parameters for the depreciation calculation program.

The calculation of depreciation is controlled by the calculation methods, the control parameters that are entered in depreciation keys, and the cutoff value keys.

  Scrap Value  

Use

It may sometimes be necessary to depreciate assets not to net book value zero, but only up to a scrap value or cutoff value. Therefore, the system enables you to set up a scrap value for assets per depreciation area. There are two ways of defining a scrap value: 

• By assigning a scrap value key to the depreciation key used in the depreciation area 

• By explicitly entering an absolute scrap value in the asset master data for the depreciation area 

  Depreciation Methods  

Use

The depreciation keys, with their calculation methods and parameters, let you represent the most varied depreciation methods in the system. The following describes the most important of these depreciation methods, and how they are handled in the system.

Standard keys exist in the system for the depreciation methods listed. Examples of depreciation keys for depreciation common in Europe are provided. 

 

  Straight-Line Depreciation over Total Useful Life  

Use

The asset is depreciated uniformly over the specified total useful life. Post-capitalization and subsequent acquisitions necessitate an increase in depreciation, by the amount which would have been necessary to fully depreciate the addition over the original useful life of the asset. This results in an increase in the length of time necessary to depreciate the asset, that is, the time period from the beginning of depreciation until the book value of zero is reached. 

Calculation : 

Depreciation = APC / expected useful life

APC: 1000 

Useful life: 10 

Depreciation = 1000 / 10 = 100

A depreciation key, which determines a percentage rate from expected useful life and uses the acquisition value or replacement value as the base value for depreciation, characterizes this depreciation method. Furthermore, certain depreciation keys (in their base method) allow depreciation below book value zero after the planned life has expired. 

In this case, the rate of depreciation can decrease after the planned life because you can then use the already expired useful life instead of the planned expected useful life to calculate depreciation. In the 11th year of use, you would not calculate with 10% as in the preceding 10 years, but only with 1/11 = 9.0909%. 

 

  Straight-Line from the Book Value over Remaining Useful Life  

Use

The book value of the fixed asset is distributed in uniform amounts over the remaining life. However, unlike straight-line depreciation over the total useful life, this method ensures that post-capitalization and subsequent acquisitions do not lead to an extension of expected useful life. Post-capitalization or subsequent acquisitions after the expiration of the specified expected useful life do, however, cause problems in this depreciation method. In such cases, the changeover key in the depreciation key used has to provide for another method after the expiration of the expected useful life. 

Calculation : 

Depreciation = net book value / remaining life

APC: 1000 

Useful life: 10 

Net book value: 500 

Remaining useful life: 5 

Depreciation = 500 / 5 = 100

You can represent this depreciation method in the system, for example, with a depreciation key that calculates a depreciation percentage rate from the remaining life, due to the depreciation calculation method Percentage from the useful life being set in its base method, and the Rem. life indicator being set in the multi-level method. Furthermore, the base value indicator "24" in the multi-level method ensures that the net book value is the basis for depreciation. The net book value and the remaining life are related proportionally, which results in straight-line depreciation. In the event of acquisitions after the expiration of the expected useful life, the depreciation key switches to a new phase after the planned end of useful life. The new phase is set up for straight-line/remaining life/pro rata/to zero/to end of life. As a result, these subsequent acquisitions are also depreciated completely.

 

  Declining-Balance Method of Depreciation  

Use

For the declining-balance method of depreciation, the fixed asset is depreciated by a progressively falling rate. A constant percentage rate is calculated from the expected useful life and a given multiplication factor. This is multiplied with the falling net book value of the fixed asset. For mathematical reasons, the net book value will never reach zero using this method. You change over to straight-line or complete depreciation under these conditions:

• Declining-balance depreciation < straight-line depreciation 

• Net book value < x percent of acquisition value 

• Net book value < fixed amount 

• Net book value < straight-line depreciation

The changeover method is specified in the internal calculation key. 

Calculation : 

Depreciation = net book value * percentage rate from expected useful life and factor

APC: 1000

Exp. useful life: 10

Net book value: 700

Multiplication factor: 3

Depreciation = 700 * (100% / 10 * 3) = 210

  Declining Multi-Phase Depreciation  

Use

By specifying the rate of depreciation and the validity period, you can determine a course of depreciation that changes in levels over time (usually decreasing). The validity period can be based, among other things, either on the capitalization date or on the depreciation start date. The change between the levels of depreciation does not have to take place at the start or end of a fiscal year. You can also change to another rate of depreciation during the fiscal year. 

Calculation : 

Depreciation = Acquisition value * percentage rate of the level

APC: 1000 

useful life: 50

Percentage rate year 1-8: 5.00%

Percentage rate year 9-14: 2,50%

Percentage rate year 15-50: 1.25%

 

Depreciation level 1 = 1000 * 5.00% = 50 

Depreciation level 2 = 1000 * 2.50% = 25 

Depreciation level 3 = 1000 * 1.25% = 12.5

 

When you define the depreciation levels in the system, you have to enter the period of validity for the individual depreciation levels as cumulative values (see Multi-Level Depreciation).

  Sum-of-the-Years-Digits Method of Depreciation  

Use

For each year of the expected useful life, the system notes the remaining useful life for the assets and totals the figures in each year. In each fiscal year, the remaining life is divided by this total in order to calculate the depreciation percentage rate for that fiscal year. This method leads to depreciation amounts that are reduced progressively by the same amount each period. 

Since the remaining useful life is no longer defined after the end of the planned useful life, this depreciation method does not allow for depreciation after the end of the planned life. However, you can change to another method after the expected useful life has expired. 

Acquisitions after the depreciation start year or post-capitalization will necessarily lead to a positive net book value at the end of planned life. For this reason, such transactions are not allowed when using the sum-of-the-years-digits method of depreciation. With this method, you have to handle subsequent acquisitions by creating sub-numbers. It is also a requirement that the acquisition year is the same as the depreciation start year.

Calculation : 

Depreciation = APC * remaining useful life (current period) / total of remaining useful life (over entire useful life)

APC: 1000 

useful life: 4

Total remaining useful life: 10 (= 4 + 3 +2 +1) 

 

Depreciation 1st year = 1000 * 4 / 10 = 400 

Depreciation 2nd year = 1000 * 3 / 10 = 300 

Depreciation 3rd year = 1000 * 2 / 10 = 200 

Depreciation 4th year = 1000 * 1 / 10 = 100

 Mean Value Method  

Use

You can manage the mean value of two depreciation methods in a derived depreciation area that links the values of the two depreciation areas. In order to do so, you have to identify the derived depreciation area as a mean value area. Instead of using the arithmetic mean, you can also link the areas proportionally.

Linking formula for the mean value:

Depreciation = (depreciation in area 1) / 2 + (depreciation in area 2) / 2

Depreciation in area 1: 300 

Depreciation in area 2: 100 

Formula: (depreciation in area 1) / 2 + (depreciation in area 2) / 2

Depreciation = 300 / 2 + 100 / 2 = 200

Depreciation for Multiple-Shift Operation and Shutdown  

Use

Increased depreciation is often calculated for assets that are used in multiple shifts. Often no depreciation is calculated for assets that are shut down. The following fields are provided for these instances in the asset master record: 

• Multiple-shift factor (time-dependent)

• Variable portion of depreciation (dependent on depreciation area)

• Shutdown indicator (time-dependent)

 

  Unit-of-Production Method of Depreciation  

Use

Unit-of-production depreciation is useful for certain types of assets. This depreciation method allows you to take fluctuations in activity into account for the depreciation calculation by linking the amount of depreciation in the given period directly to the output quantity. 

  Special Valuation  

Purpose

The Special Valuation component makes it possible to calculate asset values for specialized purposes, such as for insurance contracts.

 

  Replacement Values (General)  

Use

In addition to the historical acquisition and production costs of an asset, the Asset Accounting component enables you to work with the replacement value of the asset, which can provide a more up-to-date basis for calculating values. When determining replacement value, the system offers two options:

 Investment Support Measures  

Use

The "investment support" component is for managing government subsidies for certain types of investment. The subsidy can be managed as a reduction of acquisition and production costs, or as a value adjustment. The subsidy amount normally has to be identified separately from the actual acquisition and production costs of the asset.

This investment support is treated either as a reduction of the acquisition and production costs of the asset, or as a value adjustment on the liabilities side of the balance sheet. 

 Special Reserves  

Purpose

In many countries, you are allowed to use tax depreciation rates for book depreciation. However, the person reading the balance sheet should still be able to recognize that a different approach was used. For this purpose, book depreciation is carried out according to the appropriate requirements, and the depreciation allowed by tax law, which exceeds book depreciation, is shown as special reserves on the liabilities side of the balance sheet.

The "special reserves" component allows you to show the difference between book depreciation and tax depreciation in a derived depreciation area. You can use the values from this derived depreciation area to create special depreciation reserves for the balance sheet.

This kind of special reserve is common in Germany. 

   Transferred Reserves (Deferred Gain)  

Purpose

The "transferred reserves" component allows all or a part of the undisclosed reserves that arise from the sale of assets to be transferred to replacement assets. The gains from the sale thereby reduce the depreciation base for the newly acquired assets. Or you can show them as special reserves on the liabilities side of the balance sheet. 

If such reserves are not transferred in the year in which they arise, because there are no appropriate new acquisitions, then a reserve can be created. In this way the gain from the sale of the asset does not count as profit. This reserve usually must be transferred within the following (two) years to new assets acquired during this time period. 

 Leased Assets  

Purpose

Leased assets create special accounting requirements for the lessee. During the term of the lease, leased assets remain the property of the lessor or manufacturer. They represent, therefore, a special form of rented asset. Such assets are legally and from a tax perspective the responsibility of the lessor, and are not relevant for assessing the value of the asset portfolio of the lessee. However, in certain countries, you are nonetheless required to capitalize leased assets, depending on the type of financing. 

The Leased Assets component enables you to capitalize leased assets in the Asset Accounting (FI-AA) component using the capital lease method. The system calculates the acquisition value from the present value of the future lease payments in the leasing agreement. 

  Net Worth Tax  

Purpose

The net worth tax laws in many countries require a separate valuation of assets. The "net worth tax" component helps you to valuate assets for this purpose. You can use the values the system calculates in determining your net worth tax burden.

 Requirements for Consolidation  

Purpose

The "requirements for consolidation" component assists you in preparing the for the legal consolidation of a corporate group as relates to fixed assets, using the data in asset accounting.

   Master Data Maintenance  

Purpose

The "master data maintenance" component is used for recording the master data of your fixed assets on an individual asset basis. A fixed asset is defined as an individual economic good that it is recognized in the balance sheet at the time of closing, and is in the long-term service of the enterprise.

The list below shows some of the functions provided for assisting with master data maintenance:

• Control of the screen layout 

• Validation or substitution of entries 

• Mass changes to master record fields

  The Asset Master Record  

Use

The varied demands on master data management for Asset Accounting are met in the R/3 FI-AA component by

• Asset master records that are structured according to functional and goal-oriented requirements 

• Master data maintenance that is organized according to this structure, and allows for individual adaptation 

  Number Assignment  

Use

The asset number uniquely identifies a fixed asset. It always consists of the main asset number and the asset sub-number. There are two ways of carrying out number assignment in the system: 

• External number assignment 

• Internal number assignment

In the case of external number assignment, the user directly assigns the asset number. The system displays only the defined number interval, and issues an error message if a number is already assigned. In the case of internal number assignment, the system automatically assigns consecutive numbers. 

Do not use hyphens or the asterisk (*) symbol with external number assignment.

  Screen Layout, Maintenance Level, Tab Layout for Master Data  

Use

The asset master record in the FI-AA component has a large number of fields in order to meet the needs of its many functions. To make master data maintenance nonetheless as simple and efficient as possible, the following Customizing functions enable you to design the asset master record to best suit your needs.

• Specification of field characteristics (required entry, optional entry, suppressed) and the maintenance level (asset class/main number/sub-number) for master data fields 

• Specification of the layout of the tab pages in the master record

  Time-Dependent Data  

Use

Certain assignments during the life cycle of an asset change frequently, and therefore a record should be kept of the changes, both for reporting and for valuation needs. Examples are the assignment of an asset to a cost center, or multiple-shift usage of an asset during a certain time period. 

  Validation and Substitution  

Use

In order to provide your own customized assistance for asset master data maintenance, the system enables you to define your own validation and substitution rules. You make these specifications in FI-AA Customizing (Define validation/Define substitution).  

  Basic Functions of Transactions  

Purpose

The "transactions" component enables you to carry out all accounting transactions that occur during the life of a fixed asset in your organization.

   Transaction Types  

Use

Within Asset Accounting, asset transaction types identify individual business transactions. A transaction type has to be entered for each transaction that affects assets. Either you make this entry yourself in the posting transaction, or the entry is automatic, based on specifications made in FI-AA Customizing (Transactions).

  Line Items  

Use

From the point of view of Asset Accounting, line items are a proof of how the values displayed for an asset came about. For each transaction, a line item is created for each depreciation area in which posting is to take place. This line item contains the transaction type, asset value date, posted amount, depreciation, and interest on a transaction as well as any proportional value adjustments. 

 Dates in Asset Accounting  

Use

In addition to the usual dates entered in Financial Accounting (posting date, document date), there are special dates to consider in Asset Accounting. Either you enter these additional asset accounting dates yourself, or the system determines them. 

   Posting Gain/Loss  

Use

When you post an asset retirement, you can enter the revenue from the sale of the asset. The system automatically determines the gain or loss (affecting income) as the difference between this revenue and the book value of the asset being retired. Since gain or loss from asset retirement does not occur regularly, they have only limited relevance for management accounting. Therefore the system posts gain or loss only as a statistic to the cost center. The actual account assignment to CO takes place to the profit center, which is assigned to the cost center (refer to Additional Account Assignment). 

  Manual Handling of Delivery Costs  

Use

You might have capitalization rules that are different from those in the book depreciation area for different calculation purposes (such as group consolidation). This may be useful, for example, for the capitalization of freight costs. You can use the transaction for posting asset acquisitions to enter different APC amounts in each depreciation area (function: Areas). The only requirement is that the depreciation area cannot have mandatory takeover of APC from another depreciation area (In Customizing for Asset Accounting, choose Specify Transfer of APC Values).

  Information System  

Purpose

The Information System component contains a series of standard reports, as well as functions for modifying the Asset Accounting Information System to meet your specific needs.Reports that encompass the entire fixed asset portfolio can have a negative influence on performance. Therefore, you have to start reports of this type using background processing (in the selection screen of the report: Program  Exec. in background). You can select a maximum of 1000 assets online.

Definition of the Asset History Sheet  

Use

The asset history sheet is the most important and most comprehensive report for the year-end closing or for an interim financial statement. As with all other lists, it can be set up with any sort versions, and total on any group level. You can also create a compact totals list without individual asset information. 

 Asset Information for Intranets (FI-AA)   

Use

Ongoing availability of basic accounting information on an enterprise’s fixed assets is of considerable importance, particularly for international corporations. This information may also be significant for employees who are not directly associated with the asset accounting department. For example, while traveling on business, an employee might want to know what kind of equipment is in use at the subsidiary he or she intends to visit (such as, company cars, telecommunication equipment). There may also be cost center managers who do not have direct access to R/3, but who need to conduct informal inquiries about the fixed assets in their area of responsibility.

The Internet Application Component Asset Information provides access via Intranet to the Information system of R/3 Asset Accounting. This solution offers quick and simple access to information on the fixed assets of an enterprise or subsidiary.

   Legacy Data Transfer  

Use

Legacy data transfer is the transfer of existing data from a previous system or from a manually maintained fixed asset card file. The transfer of legacy data is generally the first action after you configure the Asset Accounting (FI-AA) component and classify your assets. This task involves transferring asset master records and transactions from the start of the fiscal year up until you go live. Reconciling the balance sheet accounts takes place later in a separate step.

Below is a brief overview of the different methods for legacy data transfer. For more information, see the documentation for these functions.

  Process for Automatic Asset Data Transfer  

Purpose

The following process flow can be used for transferring fixed assets from a legacy system to the R/3 System.

  Legacy Data Transfer Using Microsoft Excel  

Use

Along with the Data Transfer Workbench, the SAP R/3 Asset Accounting component also offers the option of transferring legacy asset data using Microsoft Excel. This method is suited for transferring small datasets, such as a few hundred fixed assets. The system can process a maximum of 5000 rows. The amount of data you can transfer using this method is also limited by the maximum number of rows in your Excel version.

  Authorizations and Preparing for Production Startup  

Use

This section describes the authorizations in the system, along with measures that can be taken to increase system performance. 

  Asset Views  

Use

Along with the standard R/3 authorization functions, Asset Accounting uses a view concept for the protection of authorizations. Therefore, the Asset view authorization object has a special function. The asset view applies especially to employees, who have only occasional limited contact with fixed assets. The asset view allows such employees only a limited view of asset data and values, whether or not they formally have access to every master record. With the Insurance asset view , for example, a person responsible for insurance can be granted access only to the data that is relevant for insurance.

  Organizational Plan and Workflow  

Use

You can represent the organizational plan of an enterprise in the R/3 System by entering organizational units, plan positions, and positions. This organizational plan is used for employee management in the Personnel Development (PD) component.

  Customer Enhancements (Customer Exits)  

Use

The system enables you to make your own enhancements to certain standard functions. There are specific points in the standard program that are prepared by the system for calling up your own individually modified function modules. 

  Asset Master Data Maintenance  

Purpose

The following objects describe master data maintenance for fixed assets. 

 

  Creating Master Data  

Purpose

The asset master record contains all information relating to an asset that remains unchanged over a long period of time:

• Technical master data

• Organizational allocations (usually time-dependent)

• Depreciation terms

The system stores all the values and transaction data per each asset master record. 

You can differentiate between different types of assets in the FI-AA component. The structure of the master record is identical for all asset main numbers, asset sub-numbers and group assets. Therefore, the basic procedure for creating any of these objects is essentially the same.

  Changes to Master Data  

Purpose

Different types of changes to master data require different handling in the system. These different types are listed below:

• You want to change normal master record information and entries regarding valuation.

• You want to change time-dependent allocations to organizational units that are not relevant to the balance sheet (for example, plant). 

• You want to change time-dependent allocations to organizational units that are relevant to the balance sheet.

The organizational units that are relevant to the balance sheet in this context are business area and profit center. The system determines the profit center for the asset indirectly on the basis of the asset’s cost center. The cost center can also be assigned to a business area. Therefore, the cost center is in this sense also relevant to the balance sheet.

• You want to change the assignment of the asset to the asset class.

  Deactivation - Deletion - Blocking  

Purpose

The system supports the removal of an asset from the asset portfolio in the following manner: 

 Acquisitions  

Purpose

The primary business process in asset accounting is the purchase of assets and/or the capitalization of in-house produced goods or services. The Asset Accounting component supports various methods of handling this business process.

  External Asset Acquisitions  

Purpose

An external asset acquisition is a business transaction resulting from the acquisition of an asset from a business partner (in contrast to an acquisition from in-house production). You can post the acquisition of a purchased asset in several different ways, using different components of the R/3 System: 

• In Asset Accounting (FI-AA) in integration with Accounts Payable (FI-AP), but without reference to a purchase order

• In Asset Accounting, without reference to a purchase order, without integration with Accounts Payable (posting to a clearing account - with or without clearing).

• In Materials Management (MM) at goods receipt or invoice receipt (refer to Processing Asset Acquisitions in Purchasing (FI-AA/MM) and Goods Receipt and Invoice Receipt with Reference to Asset).

  Processing Asset Acquisitions in Purchasing (FI-AA/MM)  

Purpose

When you are using the FI-AA component in conjunction with the Materials Management (MM) component, you can post an asset acquisition within the framework of the ordering process in purchasing. 

  Goods Receipt and Invoice Receipt with Reference to Asset  

Purpose

You can post the goods receipt and the invoice receipt for an ordered asset with reference to the purchase order. 

Acquisition Posted in Purchasing

  Acquisition from Internal Activity  

Purpose

An acquisition from internal activity is the capitalization of goods or activities that are partly or completely created within your own company. 

  Processing a Goods Issue from the Warehouse  

Purpose

Under certain circumstances, you may use goods from the warehouse as replacement parts for existing assets. The value of these goods must then be capitalized to the respective asset. This is essentially a transfer from current assets to non-current assets. 

  Acquisition Resulting from Extraordinary Revenue  

Purpose

An ‘acquisition resulting from extraordinary revenue’ is an asset acquisition that is posted in Asset Accounting without any reference to a valuated goods receipt or invoice receipt. This type of transaction might be necessary because 

• A new fixed asset, requiring capitalization, was discovered during the course of a physical inventory 

• Your enterprise receives an asset as a gift 

  Subsequent Acquisition  

Purpose

A subsequent acquisition in this context is an addition or enhancement to a capitalized asset in the current fiscal year (not Posting Post-Capitalization). The depreciation start date for the enhancement should be in the current fiscal year.

 Manual Depreciation and Transferred Reserves  

Use

The following objects describe manual planning of depreciation and of transferred reserves. For more information on the automatic calculation of depreciation, refer to Depreciation. For more information on depreciation posting and updating, refer to Processing for Closing.

   Manual Planning of Depreciation  

Purpose

As a rule, the system automatically determines the planned depreciation for the current fiscal year by means of the depreciation keys entered in the master record. If you need to specifically set the amount of depreciation, the system offers a manual depreciation forecasting option. This means you can manually increase the planned values managed for the asset. You can generate manual depreciation amounts for all depreciation types, but it is more common to manually generate unplanned depreciation and the transfer of reserves. 

There are several different types of manual depreciation that can be differentiated according to the reason that manual depreciation is required:

• There is an unexpected permanent reduction in the worth of the asset that you have to post as unplanned depreciation. 

• You have special tax depreciation that you only partially take into account. 

• You are using unit-of-production depreciation and want to manually plan depreciation, rather than using the depreciation key.

  Reserves Resulting from Retirement Revenue  

Purpose

According to the tax legislation in many countries, it is possible to transfer the undisclosed reserves that arise from the sale of assets to replacement assets (refer to Transferred Reserves). The procedure is carried out in the following steps: 

• You sell assets, and post the resulting gain to the G/L account set up for reserves (allocation of the reserves). 

• You purchase assets to replace the assets that were sold. You transfer the reserve that was "parked" in the reserve account to the new assets. The reserve then reduces the basis for depreciation for the new assets, or is represented as a value adjustment on the liabilities side (special reserves). 

  Transfer of Reserves  

Purpose

You post the transfer of reserves in Asset Accounting using a transaction type of transaction type group 68 or 69. The system then automatically reduces the depreciation base by the transferred amount in the posted depreciation areas. As a prerequisite, you must have defined the depreciation areas concerned so that they can manage reserves. You determine, according to which depreciation area you post to, whether the transferred reserve should be handled as a reduction on the assets side, or as a value adjustment on the liabilities side (see Transferred Reserves). 

  Investment Support and Revaluation  

Use

The following objects describe how the system assists with claiming and processing investment support and with the revaluation of fixed assets for different purposes. 

  New Investment Support Measures  

Purpose

Investment support measures can be managed separately from actual acquisition and production costs in the system. They can be handled on the assets side as a reduction of APC, or on the liabilities side as special reserves. For either of these methods, you need to define the relevant investment support measure in the system. You might need to define a new investment support measure for one of two reasons: 

• You need to redefine an investment support measure that already exists. 

• You want to claim a certain kind of investment support for the first time. For more information, see the Implementation Guide under Define investment support measures.

  Posting Investment Support  

Use

Investment support measures are government subsidies that a company receives for particular types of investment. This investment support is treated either as a reduction of the acquisition and production costs of the asset, or as a value adjustment on the liabilities side of the balance sheet.

 Defining the Index Series  

Use

The FI-AA component uses index series for determining replacement values and insurable values (refer to Special Valuation). You define the index series in the system with the appropriate index figures.

  Definition and Execution of One-Time Revaluation  

Use

In certain countries, tax laws allow you to balance the affects of inflation by a one-time revaluation of the entire asset portfolio (refer to Management of Inflation). This revaluation is allowed at given intervals (usually several years). 

 Other Transactions During Life of an Asset  

Purpose

The following objects describe business transactions that can take place during the life of a fixed asset.

  Down Payments to Assets Under Construction  

Purpose

Down payments represent a type of acquisition to fixed assets which you generally need to capitalize and report in a separate balance sheet item. For this reason, down payment postings use separate, special transaction types in the SAP R/3 System. 

  Settlement of an Asset under Construction  

Purpose

An asset that you produce yourself has two stages in its life that are relevant for accounting from the point of view of your company:

• Under construction phase

• Useful life

Generally, an asset has to be shown in different balance sheet items, depending on the phase that it is in. Therefore, it is necessary to manage the asset as a separate object or asset master record during the construction phase. The transition between these two phases is called "capitalization of the asset under construction" in the following. 

  Credit Memos (Received)  

Purpose

A credit memo, which reduces the acquisition and production costs of an asset, essentially represents the opposite of an invoice for a purchased asset. Therefore, it is possible to post the credit memo, as you do when you post an external acquisition, either integrated with a vendor, or to a clearing account (refer to External Asset Acquisitions).

When credit memos are received for a fiscal year that is already closed, the system cannot correct the depreciation posted in the closed fiscal year. Therefore, you have to correct the depreciation for the closed fiscal year manually using a write-up before you can post the credit memo.

  Post-Capitalization (Write-Up to APC)  

Purpose

Post-capitalization, in this context, represents subsequent corrections to the acquisition and production costs of a fixed asset. An example of when you need this type of correction is if you neglected to add expenditures and costs linked with the acquisition or assembly of an asset to its APC in a fiscal year that is now closed. 

  Write-ups  

Purpose

A write-up is generally understood to be a later change to the valuation of an asset. This change can take different forms, depending on the reasons for the change. There are two common reasons for write-ups: 

• You forgot to capitalize an asset in a fiscal year that is now closed, and this omission must now be corrected (write-ups to APC are usually called post-capitalization). This procedure is described in detail in Post-Capitalization (Write-Up to APC). 

• The value adjustments (depreciation) that you calculated in the past were too high. You must now correct this error using a write-up in the current fiscal year. Excessive depreciation generally results from 

o The use of incorrect depreciation terms (incorrect expected useful life, incorrect depreciation key) 

o Unplanned depreciation, which is no longer valid in the current situation 

o A later reduction in the acquisition and production costs of an asset (for example, due to a subsequent credit memo)

  Asset Retirement  

Purpose

Asset retirement is the removal of an asset or part of an asset from the asset portfolio. This removal of an asset (or part of an asset) is posted from a bookkeeping perspective as an asset retirement. Depending on organizational considerations, or the business transaction which leads to the retirement, you can distinguish the following types of retirement:

• An asset is sold, resulting in revenue being earned. The sale is posted with a customer.

• An asset is sold, resulting in revenue being earned. The sale is posted against a clearing account.

• An asset has to be scrapped, with no revenue earned.

• An asset is sold to an affiliated company (refer to Manual Posting of Intercompany Asset Transfer/Retirement) 

   Subsequent Revenue/Costs  

Purpose

It is sometimes necessary to post revenue or costs for an asset retirement that has already been posted. For example, you might need to post an insurance benefit as subsequent revenue to an asset, although the asset has already been scrapped (deactivated). 

  Reversals  

Purpose

Asset transactions have to be reversed using the reversal transaction of the application in which the original transaction was posted (for example, invoice receipt). You automatically go to the appropriate reversal transaction when you choose Postings ® Reverse document. 

  Processing for Closing  

Purpose

The following objects describe tasks that are carried out during period-end closing or year-end closing in Asset Accounting, rather than on an individual basis. In addition, there are descriptions of certain tasks that are required for special valuation of assets (such as replacement values).

Schedule Manager

You can manage and monitor periodic processing in Asset Accounting using the Schedule Manager. Schedule Manager is a tool for planning and overseeing business tasks. This tool makes it easier to carry out periodic processing, and is able to help automate these processes where possible. Using Schedule Manager you can display the current status of the period-end closing.

You can use the Schedule Manager to manage the following periodic processing in Asset Accounting:

• Posting depreciation 

• Automatic posting of asset transactions from a depreciation area to the General Ledger

You find the Schedule Manager in the Asset Accounting menu (choose Periodic processing).

For more information on the Schedule Manager, see the SAP Library. Choose CA-Cross Application Components ® General Application Functions (CA-GTF) ® Schedule Manager.

   Update of Depreciation  

Purpose

Every asset transaction in the R/3 Asset Accounting (FI-AA) component immediately causes a change of the forecasted depreciation. However, it does not immediately cause an update of the depreciation and value adjustment accounts for the balance sheet and profit and loss statements. The planned depreciation is posted to the general ledger when you run the periodic depreciation posting run. This posting run posts the planned depreciation for each posting level for each individual asset as a lump sum amount.  

  Parallel Valuation  

Purpose

Alongside the posting of depreciation (using the depreciation posting run), the most important periodic processing you perform is the posting of changes to asset balance sheet values (APC values). These changes consist of all postings that affect the APC of the asset, including acquisitions, retirements, and so on.

You need to post changes to APC values from more than one depreciation area to the general ledger, if one of the following applies:

• You need to create different balance sheet versions, for example, for internal and external purposes. You can define any number of balance sheet versions per chart of accounts in FI (General Ledger) for this purpose. 

• You have a group depreciation area in a foreign currency, and you need to post changes to asset balance sheet values from this area to the ledger of the corporate group (see below). 

• You calculate special reserves for special depreciation in a derived depreciation area. (This is common in Germany in depreciation area 03 of the standard chart of depreciation.) 

• To meet the needs of parallel financial reporting, you have to create an additional balance sheet, for example according to IAS, in addition to your balance sheet according to your local accounting principles.

  Periodic Reports  

Purpose

There are a number of standard reports available for the analysis of asset transactions (see Information System). In most cases, it makes sense to bundle or to automate the creation of the reports for this type of analysis. 

 Physical Inventory  

Use

A physical inventory is the recording of the quantities and amounts relating to the asset portfolio. The FI-AA component provides the following functions to support the physical inventory:

   Fiscal Year Change  

Purpose

From the point of view of the system, a fiscal year change is the opening of a new fiscal year for a company code. At the fiscal year change, the asset values from the previous fiscal year are carried forward cumulatively into the new fiscal year. Once the fiscal year change takes place, you can post to assets using value dates in the new fiscal year. At the same time, you can continue to post in the previous fiscal year. You find the fiscal year change program under Periodic processing.

  Year-End Closing  

Purpose

The year-end closing is an annual balance sheet, an annual profit and loss statement, and an appendix with additional information (annual report), which has to be created to meet the particular legal obligations in each country. Before you can close a fiscal year in Financial Accounting from a bookkeeping perspective, you have to carry out preparatory measures in Asset Accounting. 

  Primary Cost Planning  

Purpose

For primary cost planning related to cost center accounting, you need to forecast future depreciation. Therefore, you can determine planned periodic depreciation and interest for any Asset Accounting depreciation area. The depreciation area has to be a real depreciation area, not a derived depreciation area. Using a special report (Periodic Processing), you can transfer this depreciation and interest to the Controlling (CO) component. There is an indicator in the report request screen you use to specify if planning should take place on cost centers or on orders.

  Simulation  

Purpose

Simulation is the experimental changing of the depreciation parameters for all assets or for certain assets. When simulating the value development of assets, you can vary all of the important depreciation terms (depreciation key, useful life, index series). There are several different approaches that you can use: 

• Simulation of values for a single asset by changing the depreciation parameters using the asset value display transaction There are two main parameters that you can change: 

o Depreciation terms (depreciation key, useful life, and so on) 

o Transactions

• Simulation of depreciation for future fiscal years for groups of assets with the help of a special simulation report and a simulation version (refer to Simulation Version). 

• Simulation of the accumulated depreciation from the past using a new depreciation area. 

In addition, it is possible to include planned capital investments (orders/projects and capital investment programs) in the simulation.

Tools  

Purpose

You find the following activities in the FI-AA menu under Tools: 

   Processing Incomplete Assets  

Use

Incomplete assets are assets that have been entered in the system, but in which important master data was not entered (primarily account assignment information and required entries). This kind of asset could have been entered under one of these circumstances:

• When an investment measure is created, the system automatically creates an asset under construction. For some reason, the system could not automatically supply all the necessary default values for the asset under construction (refer to: Investment Management).

• When creating an asset from another component, either from within a purchase order or from the settlement rules of orders or WBS elements, assets were not entered with all of the necessary information. 

• The incomplete asset was entered using an asset view that allows only limited access to asset master records (see Master Data Maintenance with Asset Views).

Degree of Completeness

An asset can be considered complete to the degree listed below. The possible levels of completeness are: 

• The asset is complete (all required fields defined in the screen layout are maintained).

• The asset is incomplete, but can be posted (all account assignment information is complete).

• The asset is incomplete and cannot be posted.

Limitations on Incomplete Assets

You must complete any incomplete assets. Incomplete assets are therefore subject to these limitations:

• You cannot retire an incomplete asset (retirement posting is not possible). 

• You cannot close the fiscal year in Asset Accounting for the company code in which incomplete assets are found. 

• The system does not post depreciation for incomplete assets. 

You can post acquisitions to incomplete assets. However, either the business area must have been entered in the asset, or else your enterprise does not create business area balance sheets (according to the definition in the FI General Ledger). 

You can define your own checks for posting to incomplete assets by using validations (see Validation). 

  G/L Reconciliation  

Purpose

A reconciliation report (found under Tools) identifies inconsistencies between Asset Accounting line items and the balances of the various asset reconciliation accounts (for a specific account). This report can be used if differences occur between the general ledger balance list and the values shown in the asset history sheet. There two steps to the data analysis: 

1. First the report compares the totaled line items and the calculated totals for each asset with the totals updated on this asset. 

2. If no inconsistencies are found, the system then runs a comparison on document level. Asset line items created for each document number are totaled, and this total is compared with the total of document line items posted to this asset. 

  Processing Leased Assets  

Purpose

The "Leased Assets" scenario describes the management of leased assets from the standpoint of the lessee.

Leased assets create special accounting requirements for the lessee, as compared to assets that an enterprise purchases or produces itself. During the term of the lease, leased assets remain the property of the lessor or manufacturer. They represent, therefore, a special form of rented asset. Such assets are legally and from a tax perspective the responsibility of the lessor, and are not relevant for assessing the value of the asset portfolio of the lessee. However, in certain countries, you are nonetheless required to capitalize leased assets, depending on the type of financing. 

This scenario makes it possible to handle different types of leased assets differently. Depending on legal restrictions, you can capitalize and depreciate leased assets (capital lease) or post their rent expense periodically to the profit and loss statement (operating lease).

The following objects describe the most important business transactions in the life of a leased asset from the lessee's point of view. Special functions are being developed for transferring leased assets.

For further information on how to handle leased assets, see Leased Assets.

  Acquisition of Leased Assets  

Purpose

The "acquisition of a leased asset" is considered for our purposes to be the entry of the leased asset in the FI-AA System. This does not necessarily mean that the leased asset must be capitalized. You can enter a leased asset simply to manage purely statistical data. You handle the leased asset as a master record, with no values in the book or tax depreciation areas. 

Posting the acquisition of a leased asset may be necessary for one of the following reasons: 

• You have received a new leased asset (goods receipt). 

• You need to change the way bookkeeping is handled for a leased asset due to a change in the conditions of the lease. 

• You need to post a leased asset to a new asset master record due to a transfer. 

  Lease Payments  

Purpose

Regardless of whether the lease is treated as a capital lease or an operating lease, you are required to pay the periodic lease payments to the lessor (vendor). In the case of a capital lease, the corresponding liabilities are created within the framework of the opening posting. The offsetting account for the posting to the vendor is the asset control account.

For leased assets that are not capitalized, you need to create an appropriate recurring document.

  Asset Retirement for Leased Assets  

Purpose

A leased asset can be retired for one of the following reasons: 

• The lease expired or was canceled ahead of time. 

• The leased asset had to be scrapped. 

Change in the Conditions of the Lease

There are two different cases that affect assets: 

• The changes in the conditions of the lease allow for changing an asset that was capitalized (capital lease) to non-capitalized (operating lease). 

• The asset remains capitalized, but the payment conditions make a new valuation of the leased asset necessary. 

  Travel Management (FI-TV)  

Purpose

SAP Travel Management accompanies all the processes involved in handling trips. It provides integrated functions and links these to the settlement, taxation and payment processes. Travel management covers the request, planning and booking of trips, as well as the settlement of travel expenses and the transfer of settlement results to other business function areas. The integration of SAP Travel Management guarantees the benefits of synergies that increase efficiency and reduce process costs.

  The Overall Process of Travel Management  

Purpose

The goal of this process is the complete, integrated management of all processes involved in a business trip and the travel expenses incurred. The process includes the entire procedure of requesting and planning a trip, accounting the travel expenses and the correct taxation in Payroll Accounting (HR), correct posting of the travel expenses in Financial Accounting (FI), and clearing in Controlling (CO) or Funds Management (FI-FM) according to the allocation-by-cause principle.

 Roles in Travel Management  

Use

Beginning with Release 4.6 roles (single or composite roles) are available in SAP Travel Management that cover the most important tasks of the employees involved in processing trip data. By assigning a role to a user you ensure that the user can use a purely task and function based method of working in the R/3 System.

The roles in SAP Travel Management support both the decentralized and central organization of the trip process, as well as a mixture of the two with the focus on decentralization.

For the decentralized organization the travelers are responsible for entering their own travel requests, travel plans and travel expenses in the system. For a mixed or central organization these tasks are carried out by a travel assistant on behalf of several travelers. The role of the travel administrator allows the settlement of travel expenses to be organized centrally, whereby the settlements are entered and checked centrally.

You can adjust the roles defined as standard to meet your individual requirements. You can also create new roles.

The following roles are defined as standard for SAP Travel Management:

Traveler

SAP_FI_TV_TRAVELER

Travel assistant 

SAP_FI_TV_TRAVEL_ASSISTANT

Travel administrator

SAP_FI_TV_ADMINISTRATOR

Approving manager

SAP_FI_TV_MANAGER_GENERIC

Payer of trip advances

SAP_FI_TV_ADVANCE_PAYER

Travel manager

SAP_FI_TV_TRAVEL_MANAGER

Travel Manager: Cross-Process Entry  

Use

The Travel Manager, with its simple and intuitive handling, is directed at occasional users who want to process their own trips or to employees that have a few travelers assigned to them. The Travel Manager covers all the process steps in Travel Management in a single transaction with a uniform interface design. 

You can use the Travel Manager (depending on your enterprise-specific Customizing settings) to complete the following tasks:

• Create a Travel Request 

• Create and Book Travel Services 

• Create a Travel Expense Statements 

• Display an Overview of All Trips

  Travel Requests  

Use

The travel request process in SAP Travel Management includes the system-aided handling of the request and approval process for business trips. Paper forms are replaced by an electronic request that can be sent from the R/3 System to the respective manager for approval.

You can call up the travel request object at any time from the overview area of the Travel Manager. You can, therefore, always keep track of the approval status and the approved trip details, and view them at a later date (for example, to compare the facts with the corresponding travel expenses statement).

As you can enter the type and number of transportation and accommodation services required for the trip in the travel request, this can (if the travel does not have the authorization for booking) be used as a reference for booking a trip. The travel agency or area secretary with the necessary booking authorization, can arrange the necessary travel services using Travel Planning in SAP Travel Management based on the travel request.

  Travel Planning (FI-TV-PL)  

Purpose

Travel expenses are one of the largest personnel-related cost factors and offer great cost-saving potential.

The R/3 component Travel Management - Travel Planning with its connected online booking service contributes greatly towards reducing your trip process costs. Using Travel Planning you can reduce the instances involved in the planning and booking process of a trip, simplify the process itself and automatically include enterprise-specific travel policies. It also improves the transparency of the costs and the cost-incurring areas/employees.

The use of Travel Planning provides an important strategic advantage for the role of the travel manager in your enterprise. The business volume statistics and reporting tools in Travel Planning deliver concrete arguments for rate negotiations with service providers. The travel manager is relieved of routine tasks and can therefore concentrate on more strategically important tasks, such as system and quality management and the control and optimization of internal enterprise processes.

Travel Planning also extends the employee responsibility. The functions are not only designed for experts who use the system on a daily basis to book travel services, they are designed particularly to assist the occasional users. Such occasional users could be, for example, the travelers themselves or the area secretaries who have to deal with the organization of trips for several travelers.

Cost advantages are also made due to the link between Travel Planning and SAP Business Workflow, using which the approval processes can be defined uniquely and the complex approval procedure implemented successfully.

  Travel Expenses  

Purpose

The Travel Expenses function allows you to settle the travel expenses incurred by employees taking business trips simply and efficiently. The process of reimbursing the expenses to the employee is also improved.

Depending on the organization model of your company, the expense receipts are entered, checked, and settled centrally by the expenses department, or (in the decentralized model) the travelers enter the data themselves with a central monitoring of the trip facts and information.

Depending upon the individual demands of your task structure or your country specifications, the employees can choose from a range of different entry scenarios. 

  Transfer to HR Payroll   

Purpose

If Travel Management is integrated with HR Payroll, the travel expense results can be transferred from Travel Management and taken into consideration in Payroll. The transfer makes it possible to carry out payment of travel expenses via payroll. 

Regardless of whether payment is to be performed via payroll, transfer is necessary if an enterprise gives its employees payment in kind in the form of meals, for example, or reimbursement rates that are higher than the statutory tax-free rates that must be entered in payroll for taxation.

General Requirements for Integration of Travel Expenses in HR Payroll

The integration of Travel Expenses in HR Payroll is set up in Customizing for Travel Management. In the feature for settlement control (TRVPA), you specify whether integration with Payroll is to be set up and how the payroll period is to be checked against the payroll period from the personnel control record (PA03). 

To be able to process the travel expenses results in Payroll, the country-specific travel expenses subschemas must be activated in the country-specific payroll schemas. You can activate these subschemas via Travel Management Customizing.

For German Payroll, subschema DREI (transfer of travel expenses to payroll) must be inserted and activated after subschema DT00 (gross pay) in settlement schema D000 (settlement schema for Germany).

Scenario 1: Transfer of travel expenses results within one logical system

If Payroll and Travel Management are installed in the same logical system (same R/3 System and same client), the payroll program can import the travel expenses results directly from Travel Management and process them.

  Travel Management Service  

Use

In the Employee Self-Service Travel Management function, employees can: 

• Submit a travel request 

• Reserve flights, hotels, and car rental for a trip online 

• Enter data for trips that have already taken place. The system uses this data to determine the travel expenses for the employee and to trigger reimbursement of these expenses. 

   Offline Travel Expenses  

Purpose

The Offline Travel Expenses application allows you to enter and edit trips and receipts offline regardless of location, using mobile devices (Notebooks). You do not need a connection to the SAP R/3 system. This application is of particular use for employees that are regularly away from the office on business trips and that cannot always have a connection to the SAP R/3 system.

The user can enter trips and receipts offline and save them on their Notebook. They can then transfer these trips to SAP R/3 when they next have access to the online R/3 system. 

The user can synchronize the trips they create using Offline Travel Expenses with SAP R/3 at any time. Once the data has been transferred to the SAP R/3 system, it can be processed in the same way as trips and receipts created using the normal online Travel Management interface. Offline Travel Expenses uses the same business logic and the same database tables as the other user interfaces for Travel Management. At the end of the process, the travel expense information is processed in SAP R/3 and then transferred to the Travel Management components.

  Workflow Scenarios in Travel Management (FI-TV)  

Use

The standard system includes the following workflow templates for Travel Management:

• Approve Travel Request 

• Automatically Approve Travel Requests 

• Approve Travel Plan 

• Automatically Approve Trips 

• Approve Trip 

• Mail: Trip on Hold 

• Mail: Trip has been Settled 

• Mail: Trip has been Transferred to FI 

   Special Purpose Ledger  

Purpose

In the application component Special Purpose Ledger, you can define ledgers for reporting purposes. You can keep these user-defined ledgers as general ledgers or subsidiary ledgers with various account assignment objects. Account assignment objects can either be SAP dimensions from various applications (such as account, cost center, business area, profit center) or customer-defined dimensions (such as region).

The Special Purpose Ledger allows you to report at various levels using the values from the various application components. The modules in the Special Purpose Ledger allow you to collect information, combine information, and create totals. You can also modify, assess, and distribute actual and plan values that are transferred from other SAP applications or external systems to the Special Purpose Ledger.

The use of the Special Purpose Ledger has no effect on the actual functions of other SAP applications.

 The FI-SL System and Other SAP Applications: Shared Functions  

Use

The FI-SL System has interfaces with other SAP applications and shares many functions and processing techniques with these systems.

There are two types of ledgers in the FI-SL System:

• Standard ledgers

• Special purpose ledgers

  Integration of FI-SL with Other SAP Applications  

Use

All SAP applications are based on the concept that you only enter a business transaction once. The information that you enter is however then immediately available to all other SAP applications.

FI-SL collects data from other systems at the original point of entry and validates it immediately as it is being entered. With this maximum integration, you do not need to run batch interfaces; the data can be copied to the FI-SL System directly.

  Configuration  

Purpose

This section explains basic concepts for configuring your FI-SL System.

FI-SL Database Tables

FI-SL Master Data 

Additional FI-SL System Requirements

For more detailed information about system configuration, see the Implementation Guide (IMG) for Special Purpose Ledger.

 Overview: Configuring and Using the FI-SL System  

This section explains the basic steps for configuring and using your FI-SL System. For more detailed information about system configuration, see the Implementation Guide (IMG) for Special Purpose Ledger . 

1. Designing your FI-SL system structure 

Before you install and set up your FI-SL System, you must carefully design your system structure. It is very important that you take time to design your system and data structures. A well-organized system structure leads to efficient running of your production system and improves system performance.

Depending on your reporting requirements, you must determine which dimensions and field movements you want to use in your ledgers. (A dimension represents specific criteria in business processes. Technically, a dimension is a single field or column of a database table.)

 

In the above graphic, Ledger 1 uses the dimensions "Account" and "Cost Center"; Ledger 2 uses the dimensions "Cost Center" and "Plant"; and Ledger 3 uses the dimensions "Product" and "Product Number". Since Ledgers 1 and 2 share the dimension "Cost Center" and all the dimensions used by the ledgers are defined in one table group, both ledgers can use one table structure (Table Group 1). Since the dimensions "Product" and "Product Number" do not exist in Table Group 1, Ledger 3 must use a different table group.

2. Creating your FI-SL database tables 

Once you have designed your FI-SL system structure, you can create your database tables and specify which dimensions you want to include in your tables.

FI-SL uses the following table types:

• Object tables

(for receiver/sender and transaction attributes)

• Summary tables

• Actual line item tables

• Plan line item tables

For more information about these table types, see FI-SL Database Tables.

You use the Define Table Group function to define your database tables and store them in the ABAP Dictionary. A table group is a group of interdependent tables (object tables, summary tables, actual and plan line item tables).

For more information about creating a table group, see the Define Table Group activity in the Special Purpose Ledger Implementation Guide (IMG).

 

You can also create a rollup actual line item table and a rollup plan line item table, if, for example, you want to drill down from the rollup summary data to the original data in a Report Writer report.

It is not currently possible to automatically install these tables using the Define Table Group function. If you want to use a rollup table, you must copy the standard tables delivered with your system (GLREFU: Rollup actual line item table and GLREFV: Rollup plan line item table) using the Copy table function in Customizing and modify them according to your requirements.

For more information, see the Copy Table activity in the Implementation Guide (IMG) for Special Purpose Ledger.

When you create your database tables, you must decide among other things the following:

• Whether you require a local table (for a company code) or a global table (for a global company).

• Which dimensions you want to include in the object/partner object table (for example, account, cost center, business area, and so on) and which of these dimensions you also require as partner dimensions (sender/receiver relationship).

• Whether you require a second object table for transaction attributes.

• Whether you want to include additional dimensions in the data part of the summary table. These dimensions are known as derived dimensions because they must be uniquely derivable from the other dimensions in a specific summary record.

• Whether you want to include additional dimensions in your actual line item table. These dimensions are only used in document display (or in line item reporting).

• Which currencies and quantities you want to use in your database tables

• How many periods you require in your summary records

• Which database indices you want to define for your FI-SL tables

See also:

Database Definition and Installation

3. Installing your FI-SL database tables 

Once you have defined, saved, and activated your table group, you can install your database tables directly using the Table Group function.

For more information, see the Define Table Group activity in the Implementation Guide (IMG) for Special Purpose Ledger.

See also:

Database Definition and Installation

4. Creating your FI-SL master data 

After you have defined the dimensions that you want to use in your ledgers (table structure), you can define the master data (special purpose ledgers, companies, activities, and field movements) that you want to use in your system (see the following graphic).

Special purpose ledgers: When you create your special purpose ledgers, you define, among other things, the ledger master data (such as the currencies and quantities the ledger should use, whether the ledger is open for posting, and whether the ledger can be used as a rollup ledger). You must also assign a company code or global company to your ledger so that data can be posted to the ledger. You then define which activities can update the ledger (company code/ledger/activity or global company/ledger/activity assignment). If you want to define additional criteria for posting data to your ledger, you can enter ledger selection conditions.

Company codes and global companies: You can use company codes and global companies in your FI-SL system. Company codes are defined in the FI System and are the most commonly used companies in the FI-SL System. You can set up your system so that a company code directly updates a local ledger (ledger/company code assignment). Global companies usually group together one or more company codes. You can assign a company code to a global company so that the company code updates a global ledger (ledger/global company assignment) and a local ledger.

Activities: The data entered in other SAP application areas or external systems is transferred into the FI-SL System using an activity. You must assign activities to your ledgers so that data can be updated in these ledgers.

Field movements: You can create field movements to define which dimensions are filled within the FI-SL System. Field movements determine which dimensions from other SAP applications are transferred to the dimensions in the FI-SL System.

For more information about creating master data, see the activities under Master Data in the Implementation Guide (IMG) for Special Purpose Ledger.

You can also define your master data using the Graphic navigation function, which allows you to graphically display relationships between company codes, global companies, ledgers, and activities. If required, you can also branch to the assignment to change it. For more information about using the Graphic navigation function, see the Use Graphic Navigation activity in the Implementation Guide (IMG) for Special Purpose Ledger.

See also:

Master Data 

5. Defining additional requirements for working with your system 

After you have created the master data that you want to use in your system, you have to maintain additional system settings (such as posting periods and versions) required for working in your productive system.

You can also define your own validations and substitutions for your system to check and/or substitute values and combinations of values as they are being entered in your system. Since validation and substitution occur before data is posted, only valid information enters the FI-SL System.

For more information, see the Special Purpose Ledger Implementation Guide (IMG).

See also:

Additional FI-SL System Requirements

6. Working with your FI-SL System

After you have completed the above steps, you can work in your FI-SL System, using the available functions to meet your specific business requirements.

  Planning  

Purpose

With the Planning function in the Special Purpose Ledger, you can enter and distribute plan data to create budgets, forecasts, and other reports.

You can quickly and easily enter large amounts of plan data. Generally, you can enter plan amounts in the following ways:

• You can enter amounts as plan totals that are (automatically or manually) distributed to the planning periods.

• You can enter amounts as period amounts that are automatically totaled.

• You can enter a combination of both totals and period amounts.

For information on creating plan data, see Creating Plan Data.

  Actual Posting  

Purpose

With the Special Purpose Ledger actual posting, you are able to transfer data/business transactions to the FI-SL system in one of the following ways:

•        From other SAP application components, such as Financial Accounting (FI), Materials Management (MM), Controlling (CO), and Sales and Distribution (SD)

•        Directly, using FI-SL’s document entry function (for example, when posting correction documents)

•        From external systems (for non-FI-SL data)

You can enter a transaction into the “MM” system as a “material receipt”. This transaction could then update an FI-SL ledger in real-time mode.

The document principle controls the input and storage of documents in the SAP R/3 Systems. A document is the basic unit for recording and tracking business transactions through the SAP R/3 System. One document exists for each business transaction. Each document is assigned a document type. The document type groups together documents that are to be processed in the same way. In the FI-SL System, document types determine:

•        Whether a document is stored as plan or actual data.

•        Which currency fields appear on the document entry screens.

•        Whether or not the document has to balance.

•        How the document number is assigned.

  Periodic Processing  

Purpose

This section describes the processes and functions that are relevant for periodic processing.

  Information System  

Purpose

The SAP system includes an extensive and flexible Information System for analysis of cost flows that occur in an organization. You can use this both to carry out recurring standard evaluations and create reports for extraordinary queries and tasks. It is possible to analyze all data interactively, directly after input into the SAP R/3 System. Data can be traced right back to document level. All reports that are available online can be executed in the background. This is particularly important in the case of very extensive datasets.

  Tools  

Purpose

The FI-SL system offers a wide array of different tools that you can use to create reports, check and test settings, and trigger evaluations, validations, and substitutions. You can create sets, check the posting structures in your system, and display the contents of your FI-SL direct posting tables.