TFIN 50

BASIC SETTINGS
ORGANIZATIONAL UNITS

Organizational units are used to structure business functions and for reporting. The
organizational units of Financial Accounting are used for external reporting
purposes, that is, they fulfil requirements that your business is subject to from
external parties, for example, legal regulations. The financial statements for
example, are created based on the organizational units of Financial Accounting.
Use
You create your company-specific organizational structure in the SAP System by
defining the organizational units and making the basic settings. Defining
organizational units for Financial Accounting is obligatory, that is, you have to
define these units in order to be able to implement the Financial Accounting
component.
Integration
In the SAP System, you define the relevant organizational units for each
component that you are implementing. For example, for Sales and Distribution, you
define sales organizations, distribution channels, and divisions (product groups).
Similarly, for Purchasing, you define purchasing organizations, evaluation levels,
plants, and storage locations. The organizational units are independent of one
another at this stage.
To transfer data between the individual components, you have to assign the
organizational units to each other. You only need to make these assignments once
in the system. Whenever you enter data subsequently, it is automatically
transferred.
The client is the highest level in the SAP ERP system hierarchy. Each client is a
technically independent unit with separate master records and a complete set of
tables and data.
The most important organization unit of financial accounting is the company code.
A company code represents an independent balancing/legal accounting entity.
And is the minimum structure necessary in SAP ERP Financials.
Every organization for which a financial statement and profit and loss statement
(P&L) is to be created must be stored as a company code in the SAP system.

Highest Level
Specifications or data valid for all organizational units
Each Client is an independent unit
Corporate group or group of affiliated companies

Controlling
area

Client

Company
Independent balancing/legal accounting entity
Minimum structure necessary
Usually created per country
Alphanumeric ID

Business area: 4 digit ID

Segment: 10 characters ID

Business
area

Company
Code

Profit
Center

Segment

Client
Definition
A commercially, organizationally, and technically self-contained unit within an SAP
System. Clients have their own master records and set of tables.
The definition of the client organizational unit is obligatory.
Use
You 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.
Company
Definition
The smallest organizational unit for which individual financial statements are
created according to the relevant legal requirements. A company can include one
or more company codes.
The definition of the company organizational unit is optional.

Use
A companys 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.
Company Code
Definition
Smallest organizational unit of external accounting for which a complete, selfcontained set of accounts can be created. This includes the entry of all
transactions that must be posted and the creation of all items for legal individual
financial statements, such as the balance sheet and the profit and loss statement.
The definition of the company code organizational unit is obligatory.
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.
Integration
If you use other components of the SAP System, you have to make assignments
between the company code as the central organizational unit of Financial
Accounting, and the organizational units of the other components. This is
necessary to ensure that data can be transferred between the components.

Copy an existing company code.

Address data is required for correspondence and is recorded on evaluation

reports.
Currency Accounts are managed in the company code currency. Other
currencies are interpreted as foreign. The system translates the amounts
posted in a foreign currency into the company code currency (local
currency).
Language key
Country key This is important for business or payment transactions, since
different forms are required for foreign payment transactions.

In addition to the company code there are further important organizational units in
Financial Accounting. These are optional:

Separate reporting
Separate financial statement

Other important organizational units in Financial Accounting:

Other important org. units

Business area

Represent separate areas

of operation, can be used
cross-company codes

Profit Center

Evaluates the success of

indipendent areas within a
company. Internal analysis
of profits

Segment

Business segments (IFRS)

Company

For consolidation
functions. It can contain
one or more company
codes

Functional area

In cost-of-sales
accounting, operating
costs are sorted according
to function

The controlling area is the most important organizational element in Controlling. A

self-contained organizational structure for which costs and revenues can be
managed and allocated. More than one company code can be assigned to one or
more controlling areas. Assigning more than one company code to the same
controlling area is possible only if all the assigned company codes use the same
operating chart of accounts and have the same fiscal year variant.

Controlling

Chart of accounts
(+ Fiscal Year
variant)

Company Code 1

Company Code 2

Company Code 3

Controlling area (most important in controlling) identifies a self-contained organizational

structure, here cost and revenue can be managed and allocated. Represents a separate unit of
cost accounting.
More than one company code can be assigned to one or more controlling areas. This enables a
cross-company code cost accounting between the assigned company codes. It is possible if all the
assigned company codes use the same operating chart of accounts and have the same fiscal year
variant. However, as there are important relationships between financial and management
accounting we will also regard this area as a whole. (Reporting purposes).
BASIC SETTINGS IN GENERAL LEDGER ACCOUNTING

Define which elements separates reports are necessary

G/L accounting (new) enables to use of parallel valuations approaches/parallel accounting
through the use of different ledgers

Each client has exactly one leading ledger, while additional non-leading ledgers are used for other
requirements. The main ledger reflects the accounting principle used to draw up consolidated
financial statements. It is integrated with all subledgers and is updated in all company codes.

Leading ledger 0L, non-leading ledgers (parallel accounting). This is known as the
ledger approach in the new General Ledger, is not necessary to define an
additional ledger per company code, a non-leading ledger is sufficient for the
purpose.
You have the option of defining a different fiscal year in non-leading ledgers. Only
the values from the leading ledger are posted to CO in the standard system. The
accounts approach, different valuation approaches and valuations are posted to
different accounts.

Accounts approach Vs. Ledger approach

Account
Approach

Leading
Approach

-Relevance of posting for

Local or Int. GAAP specified
at the acc. level

-Relevance of posting for Local or

Int. GAAP specified at the acc. level

-ALL valuation approaches

can be posted to CO

-ONLY the leading valuation can be

posted to CO

-Minimum one retained

earnings acc. for EACH GAAP
-Complex financial statement
definition

-Minimum one retained earnings

acc. for ALL GAAP
-Standard Financial Statement
definition

-Specific accounts groups

-Complex chart accounts
structure

-No specific account area

-No change to chart of accounts

You cannot define your own scenarios. The scenarios provided are assigned to
the ledgers in Customizing. A ledger (always the leading ledger) can be assigned
one or more scenarios, or even all six at once. You do not need a ledger for each
scenario!

Cost Center Update

-Update os sender
cost and receiver
cost center fields
Cost of Sales
Accounting

Preparation for
Consolidation

-Update of partner
business area and
receiver functional
area field

-Update for
consolidation tx
type & trading
partner fields

Scenarios
Segment Reporting

Business Area

-Update of
segment, partner
segment and profit
center fields

-Update of trading
partner business
area and reciever
business area fields
Profit Center
Update
-Update of profit
center and partner
profit center fields

VARIANT PRINCIPLE
Three step method used in SAP system to assign particular properties to one or more objects . The
main advantage is that it is easier to maintain properties which are common among several
business objects.

Define
Determinine Values
Assign to the objects

The variant principle is used for:

Field status
Posting periods
Fiscal year
()

The main advantage for using variants is that it is easier to maintain properties
which are common among several business objects. You define the fiscal year as
a variant that is assigned to the company code. The fiscal year variant contains the

definition of posting periods and special periods. In total, you can define 16
periods.
FISCAL YEAR

To assign business transactions to different periods, is necessary define a fiscal

year with posting periods. Define as a variant assigned to a company code.
Fiscal year variant contains the definition of POSTING PERIODS and SPECIAL
PERIODS, this ones (special periods) are used for postings that NOT assigned to
time periods but to the business process of YEAR-END-CLOSING. (In total you
can define until 16 periods).
The system derives the posting period from the posting date. If the posting date
falls within the last normal posting period, you can post the transaction in one of
the special periods.

Fiscal Year

Year Indipendent

Year Specific/Dependent

The number starts and end

dates for the periods are the
same for every year

Periods can be vary from

year to year

Calendar Year: Posting

periods are equal to the
months of the year (12
posting periods)

Non-Calendar Year: posting

periods by assigning end
dates to each periods. (1-16
postin periods) If not start on
1st January must has +1 or-1
indicator

Conditions: a)Start/end of
posting periods are different
dates between one year and
other. b) Some FY use a
different number of posting
periods.

Shortended FY: One fiscal year

of a fiscal year variant has less
periods than the others. Is
assigned a lower number of
posting periods. It need to be
defined and number of
postinmg periods beofre be
defined period dates.

The fiscal year variant does not specify whether a period is open or closed (this
data is managed in another table). FY variant only defines the number of periods
and their start and finishes dates.
CURRENCIES

Currency Key: need to be assigned. Use International standard currency keys

(USD, JPY,GBP, MXN etc.) Each currency key can have a validity date.
For every combination of two currencies, can be maintain different exchange rates
which are distinguished by an exchange rate type. Then, use different exchanges
rates for different purposes, such a validation, conversion, translation and planning.
Exchange rate types:

Historical rate
Bank selling rate
Bank buying rate
Average rate
The rate on certain key dates

The relationship between currencies must be maintained per exchange rate type
and currency pair using translation ratios (usually has to be performed only
once). Since inflation can deeply influence the relationships between currencies,
translations ratios are maintained on a time period basis.

Is possible reduce the amount of work involved in the maintenance of exchange

rates by using one of the following TOOLS:

Base currency
Exchange rates spreads
Inversion

Exchange rate spreads between the bank buying/selling rate and average rate
usually remain constant. If the exchange rate spread of an exchange rate type is
entered in the system, only is necessary maintain the average rate since buying

and the selling rate can be derived by adding/subtracting the exchange rate spread
to/from the average rate.
(Combination of base currency and exchange rate spreads). Efficient combination
of the exchange rate tools is:

Using base currency for the average rate

Using the exchange rate spreads to calculate the buying and selling rates

The exchange rate is defined or communicated using the direct or indirect method
of quotation depends of the market standard or the individual business transaction.
The use of indirect quotation is neither application nor country-specific(it affects all
the components in which exchange rates are used).

Local: EUR

Direct: One unit of

foreign currency is
quoted for the local
currency
1USD = 1.2663 EUR

Foreign: USD

Indirect: One unit of

the local currency is
quoted for the foreign
currency
1EUR = 0.7897 USD

Worklists for Maintaining Exchange rates

Maintenance for exchange rate table with several employees, problems can be
occur:

Maintain incorrect exchange rates (unknowingly or unintentionally)

Maintain the exchanges rates with the incorrect quotation (indirect instead
direct or vice versa)
The table is very large, maintaining is very time-consuming (scrolling is
necessary)
Table TCURR cannot be maintained by more than one user simultaneously

Advantages using Tx TCURMNT to define workilsts and maintain the exchanges

rates>

Only relevant exchanges can be maintained. (Option to assign

authorizations for worklists)
Only the relevant quotation can be maintained

The worklists is smaller and therefore clearer

Parallel processing of different worklists is possible

Additionally, maintenance can be do it with two prefixes, that can be used to

differentiate between direct and indirect quotation exchange rates during input and
display. If you do not enter the standard setting is valid:

(blank, without prefix) Direct quotation exchange rates

/ Indirect quotation exchange rates

Standard
Setting:Works mainly
with direct quotation
and rarely use
indirect.
" " Direct
"/" Indirect

Scenarios
Indirect quotation is
the most widely used
notation
"*" Direct
" " Indirect

Alternative prefix for

both: increasingly use
direct quotation as
well direct quotation
"*" Direct
"/" Indirect

MASTER DATA
GENERAL LEDGER ACCOUNTS

The chart of accounts is a variant that contains the structure and the basic
information about General Ledger accounts. It is defined with a four characterID, also is defined the individual components of the chart of account (language,
length of G/L account number, group chart of accounts, status). The chart of

accounts must be assigned to every company code for which accounts are to be
set up based on the structure concerned.

Chart of accounts: to create chart of accounts, consider the same steps as

the variant creation

Define Chart of
accounts (+ Define
properties)
Contains:
-Chart of accounts Key
-Description
General Inf.:
-Maintenance Language
-Length of the G/L acc. number
CO integration:
-Manual or automatic creation of cost
elements
Consolidation:
-Group chart of acc.
Status:
-"Blocked" Indicator

Assign to company
codes
Which company code with which chart
of accounts.

Definition
Maintenance languages is in which account descriptions are maintained.
The length of the G/L account numbers can be between 1 to 10 numbers.
Via integration G/L accounts and cost types, it is possible control to what extent the
cost master record is maintained when do this in G/L account master records of
P/L statement accounts. It could be manually or automatically . You can maintain
cost types manually, however, you also have the option of maintaining them
automatically. When you save a new G/L account, the corresponding cost type is
created automatically. The prerequisite however, is that a default value for the cost
element category is defined for this cost element, since if no default value exists,
the system assumes that no cost element is to be created.
Once is assigned a group account number for each G/L account, it supports to
use for cross-company code reporting if the company uses a different chart of

accounts. If you enter a group of chart of accounts number in the corresponding

field in the G/L account definition (required field entry) and checks whether the
group account number entered exists in the group chart of account. When chart of
accounts is not completed can be blocked so that no company code can use it
until it is ready. You can get a directory of the G/L accounts in your chart of
accounts for information or for documentation purposes
Assigning
Every company code must have a chart off accounts assigned to it. One chart of
accounts can be assigned to several company codes (variant principle).
Controlling component uses the same Financial Account component, in case to
cross-company code controlling, use the same chart of accounts.
Chart of accounts segment
The chart of accounts contains basic information about the accounts, it is
summarized in a chart of accounts segment. Contains:

Account number
Name of the account (short/long text)
Control fields
Consolidation fields

If the chart of accounts has not been translated into the appropriate logon
language, the account name appears in the maintenance language.

Chart of accounts
segment
(Groups of Fields)

Type/Description
-Control in Chart of
accounts
-Description
-Consolidation data in
chart of accounts

Key word/Transaltion
-Keywords in chart of
accounts
-Translation

Information
-Information in chart of
accounts
-G/L texts in chart of
accounts

Information entered in the chart of account segment for G/L account applies to all
company codes. (information entered once). Texts entered for the chart of
accounts segment is managed by text ID and language. Use key words to search
account numbers.
Is possible define and change the layout of the tab tables for individual processing
of the G/L account master data, define:

Number of tab pages

Title of tab pages
The field groups that you require and their position on the tab pages
Select layouts for central processing, and processing in the chart of
accounts and company code-specific area. (You can copy these
layouts, adjust them to meet your requirements, and then assign them to
your chart of accounts or your account groups.)

Company code segment

To use one of the accounts from the assigned chart of accounts in your company
code, you must create a company code segment for the account. This company
code segment is added to the chart of accounts segment, and together they form
the account. Contains information to refers exclusively to company code
concerned.

Control Data:
-Account Control
-Account
Management
-Joint Venture

Company Code
segment
(Several
groups of
fields)

Information:
-Information
-G/L Account texts

Bank/Interest:
-Documentation
Creation
-Bank/Financial
Details
-Interest Calculation

The company code segment for the same G/L account can be different depending
on the requirements of the company code. To define the information that is
relevant to each company code:

Currency
Taxes
Reconciliation account
Line item display
Sort key
Field status group
House bank
Interest calculation information

Texts are managed by text ID and language.

One Chart of Accounts, Several Company Codes
Every company code that wants to use an account from the assigned chart of
accounts has to create it is own company code segment. Because the number
and name of the account is maintained in the chart of accounts, the account has
the same name and number in all assigned company codes.
Balance sheet and P&L Statements Accounts
In the chart of accounts segment, is necessary to specify whether the account is a
balance sheet or a P/L statement account.
Two types of accounts that are treated differently in the closing procedure
1. For balance sheet accounts, the balance is carry out forward to the same
account
2. For P/L statement accounts, the balance is carried forward to a retained
earnings account and the P/L statement account is set to zero. A key is
assigned to the account to which balance is carried forward. (Enter the key
in the field P&L statement type in the chart of accounts segment)
In customizing, users define the retained earnings account that is assigned to
expense accounts during G/L account master record creation. If there is only one
retained earnings account, the system automatically uses the one defined in
customizing. If there is more than one retained earnings account, when you create
a master record, you can select the retained earnings account for each P&L
statement account.
Account groups for G/L accounts
Since a chart of accounts contains many different types of accounts, they can be
grouped into different account groups. Usually, one account group groups
accounts with the same tasks within the G/L. By assigning a number of range to
an account group, it can ensure that accounts of the same type are within the
same number range. Number intervals go G/L account master records can overlap.

At the moment to enter the account group in the chart of accounts segment, it
controls the appearance of the company code segment of a G/L account. In
customizing, for your Cash Accounts account group, change the field status to
make line item display a required entry. (SAP ERP delivers predefined account
groups).
Field Status
It enables to you to control the display and maintenance of an accounts master
data:

Hide
Fields that are not used

Display
Fields whose values must
not be changed

Required
Fields where must be
enter value

Optional
Fields that can contain an
entry, but are not
required

Certain fields are grouped together and their field status is valid for the entire
group. The fields Account currency and Field status group are ALWAYS
required entry fields, this status cannot be changed. For fields which are supressed
may contain values, and these values still take effect.
Field Status for Master Data

The field displayed in the general ledger account master record are not only
controlled by the account group, but also by the transaction that you are using to
edit the master data (transaction-specific control). If have not the certain fields to
be modifiable after the creation of master record, specify that a particular field is
not modifiable in the Change Master Data transaction in customizing assigning
the status Display to the relevant field.
For each field, the field status definitions from account group and the transaction
are taken into consideration and the one with higher priority is used.
Fields that are accessed with the transaction Display Master Data are always
either displayed or hidden since you cannot make an entry in a display
transaction. If is not wished to use the transaction-specific control, set the field
status for all fields to optional. Since this field status has the lowest priority, the
account group specific control is always used.
Reconciliation Accounts
Are general ledger accounts assigned to the business partner master records to
record all transactions in the subledger. All posting to the subledger accounts are
automatically posted to the assigned reconciliation accounts. The general ledger is
always up to date.
To define a G/L account as reconciliation account by entering one of the following
account types in the field Reconciliation account for account type:

Accounts Receivable (D)

Accounts Payable (K)

The reconciliation account is then ONLY valid for the account type specified.
Typical reconciliation accounts are the accounts receivables and payables.
Amounts cannot be posted directly to reconciliation accounts
Line Item Display
Is a control field in the company code segment of an account.
Transaction figures are the totals of line item postings on the debit or credit side.
The balance is the difference between the debit and the credit transaction figure.

Accounts with:
-The most important data
from the posted line items is
sorted in special index table
-This data is also sorted in the
documents, it is redundant
and nedds additional storage
and system time
-To looks this account online,
is possible view the balance
and individual line items

Accounts without:
-Only the transaction figures
are updated when a document
is posted to this account.
-To look this account online ,
only is possible view the
balance

Since the line item display takes up additional system resources, you should only
use it if there is no other way of looking at the line items. Not activate Line Item
Display for:

Reconciliation accounts: line items are managed in the subledgers

Revenue accounts: line items are managed by the Sales Order
Management application
Material stock accounts: line items are managed by purchasing
management application
Tax accounts: tax items are only useful in connection with the document;
the tax amounts were already checked when the document was posted

All necessary information is in subledgers. In New General Ledger accounting, the

statement regarding the control of line item management in the account refers only
to the entry view of documents. The active new general ledger accounting has an
Entry view and a General ledger view for a document. In general ledger view,
the line items on all accounts are always visible.
Open Item Management
Items in accounts with open item management are specified as OPEN or
CLEARED. Accounts with open item management must have line item display
activated.
Open item management is a prerequisite if is necessary check whether there is an
offsetting posting for a given transaction. It is possible display open and cleared
items separately, and therefore it is easy to see which business transactions still
need to be cleared.
Open Item management should be used for the following accounts:

Bank clearing account

Clearing accounts for goods receipt/invoice receipt
Salary clearing accounts

Is possible to activate or deactivate open item management if the account has zero
balance.
Account in Local currency
As standard, the local currency is proposed as the account currency when is
created a G/L account. For account currency there are two options:
1. Local currency
2. Foreign currency
If the account currency is the local currency, the account can be posted to in any
currency. The other currencies are converted into the local currency for each line
item.
Only balances in local currency
If the indicator Only balances in local currency is selected in the master data
record, transaction figures are only managed for amounts converted into local
currency.
The indicator must be set in cash discount and GR/IR clearing accounts. The
indicator is usually set in balance sheet accounts that are not managed in foreign
currencies and not managed on an open item basis.
Account in foreign currency
Accounts with a foreign currency as account currency can only be posted to in this
foreign currency.

Manually

Copying

Data Transfer

One Step: Create both segments

simultaneously (centrally)

Copying an individual G/L acc.

w/reference to other G/L acc.

Transfer a new chart of accounts

from an external system

Two Step:
-Chart of accounts Segment
-Company Code Segment

Copy the entire Company Code

Segment

Copy the entire chart of accounts

segment

Create Manually

With the two step method, creation of chart of accounts segment separately
from the company code segment. This allows to create the G/L account only in
the chart of accounts segment or in multiple company code segments.
Use the one-step method to create the G/L account in specified company code.
Repeat step 2 of the two-step method, that is, creation in the company code
segment, to create the G/L account in additional company code as needed.

Create G/L accounts by copying

To create an account that has the same properties as an existing account,

that is, another cash account, create the new account with reference to the
existing account and change the account name accordingly.
If all of the G/L accounts in an existing company code are required in
another company code, you can copy the entire company code segment to
the new company code.
You can also copy the entire chart of accounts to a new chart of accounts,
including the account determination. Is possible, also copy the financial
statement version

Data Transfer

To reduce data entry, programs (RFBISA00, Batch input interfaces for G/L
acc. Master data) can be modified to transfer new chart of accounts.

Collective Processing
Collective processing functions for G/L account master records. The system
allows to change at the same time master data in:

Chart of accounts segment

Company code segment
Description (such names of several G/L accounts)

For internal purposes, cross company code reporting may be useful. It is not
problem if all company codes use the same chart of accounts. If some company
codes may have to use special chart of accounts because of legal requirements, is
necessary apply the following procedure for internal reporting:

Can use a group chart of accounts, it must contain all of the group of
accounts
The group chart of accounts must be assigned to each operational chart of
accounts. If this is done, the field Group account number in the chart of
accounts segment s of operational charts of accounts is a required entry
field
Must enter the group account number in the chart of accounts segment of
the operational account. Different accounts of one operational chart of
accounts can refer to the same group account.
Must use a financial statement version for the group chart of accounts

(Disadvantage: because the company codes uses different operational chart of

accounts, no inter-company code controlling can be performed)
Country Chart of Accounts
An alternative to using a group of chart of accounts is to use a country chart of
accounts, all company codes uses the same operational chart of accounts.
Company codes that nevertheless required a special chart of accounts for external
reporting have the following option:

A chart of accounts is assigned

The country chart of accounts number (alternative account number) is
entered in every company code segment. Every country chart of accounts
number can only be used once

Since all company codes post into the same operational chart of accounts, crosscompany code controlling is possible.
(Disadvantage: Accounting clerks who may be familiar with the country charts of
accounts first have to get used to using the operational chart of accounts)

PROFIT CENTER AND SEGMENT

Every company can define for itself which elements/objects can be used to create
the reporting (balance sheet/ P&L). The segment is often chosen as the element
here.
The segment field/characteristic is a new standard account assignment object in
order to create evaluations for objects/entities below the company code level.
The objective is to give a detailed look at the various business activities at (broadbase) enterprise. segment reporting. Alternative account assignments already
used which are still available:

Profit Center
Business area
Profitability segment of CO-PA
User defined field

Segments can be used to meet the requirements of international principles

regarding segment reporting.
The business area or profit center objects can be used as alternatives. The
segment is provided in addition because the business area and/or profit center
were frequently used for other purposes in the past and thereby to meet other
requirements.
Derivation of a Segment
System enables save a segment in the master data of a profit center. The segment
is posted automatically when the profit center is posted to.
If the profit center does not have a segment, there is no segment account
assignment either. The standard method is to derive the segment from the profit
center. (Customers can also program solutions/derivations themselves.)

The segment is derived from the characteristic profit center because this already
exists in various SAP objects, and the characteristic segment is automatically
derived from this. Segments can only be derived automatically using profit centers.
If it is not possible to derive the characteristic Segment from a profit center master
record, other ways must be found of assigning a segment. Document splitting
provides the following options:
Manual entry
BAdI implementation (FAGL_DERIVE_SEGMENT)
Defining substitution rules
Standard account assignment.
CUSTOMER/VENDOR ACCOUNTS

These accounts have two segments as G/L accounts:

1. Client level, contains general data. This data can be accessed throughout
the whole organization.

2. Segment at company code level, contains company code-specific data.

Any company code that wishes to do business with specific customer or
vendor has to create a company code segment for this customer or vendor.
This also creates a customer or vendor account.
Because the sales and distribution department also stay in contact with a customer
and has to know specific data about this customer, a sales area segment can be
created for each customer. Any sales area that wants to do business with a
customer has to create a sales area segment first. The sales area segment
contains sales area-specific data.
The Materials Management point of view of the vendor account, just as there is a
sales area segment for customers, and purchasing organization segment for
vendors. Any purchasing organization that wants to do business with a vendor has
to create a purchasing organization segment first, it contains purchasing
organization-specific data.
Usually the sales area segment must at least be created for the sales area
assigned to the company code. The account number is assigned to the
customer/vendor at client level. This ensure that the account number for a
customer/vendor is the same for all company codes and sales area.
Complete Customer Account
General data in a client level
Company code segment
Sales area segment
Complete Vendor Account
General data in a client level
Company code segment
Purchasing organization segment

Usually at least the purchasing organization segment for purchasing organization

assigned to the company code must be created.
Centralized Vs. Decentralized Maintenance
The system offers two separate functions for maintaining customer/vendor master
records depending on the requirements of the organization. These data records
can be maintained centrally for all areas or separately for financial accounting
and Materials Management., sales and distribution (customer case).

Compare Master Data

It is easier to create customer/vendor master records centrally to ensure that they
are set up correctly. In some cases Purchasing Management/Sales Order
Management create their own segments of the master record and accounting
creates its own segments of master record, in this case there is the risk of creating
incomplete or duplicate master records. To prevent the creation of duplicate
accounts as follows:

Use the match code before create a new account

Activate the automatic duplication check

Pages of the customer/vendor account

Each account segment consists of several pages

with different groups of fields

General Data
-Adress
-Control data
-Payment transactions
+ texts

Company Data
-Acc. information
-Payment transactions
-Correspondence
-insurance
-withholding tax
+ texts

Important fields

Search terms: enter an abbreviation for the customer/vendor name in these

fields. The format is defined by company guidelines and practices
Group: Customer or vendors who belong to the same corporate group can
be bundled together under a user-defined group key. This group key can be
used for running reports, transaction processing, or for matchcodes.
Clerk/accounting: the name of the accounting clerk must be saved under
an ID. You can also use this ID for sorting dunning and payment proposal
lists.

Explanatory texts can be entered in every segment. Line item display and open
item management are configured as standard for every customer/vendor account.
As a recommendation, you create a reference account for every account group.
Account groups
When is created a customer/vendor master records, enter de account group on the
initial screen. In Financial Accounting, once the customer/vendor account has been
created, you can no longer change the account group. The account groups
controls:

Number ranges

Status of the fields in

master records

One time
customer/vendor
account (Normal
Account)

Divided into smaller number ranges (it must not overlap)

Internal: assigned by the system
External: entered by the user who creates the record (alphanumeric)
Each number ranges can be assigned to one or more account groups

The account group is used to control the fields displayed in the master
record

Created for rarely business with customer/vendor

Contains receivables and payables for one-time
It doesnot contain any specific information
It should be hidden fields
Entered in the document during posting

In Status of the fields in the Master Record the account group is used to control the
fields displayed in the master record.
Controlling the field status
The layout of customer/vendor master data screens can be affected by several
factors:

Account group-specific control: field status is usually controlled only by

the account group. All accounts of one account group have the same screen
layout.
Transaction-dependent control: field status can be dependent on the
master data transaction (create, change or display). The transactiondependent field status should be set to display for the change transaction
if the field is not to be changed after it has been created.
Company code-dependent control: control the field status for fields in the
company code segment of customer/vendor master records via the
company code-specific screen layout. Hide fields that are not used in
specific company code, but enter values in these fields in other company
codes.

The account group-specific status, transaction specific-field status and company

code-specific field status are compared and the field status with the highest priority
is used.

Dual control principle

It define that one person makes changes to customer/vendor master data while
another person is responsible for confirming the changes, usually for critical
changes. If it is define a field in the customer/vendor master record as sensitive,
the corresponding customer/vendor is blocked for payment if the entry is changed.
The block is removed when a second person with authorization check the change
and confirms or rejects it.
The confirmation for the changes can be made for a single customer/vendor or
using a list. It can be restricted by:

Customer/vendor
Company code
Accounts not yet confirmed
Accounts rejected
Accounts to be confirmed by me
Display the changes to the customer or vendor master record for all
accounts (reports RFDABL00 or RFKABL00)

Customer/Vendor Clearing
If a customer is also a vendor or vice versa, the payment and the dunning program
can clear open items against each other. The open items of the assigned
account can also be displayed in the line item display and the open item selection
screens. To clear open items, follow the steps:

Enter de vendor account number in the customer account and vice versa
Each company code can decide separately whether it wants to clear open
items between customers and vendors. If clearing is to be used, select
Clearing with vendor field in customer account or corresponding field in
vendor account.

Alternative Payer/Payee
At the client and company code level, you can enter an alternative payer/payee.
The entry in the company code segment has higher priority than the entry at client
level. If you set the Individual Entries indicator when creating an invoice, you can
enter information about an individual payer/payee for a customer/vendor that has
not been created in mySAP ERP. If the alternative payer/payee is an existing
customer or vendor, you can enter the customer/vendor account number as
permitted payee/payer in the master record.

Head Office/Branch
Customer in some industries place orders locally, but pay invoices centrally, there
is a difference between the goods flow and cash flow. All items posted to a branch
account automatically transferred to the head office account. Usually dunning
notices go to the head office and it is the head office that make and receives
payments. If the Decentralized processing field is selected in the head office
master record, the dunning and payment programs use the branch accounts
instead.

DOCUMENT CONTROL
DOCUMENT STRUCTURE

Document principle, a document is saved for every posting. The document

remains as a complete unit in the system until it is archived. Every document is
uniquely identified by the following fields:

Document number
Company code
Fiscal year

Each document contain the following:

Document header, information that applies to entire document

Between 2 and 999 line items (information that is specific to the line
item). When you post documents via the AC interface (for example, from
Sales Order Management, Purchasing Management, or other applications),
it creates items in the accounting document that are identical in almost all of
the fields.

Is possible display detailed data for the document header and line items. Two
important control keys:

Document type for the document header

Posting Key for the line items

The SAP system generates at least one document for every business transaction.
The system can assign the document numbers or the user can assign the number
when entering the document.
Related documents are linked in the system so that you have an overview of every
business transaction in the system.

Document type
Controls the document header and is used to differentiate the business
transactions to be posted. Documents types are defined at client level and are
therefore valid for all company codes. The standard system is delivered with
document types that can be changed or copied.
Document types define the following:

Number ranges for document numbers

Account types permitted for postings

Document types also define the following:

The field status of the document header text and reference number
fields in the document header
Whether invoices are posted with the net procedure

If the original document has an external number:

Enter the external number of the original document in the Reference Number
field in the header of the system document
Note the number of the system document in the original document

Customer
Invoices (DR)
Vendor net
invoices and
credit memos
(KN)

Vendor
Payments (KZ)

Customer
Credit Memos
(DG)

General
Documents
(AB)

Vendor Credit
Memos (KG)

Customer
Payments (DZ)

GL Acc.
Postings (SA)
Vendor
Invoices (KR)

Document type AB allows postings to all account types. To transfer billing

documents from the SAP ERP billing system, you need one of the following
document types:
RV, the default document type for Sales Order Management billing documents
(customer invoices).
RE, the default document type for Materials Management billing documents
(vendor invoices).
When internal number assignment is used, the system assigns a new number to
each document in the Financial Accounting component. In external number
assignment, the system transfers the billing document number to the accounting
document, providing this number has not already been assigned.
Document number ranges
Defines the range of numbers that must be assigned as document numbers. It
must not overlap.

Internal numbering: The system saves the last document number that was
taken from the number range in the current number field and assigns the
number following the current number as the text document number.
External numbering: The user enters the number of the original document,
or the number is transferred automatically from another system. The number
is usually not assigned in sequence, which is why the system cannot store a
current number. It can be alphanumeric.

The document number range must be defined for the year in which it is used.
There are two options:
1. Fiscal Year in the Future: at the beginning of a new fiscal year, the system
continues to use the number after the current number as the next number. It
does not restart at the first number of number range.
2. To Every Fiscal Year: at the beginning of a new fiscal year, the system
starts again with the first number of the number range. This helps to ensure
that the number range is sufficient.
In new General Ledger Accounting, different ledgers can use different fiscal year
variants. This is a very rare case. It is then necessary to make special settings for
these ledgers in Customizing:
Document number ranges are stored for the general ledger view.
The number ranges are assigned to the document types for the general ledger
view.
Internal number assignment must be set for these number ranges. One number
range can be assigned to several document types.
Functions of Posting Key
The posting key has control functions within the line items. It controls:

To which type of account the line item can be posted to

If the item is posted as a debit or credit
The field status of additional details

Like document types, posting keys are also defined at client level. In addition to
control functions, posting key also specifies:

Whether the line item is connected to a payment transaction. This

information is required for analysing the payment history and creating
payment notices

Whether the posting is sales-relevant and the sales figure of the account is
to be updated by the transaction

In the standard transactions, posting keys are labeled debit and credit. The
following default values:
For GL account posting: Debit is posting key 40, credit is posting key
50.
For customer invoices: Debit is posting key 01, credit is posting key 50.
For customer invoices: Debit is posting key 31, credit is posting key 40.
Document Field status
At the moment to enter documents, different fields are displayed depending on the
transaction and the accounts used. What information is displayed when a
document is processed is controlled by the field status.
As general rule, define the account-dependent field status for general ledger
accounts in customizing. For customer and vendor data, define the posting keydependent field status in customizing according the requirements.
Exceptions

If business areas are used, the business are field must be ready for input.
You can activate it by enabling business area financial statements for the
company code. You can only use the field status to define whether the field
is a required or an optional entry field.
Entries in tax fields are only possible if the general ledger account is
relevant for tax.

The hide field status cannot be combined with the required entry field status.
This combination causes an error.
Field Status Group
For each group of general ledger accounts, is necessary define the status of every
document entry. When documents are entered for these G/L accounts, should the
text field be required, optional or hidden??
This information is divided into field status groups for each group G/L accounts.
Is assigned field status groups to the respective general ledger accounts in the G/L
account master records. The field status group are summarized in one field status
variant. The field status variant is assigned to your company code(s). No posting

can be made until this is complete. If a document is posted to a subledger account,

the field status group of the reconciliation account is used.
Standard Posting Keys
By changing the field status definition posting keys and the field status group, you
can make the field status transaction-dependent or account-dependent.
Since the subledger accounts do not have a field status group, postings are
differentiated mainly by means to different posting keys. For this reason, there are
numerous posting keys for subledger accounts.
Mandatory fields are also controlled centrally for document splitting objects (such
as the segment or profit center) when document splitting is used.

Postings to G/L accounts are mainly differentiated by means of different field status
groups. Therefore, only two posting keys are required for G/L account postings.
POSTING PERIODS

Posting periods are defined in the fiscal year variant. To prevent documents from
being posted to an incorrect posting period, as advise close certain posting
periods. Usually the current posting period is open and all other periods are closed.
At the end of a period this period is usually closed and the next period is opened.
Open a posting period by entering a range in the posting period variant that
compasses this period.

During period closing, open special periods for closing postings. During closing,
two periods intervals must be open at the same time. Therefore, two periods
intervals can be entered in the posting period table.
Posting Period Variant
Several company codes can use the same posting period variant. For all company
codes assigned, the posting periods are opened and closed simultaneously. This
simplifies the period maintenance.
Periods check by account type
In the document header, the periods assigned to the account type+ are checked.
This is the first check. Therefore the account type + must be open for all periods
that are supposed to be open for any other account type. The posting period
variant must contain at least the account type +. If the posting periods for
different account types are all to be handled in the same way, the control by means
of the + entry is sufficient.
Posting periods can be handled differently for different account types; that is, for a
certain posting period, postings to customer accounts may be permitted while
postings to vendor accounts may not.
At the line item level, the system check the account type of the posting key to
ensure that the period is open for the assigned account type.
The account interval always contains G/L accounts. By entering certain
reconciliation accounts behind subledger account types, these subledger accounts
can be treated differently to accounts that have different reconciliation account.
During closing, two periods intervals must be open at the same time. An
authorization group may be assigned to the first period interval. Then, only users
belonging to this authorization group have the permission to post in the first period
interval. It makes sense to use the first range for the special periods and authorize
only the accountants involved in closing to post in the special periods.
A third period interval is possible. In this interval, open periods are stored for realtime integration CO FI really should be able to be posted in the periods. If the
third period is not filled, the entries in intervals 1 and 2 are also valid for these
postings.
With the new General Ledger Accounting, there is also the option to control more
precisely which values for which individual account assignment objects can be
posted, and when.

Determination of posting periods during posting

When entering a document, among other items, enter the posting date, the system
automatically determines the posting period and fiscal year based on the posting
date entered.
In the document overview the posting date, posting period and fiscal year are
displayed. The posting period determine is entered in the document and the
transaction figures for this posting period is updated. If display the balance of an
account, the transactions figures for the posting periods are displayed.

POSTING AUTHORIZATIONS

The upper limits for posting transactions within tolerance groups.

The maximum amounts are defined per company code in tolerance groups. This
is also where the processing of payment differences is controlled.
Maximum amounts
Upper limits for posting transactions within tolerance groups. Is possible enter the
following:

Total amount per document

Amount per customer/vendor item
Cash discount a user with this tolerance group is able to grant

(Local currency of the company code).

Assigning posting authorizations
Is possible to create many tolerance groups, every user can be explicitly assigned
to a tolerance group. For any employees who have especially high or low limits, a
special tolerance group be created and assigned to their user logon IDs.

SIMPLE DOCUMENTS IN FINANCIAL ACCOUNTING

G/L acc.
postings

SIMPLE
POSTINGS
Customer
invoices
and credit
memos
posting

Vendor
invoices
and credit
memos
posting

The SAP Financials Accounting component uses one posting transactions for
several different postings. Header and Item data, also the entry screen contains an
information area where is displayed the balance.
Enjoy Posting Screen
The easy to use ENJOY transactions. You can define a document type for each
transaction, which then appears as a general default value. You can overwrite this
proposed document type at any time as long as the document type field is ready
for input during document entry. Via the button Tree, you can access screen
variants, account assignment templates, and held document that you can select as
templates.

You can select from Park, Post, or Hold, to complete the document entry
transaction once the balance is zero. For complex postings you can access the
complex posting transaction via the menu. You cannot return to the initial screen
from this complex posting transaction. You can enter an explanatory text for the
line item. This item text can be used internally and externally.

POSTING CONTROL
DOCUMENT SPLITTING

Is only for customers who have to or want to enter further characteristic (such as
segment) on the balance sheet, in addition to company code.
A financial accounting document ALWAYS has two views:

Data entry view: view of how a document appears to the document

creator and therefore how it is shown in the subledgers
General ledger view: view of how a document appears only in the
general ledger

Besides the leading ledger, may also see the document in other, non-leading
ledgers in the general ledger view.

Displaying a document in the entry view and general ledger view is defined in the
new G/L accounting an cannot be switched on or off using customizing. New G/L
accounting offers the following aspects for balance sheet analysis below the
company code level.
Displaying P&L statement by profit center, business area or segment is never
problematic, since the positions which have an effect are always provided with
unique corresponding objects by the original controlling object. If a balance sheet is
created for one of these objects, the problem is that line items cannot be split in the
entry view. This only happens in the general ledger view, using document splitting.
The entities defined as splitting characteristics (balancing characteristics) are
inherited in non-account-assigned posting lines. Document splitting (also called
online split) ensures that companies can create complete balance sheets for
desired objects. If document splitting is not activated, there is usually no difference
between the entry view and G/L view.
Document splitting is activated in customizing. Since document splitting can be
activated for each client and deactivated for each company code, the decision of
whether to split the document or not is made at company code level. All company
codes of a client can only use one document splitting procedure, that is, different
procedures cannot be assigned to different company codes.

Inheritance

If an account assignment object is unique in a document, it is

inherited online in all missing positions.

Default acc.
asisgnment

It is possible to work with default acc. assignment, that is, if the

position is not provided with necessary object for any reason
then a default value can be set automatically

For documents which

do not show clearing,
individual distribution
rules can be created in
customizing to decide
which positions of a
document are divided
according to which
basic positions. The
document type is the
basis for the rule

Creating clearing lines/zero

balance formation

During clearing, the

entities of the
document being
cleared are copied to
the clearing document
without being change

Active Split

Passive Split

Document splitting process

Is always used if, in
addition to the total
document, the objects
to be balanced within
the document should
be balanced to zero

Document splitting can be activated subsequently by migrating existing data. The

document splitting settings generally cannot be changed after this.
Standard splitting characteristics
Always set the Zero balance indicator if you want to create a financial statement for
the characteristic.

Business area
Profit Center
Segment

(User-defined characteristics can also be used for document splitting)

Document splitting characteristics determine which objects document splitting is
used for (where to divide/balance)
The mandatory field indicator has two meanings:
1. It is an extension of the field status for accounts in which characteristics
cannot be entered during document entry, and/or for accounts that cannot
be controlled using the field status.
2. It is a check as to whether a business process-equivalent business
transaction variant was selected (which determines whether a splitting rule
can be found)
The mandatory field indicator works in addition to field status control in the account
or in the posting key.

A splitting procedure, defined in brief, is the total of all splitting rules of all business
transactions. As such, the splitting procedure defines how and under which
circumstances document splits will be performed. In detail, it means each splitting
procedure defines how each item category will be handled in the individual
business transactions.
Is a general breakdown of
the actual business
porcesses that sap
provides and is assigned a
wide variety of item
categories

Is the semantic description

for the document split.
Technical map of the
posted line items.
Describes the items that
appear within a document

is a specific version of the

predifined business
transactions provide by
SAP and the (technical)
modeling of a real business
process for document
splitting

BUSINESS
TRANSACTION

BUSINESS
TRANSACTION
VARIANT

ITEM CATEGORY

INDIVIDUAL
SPLITTING RULE

Defines which itmes

categories can/should be
split (item categories ti be
processed) and at the
same time defines which
foundation (case) can be
used (based item
categories)

DEFAULT VALUES

Parameter IDs allow users to set default values for fields whose values does not
change very often, when is executed the transaction, these values appear in the
corresponding fields automatically. Therefore, is not necessary enter values
manually and can prevent input errors. Using the editing options, configure the
screens for the followings areas:

Receipt entry: users can hide fields that may not be relevant for their jobs,
such as foreign currency or cross company code transactions. Can also use
special editing options for the single screen transactiosn
Document display: using the List Viewer, the user can select different
display options for displaying documents
Open items: users can choose line layout displays and postings options for
processing open items, in other words, they can enter the amount of a
partial payment or the balance of the new open item.

When users log on to the SAP ERP system, their user ID has specific properties
that apply to it throughout the system: logon language, date format, and decimal
notation. Users can also set a default printer for themselves.
System and Accounting Defaults
The system provides you with basic default values for document entry. The system
proposes the company code that you entered in the last document. The system
works on the basis of the Document Principle: All documents must balance
before they can be posted to.
At company code level, enter the maximum difference permitted between the
exchange rate in the document header of a business transaction and the exchange
rate in the exchange rate table.
CHANGE CONTROL

Changing documents
Users can change documents that have already posted, based on different rules,
only certain fields can be changed. These rules can either be predefined by the
system or be user-specific.
Certain fields in both the document header and the line items can be changed.

Document header: Only the reference number and document header text
can be changed
Line items: the system does not allow changes to the amount, the posting
key, the account, or any others fields that would affect the reconciliation of a
posting

As users make changes to documents, the following information is logged:

The field that was changed

The new and old values
The user who made the change
The time and date of the change

Differentiation between document change rules according to the following criteria:

Acc. Type: allows users to define rules for customer, vendor and G/L
accounts
Transaction class: are only used for the special G/L transactions bill of
exchange and down payment

Company code: if the field is blank, the rules applies to every company
code

The CONDITIONS for changing a field predefined:

The posting period is still open

The line item is not yet cleared
The line item is either a debit in a customer account or a credit in vendor
account
The document is not a credit memo for an invoice
The document is not a credit memo from a down payment

DOCUMENT REVERSAL

Once in a while, a document is entered and posted incorrectly. It must be reversed

and re-entered correctly. Users can make errors when they enter documents. As a
result, the document created contains incorrect information. In order to log the
adjustments, the incorrect document must first be reversed. The document can
then be re-entered correctly.
The system provides a function to reverse G/L, customer, and vendor documents,
both individually or in a mass reversal. A document can be reversed by:
a) Normal reversal posting: causes the system to post the incorrect debit as
a credit or vice versa. It causes an additional increase in the transaction
figures.
b) Negative posting: also post the incorrect debit as a credit and vice versa.
This time the posted amount is not added to the transaction figures, but is
subtracted from the transaction figures of the other side of the account. This
sets the transaction figures back to as they were before incorrect posting
took place.
When you reverse a document, you have to enter a reversal reason that explains
the reversal. The reversal reason also controls whether the reversal date is allowed
to be different to the original posting date. Documents with cleared items cannot be
reversed. The document must first be reset.
The normal reversal posting causes the system to post the incorrect debit as a
credit and the incorrect credit as a debit. The negative posting also posts the
incorrect debit as a credit and the incorrect credit as a debit. Is subtracted from the
transaction figures of the other side of the account.

Normally the system uses the normal reversal posting to reverse documents. The
following prerequisites must be fulfilled to enable negative postings:

The company code permits negative postings

The reversal reason must be defined for negative reversal

Negative posting can also be used to perform transfer postings of incorrect line
items. The item is removed from the wrong account by a negative posting
(resetting the transaction figures) and posted to the correct account by a normal
posting. This can only be done with a document type that explicitly allows negative
postings.
When is applied a reverse a document, enter a reversal reason that explains the
reversal. The reversal reason also controls whether the reversal date is allowed to
be different to the original posting date.
Documents with cleared items cannot be reversed, the document must first be
reset.
PAYMENT TERMS AND CASH DISCOUNTS

Terms of payment are conditions agreed between business parameters for the
payment of invoices. The conditions define the due date and the cash discount
offered for payment of the invoice within a certain period.

Some terms of payment are predefined in the system; is possible add news if it is
necessary.
Terms of payment enable the system to calculate a cash discount and invoice
due date. In order to this, the system needs the following data:

Baseline date: the date from which the due date is derived
Cash discount terms: the terms which the cash discount can be taken
Cash discount percentage rate: the percentage rate used to calculate
cash discount

When a document is process, enter the terms of payment so that the system can
calculate the required conditions of payment. If you have entered terms of payment
in the master record, these are proposed. You can also enter or change them
during processing.
Is possible enter terms of payment in the company code segment, sales area
segment, purchasing organization segment of a customer/vendor master record.
Invoice related credit memos
Credit memos can be linked to the original invoice by entering the invoice number
in the invoice reference field during invoice entry. In this case, the terms of
payment are copied from the invoice so that the invoice and the credit memo are
due on the same date

Other credit memos

General

Terms of payment in other credit memos are invalid. These credit memos are
due on the base line date. To activate the payment terms on these noninvoice related credit memos.

The DAY LIMIT is the calendar day to which the terms of payment are valid. It allows
store single or multi-part termsof payment in a terms of payment key

The DESCRIPTION for terms of payment includes the following elements: an

explanation generated automatically by the system which can be replaced by user
explanation of the terms of payments and a Sales Order Management text for
printing on invoices

The Account type defines the subledger in wich terms of payment can be used.

Payment Control
A block key and payment method, defined in terms of payment are defaulted in the
line item when the terms of payment are used.

Using block keys, which can be entered in line items or accounts, can block
line items or accounts for payment or collection. These block keys can also
be entered in payment terms
A payment method (for each country, the system has payment methods
defined that you can use in that country) is entered in the line items or the
accounts. Like payment blocks, payment methods can be entered in the
terms of payment.

Baseline Date
Is the starting date the system uses to calculate the invoice due date. The following
rules apply for the calculation of the baseline date:

The default values from which the baseline date can be determined are as
follows: no default, document date, posting date or entry date
Specifications for calculating the baseline date: fixed day used to overwrite
the calendar day of the baseline date.

The number of month(s) to be added to the calendar month of the baseline month.
Cash discount
To calculate the cash discount, enter a percentage rate in the terms of payment,
also enter the number of days that the percentage is valid for in the same line. You
can also add fixed days and months. Also, system allows enter up three cash
discount periods.

Discount percentage rates

Discount periods

The days and months specified in the terms of payment are used in conjunction
with the baseline date to calculate the correct cash discount amount for the
payment date. Enter up to three cash discount periods.
Day limits
It enables date-specific terms of payment in one terms of payment key. Is possible
define several versions of terms of payment, with each version having a different
day limit.
The day limit is the baseline date up to which the payment term version applies.
For terms of payment that are dependent, allows to enter two-part terms of
payment under the same terms of payment key. The entry for specified day limit is
added to the terms of payment key. This results in two entries where different
terms of payment can be defined. The following terms of payment REQUIRE the
specification of a day limit:

Documents with invoice date up to the 15th of the month are payable on the
last day of following month
Documents with later invoice date are payable on the 15th of the month after

Instalment Payment
An invoice can be paid over several months using an instalment plant, or a portion
of the invoice amount may be retained for payment at later date. The total invoice
amount is divided into partial amounts due on different dates.

The system carries out this split automatically if instalment payment is defined in
the terms of payment. Consider:

Instalment number
Percentage
Payment terms for instalments

The percentage rates specified must total 100%. The system creates a line item for
each installment specified.
The line item amounts correspond to the percentages of the total amount. The total
of the line item amounts corresponds to the total amount. The terms of payment for
the line items are the terms of payment defined for the individual instalments.
Cash discount base amount
Depending on the international regulations of each country, the cash discount base
amount is the net value or gross value. For each company code or tax jurisdiction
code, specify which value the system is to use as cash discount base- this setting
belongs to the global parameters of a company code.
Posting cash discount
Gross procedure
The cash discount amount is entered either manually or automatically by the
system using the rates in the terms of payment. You can still change the cash
discount after you post the invoice. When an open item on a customer or vendor
account is cleared, the possible cash discount is posted automatically to an
account for cash discount expense or cash discount received. Define the
accounts for cash discount expense or cash discount revenue in the configuration.
Net Procedure
The amount posted to expense or balance sheet account is reduced by the cash
discount amount. The same amount is also posted to a cash discount clearing
account to clear the posting. When is used the net procedure, the cash discount
amount is automatically posted when the invoice is posted.
When you use the net procedure, the cash discount amount is automatically
posted when the invoice is posted. When the invoice is paid, the system carries
out a clearing posting to the cash discount clearing account. If the invoice is paid
after the cash discount deadline, the cash discount loss is posted to a separate
account. The cash discount clearing account must be managed on an open item
basis.

TAXES

When posting an invoice SAP allows for taxes to be levied on the invoice amount
as:

Tax on sales/purchase
US sales tax
Additional taxes (country-specific)
Withholding tax

Two taxation types are possible:

1. Federal/country level, with uniformly defined rates
2. State/jurisdictional level, with rates defined by the state or jurisdiction
In some countries taxes are even levied in both levels

Tax Support
Provides support for

Calculate tax
amounts

Posting to
defined tax
accounts

Performing
tax
adjustments

Tax reporting

Calculates tax
amounts from
Base amounts
with or
without a
cash discount

Tax codes to
check or
calculate the
tax amount

The expense or revenue mount is the base amount is the base amount, which can
include a cash discount (tax base is gross) or exclude a cash discount (tax base is
net). Tax code is used for the calculation procedure required to perform taxation
functions on the SAP system.
National regulations determine whether the tax base amount must be:

Net amount: taxable expense or revenue items minus cash discount

Gross amount: taxable expense or revenue items including cash discount

User can define which amount is to be used for each company ode or for
the highest level of the jurisdiction code.

Tax on Sales and Purchases

The output tax is levied on the net value of the goods and is billed to the
customer. It is a liability of the company to the tax authorities.
Input tax is levied on the net invoice amount and is billed by the vendor. The input
tax is a receivable which the company claims from the tax authority. The tax liability
minus deductible input tax is the tax payable. Tax authorities can define that part of
the input tax is not deductible. This tax amount can be posted to a separate
expense account
Tax calculation procedure
For carrying out tax calculations is assigned to every country.
Tax calculation
procedures
contain:

THE ORDER OF STEPS: which have taken in the tax calculation

procedure (the "from step" indicates where the system calls the
base of value for "step")
TAX TYPES (CONDITION TYPE): apply for the country. The system is
delivered w/consition types necessary for ech type of taxcalculation

ACCOUNT KEY / TRANSACTION KEY: covers additional specification

and is used for the automatic auccount determination for the taxes
concerned
Condition types are tax calculations that are valid for the country. The base amount
is an expense or revenue item.
Jurisdiction key/code
A jurisdiction code is a combination of codes of tax authorities that tax movements
of goods and use their own tax rates. There are four possible levels below national
level:
1.
2.
3.
4.

State
County
City
District

The tax jurisdiction codes must be defined on every level. You can enter the taxes
per jurisdiction code or per tax level.
Using tax jurisdiction codes involves two steps:
a) Define the length of the individual elements of the code for the format of the
jurisdiction code. This activity also automatically switches over tax
processing for this tax jurisdiction code method
b) The tax jurisdiction codes must be defined on every level
When are post taxes with jurisdiction code, it allows enter the taxes per jurisdiction
code or per tax level.
Tax code

Verify the amount of tax

Calculate the amount of tax
Calculate additional tax portion
Verify the tax type
Determine de G/L account
Show tax correctly on tax forms

Enter a the tax code when post the document and this is the main connection to
the tax calculation. This connection is different depending on whether the country
uses tax calculation procedure with tax jurisdiction codes or not . Tax code is linked
with either of the following

Country key
Combination of country key and tax jurisdiction code
The tax codes with a jurisdictional taxation method are date-specific. In the
configuration, choose whether the document date or the posting date is valid
for the tax calculation.

Tax rates
It are assigned to the tax types used in the tax calculation procedure. A tax code
may have several tax rates entered for different tax types (if a line item is to be
taxed with several tax types), but usually one tax rate is entered.
Some posting to tax-relevant G/L accounts must have a tax rate of zero. This
applies to:

Items that are tax-exempt but have to be reported to tax authorities. For
these items a special tax code with a tax rate of zero is created.

Items that are created by tax exempt transactions such as goods issue,
goods movement, and so on. A special tax code must be assigned to these
transactions in configuration.

The tax type definition determines if the base amount is percentage included or
percentage separate.

TAX POSTINGS

Standard Scenario: The taxes calculated

by the system are usually posted via a
separate line item to a special tax
account.

Taxes with certain transaction/account

keys are distributed to the relevant
expense/revenue item. (Sales tax
payables or other non-deductible input
taxes)

If the system detects a deviation between the tax calculated and the tax amount
entered, it either issues an error message (check indicator set) or a warning
message (check indicator not set).
Tax Postings
The taxes calculated by the system are usually posted via a separate line item to
a special tax account. This is the standard scenario.
Taxes with certain transaction/account keys (for example, NVV) are distributed to
the relevant expense/revenue item. This is the case for sales tax payables or other
non-deductible input taxes.
Tax account determination
To enable to automatic tax account determination, it has assigned the following
data to the account/transaction keys that generate the tax item during posting:

Posting keys
Rules that determine which fields the account determination is based on
(tax code or account key)
Tax accounts

When exchange rate differences occur because of tax adjustments in foreign

currencies, these exchange rate differences are usually posted to the normal

account for exchange rate differences. The resulting differences are posted to a
special account.
Tax accounts
Means accounts to which tax items are posted, in the field tax category by
entering one of the following signs:

< for input tax

> for output tax
The properties of the tax code define whether or not the tax posted is an
input or output tax

Post automatically only option must be selected if it does not want to post tax
manually.
Other G/L Accounts
If the Postings Without Tax Allowed field is selected, you can post to this G/L
account without specifying a tax code. This is especially necessary for tax postings
within a jurisdiction code tax calculation procedure to foreign customers who do not
have a jurisdiction code.
Accounts for cash discounts need an entry in the Tax category field if the system is
supposed to post tax adjustments
Special Tax Codes
The acquisition tax code generates two posting items: it posts the acquisition tax
to credit side of the acquisition output tax account and the same amount to the
debit side of the acquisition input tax account.
The output tax code for the tax exempt deliveries must have an EU code for
goods
CORSS-COMPANY CODE TRANSACTIONS

It involves two or more company codes in one business transaction. A crosscompany code transaction post to accounts in several company codes. This cannot
be done by posting only one document because a document is always assigned to
exactly one company code. Instead, the system creates and posts a separate
document in each company code involved.
In order to balance debits and credits within these documents, the system
generates automatic line items which are posted to clearing accounts, for
payables or receivables.

The documents which belong to one cross- company, code transaction are linked
by a common cross-company code transaction number.
Central Procurement
The clearing postings and the tax postings are created automatically.
The tax is not distributed between the company codes according to their expenses.
Therefore, this function may only be used if the transaction itself is not tax-relevant
of if the company codes form a taxable entity.
The tax calculated is always posted to the company code of the first item.
Therefore, to ensure that the tax is posted to the same company code as the
invoice, the invoice item must always be entered first.
Clearing accounts
Must be defined in every company code before cross-company code transaction
may be carried out. The clearing accounts may be G/L accounts, customer/ vendor
accounts.
To reduce the number of clearing accounts, you can use just one company code
as the clearing company code. In this case, only has to assign clearing accounts
to every combination of the clearing company code and other company codes.
Posting keys, must be assigned to the clearing accounts to identify their accounts
types.
Cross-company code document number
When the cross-company code document is posted, the system generates a crosscompany code document number to link all of the new documents together.
The document dumber is a combination of the document number of the first
company code, the first company code number, and the fiscal year. It is stored in
the document header of all of the documents created for a complete audit trail.
Cross-company code documents may be reversed: to do this, use the reversal
function for cross-company code transactions.
REAL-TIME INTEGRATION

In many Controlling postings, financial accounting objects are addressed. These

cases are implemented using real-time integration COFI in financial accounting.
Defined variants in customizing are used to decide for which objects postings of
this kind should or have to be created.

The real time integration of controlling/accounting makes ad hoc valid reporting

possible. This enables full compliance with transparency requirements for
corporate governance.

As a result of a posting between

controlling objects, a change results for
an accounting object (profit center,
segment business area or functional
area) stored in a controlling object

Costs are posted across company codes

in cross-company code cost accounting.
In this case such postings must alse be
mapped correspondingly in accounting

Real-time affectation

Special features of the Financial Accounting document:

Postings are made in real-time (for each CO document).
In this case, the FI follow-on document has no clearing accounts.
The variants for real-time integration COFI are defined in customizing. In an
additional step, these are the assigned to a company code. The key date activation
defines when CO-FI reconciliation is possible with real-time integration.

CLEARING
OPEN ITEM CLEARING

Open items are incomplete transactions, such as invoices that have not been
paid. For a transaction to be considered as completed, it must be cleared. A

transaction is cleared when a clearing posting has been carried out for an item or
group of items, so that the resulting balance of items is zero.
Documents with open items cannot be archived and stay in the system until all
open items are cleared. Clearing transaction ALWAYS creates a clearing
document.
Post with clearing
When use this function, enter the clearing document amount and then select the
open items that are to be cleared.

If the total amount of selected open items equals the amount of the clearing
document, the system clears the open items by creating one or more
clearing items.
If the total amount of selected open items does not equal the amount of the
clearing document, the system allows to post the difference

Posting with clearing can be carried out for several accounts, account types and for
currency simultaneously. It could be manually or automatically, using the automatic
payment program.
Account clearing
Using this function, select those open items from an account that balance to zero.
The system marks them as cleared and creates a clearing document. The clearing
document number and the clearing date is entered in the cleared items.
The clear account function works for any accounts managed on an open item
bases in de G/L and the subledgers. (manually or automatically using the clearing
program)
Account Clearing
Using the Clear Account function, you select those open items from an account
that balance to zero. The Clear Account function works for any accounts
managed on an open item basis in the general ledger and the subledgers.
Clearing program
The user can clear open items for general ledger and subledger accounts with the
automatic clearing program. The program groups together the items of an account
that have the same entries in the following fields:

Reconciliation account number

Currency
Special G/L indicator
Five freely defined criteria from document header or line item

If balance (in local currency) of the items within a group is zero, the system
automatically clears them and creates clearing documents.

Steps in the Clearing

program:
-Group Items for each
account
-If balance is zero, items are
marked for clearing

Prerequisites for clearing:

-User criteria must be
defined in customizing
-Accounts to be cleared
must be defined for
automatic Clearing

Items that are not cleared:

-Noted items
-Statistical postings, G/L
transc. relating to bill of
exchange postings
-Items with withholding tax
entries

The assignment field as sort field

The system automatically fills the assignment field for a line item when you post
items according to the sort field entry in master record. The assignment field can
be a combination of up to 4 fields with a maximum of 18 characters. The line item
sorting in the line item display and clearing function is based on the assignment
field.
However, if the sort key is set to the cost center in a general ledger master record,
then the assignment field in the general ledger line item is filled with the number of
the cost center when that G/L account is used. The line item sorting in the line item
display and clearing functions is based on the assignment field.
The reference and the assignment in the accounting document are copied from the
reference and the assignment in the Sales Order Management billing document.

INCOMING AND OUTGOING PAYMENTS

Customers pay open invoices taking advantage of cash discounts. The cash
discount is to be posted in the system automatically. See Manual payment process
as follow

POST WITH
CLEARING

DOCUMENT
HEADER
-Payment header
-Bank data
-Select open items

PROCESS OPEN
ITEMS
-Activate items
-Activate cash
discount

POST
-Display overview
-Post

A manual payment is a transaction that clears an open item, typically an invoice, by

manually assigning a clearing document. An incoming payment, typically used in
accounts receivable, clears an open debit amount.
An outgoing payment, typically used in accounts payable, clears an open credit
amount.
Manual Payment Process

1. Data is entered in the document header

2. Open items are selected to be cleared

3. Transaction is saved

The data entered in the document header is similar to the data entered when
posting invoices. The document header consist of three sections:

1. Payment header: includes document date, document type, company code,

period specification (posting date/period), currency code, exchange rate
date for currency translation, reference document number, document
header text, clearing text.
2. Bank data: account, total payment amount, bank charges, value date, text,
assignment number.
3. Open item selection: account and account type, normal open items and/or
special G/L transactions, payment advice note number, other accounts,
additional selections.
The first step in processing open items is to active the required line items before
can assigned a payment. The amount entered is assigned to the appropriate line
items and their cash discount. To post a document, the amount entered must is the
same as the amount assigned.
The cash discount granted is determined by the terms of payment of the line item.
The cash discount is taken into consideration for calculating the assigned amount.
Is possible change the cash discount by overwriting the absolute cash discount or
by changing the cash discount percentage rate. It must not exceed the limits set in
the tolerances.
Automatic Postings for clearing open items
You can enter bank charges when you enter the bank data; they are automatically
posted to the G/L account. In order to perform manual cross-company code
payments you have to assign a clearing transaction to the combination of paying
company code and the company code for which the payment is being made. Then,
when you select open items, open items are displayed from each company code.

Cash discounts expense or revenue

Cash discount clearing (net procedure)
Tax adjustments
Exchange rate differences
Bank charges
Clearing for cross-company code payments
Over-or underpayments within tolerances

Resetting Clearing
When you reset clearing, the clearing data is removed from the items. In Accounts
Receivable, the payment history and the credit limit are corrected, if applicable.

PAYMENT DIFFERENCES

In accounting, tolerances can be divided into three types: Employee

tolerance groups, G/L account tolerance groups and customer/vendor
tolerance groups.

For Employees:
-Upper limits for transactions
-Permitted payment
differences

For Customers/Vendors:
-Default values for
clearing transactions
-Permitted payment
differences
-Specifications for
posting residual items
from payment
differences
-Tolerances for payment
advice notes

For G/L Accounts:

-Permitted payment
differences

Assign tolerance groups to

User master data

G/L account master records
Customer/vendor master records

You have to carry out two steps to use tolerance groups:

Group definition: The tolerance group is defined by a group key, company code,
and a currency code.
Group assignment: If no tolerances are assigned, the default tolerance group
____ (blank) applies.
Permitted payment differences
The specifications for permitted payment differences can be found in both types of
tolerance groups (employees and customers/vendors). They control the automatic
posting of cash discount adjustments and unauthorized customer deductions. The

system takes the entries in both groups into account during clearing. The payment
difference has to be within both tolerances to be handled automatically.
The entries in the tolerance groups are always in the local currency.
Payment differences
A payment difference normally occurs during the clearing of an open item. The
difference is then compared to the tolerance groups of employee and
customer/vendor and is handle accordingly.

Within tolerances: Automatically posted as either cash discount

adjustment or unauthorized deduction.
o Automatic cash discount adjustment
o Automatic posting unauthorized deductions
o Manual cash discount adjustment
Outside tolerances: processed manually
o Partial payment
o Clear difference manually
o Payment on account
o Residual items

If the payment difference is immaterial, it may be processed automatically by

allowing the system to adjust the cash discount up to certain amounts or to write it
off to a special account. The limits to which a payment difference is considered to
be immaterial are defined in tolerance groups. Within the tolerance group for an
employee, it allows and adjustment of the cash discount (within defined limits), so
that employee has the authorization to make the adjustment.
If the payment difference is too high to be immaterial it must be processed
manually. If the payment difference is outside of the tolerances it has to be
processed manually. The payment can be posted as follows:
Partial payment
The payment difference may be posted as a residual item
The payment difference can be posted to an account assigned to a reason code
or written off by manually entering a new posting item.
Payment on account
If the payment difference is outside of the tolerances it has to be processed
manually. The user can:

 Post the payment as a partial payment, where all the documents remain in the
account as open items
Post the payment difference as a residual item, whereby only the residual item
remains in the account and the original document and the payment are cleared. A
new document number is created with reference to the original documents.
Post the payment difference to a different account as a difference posting using
reason codes and automatic determination.
Write off the difference (manual account assignment)
The customer/vendor tolerance groups contain entries that control the residual
items. These specify:
Whether the terms of payment of a residual item are the same as those of the
cleared item or whether the terms of payment are fixed
Whether cash discount is granted only partially and not for the whole amount
By specifying a dunning key, whether the residual item has a maximum dunning
level or is printed separately
If you know the reason for a payment difference, you can enter a reason code.
Reason Codes
Are used to describe the reason for the payment difference. To assign more than
one reason code to a payment difference click on distribute difference. Reason
codes can be assigned to:

Difference postings
Partial payments
Residual items

The reason codes can be used to analyze and post process payment differences.
Additional optional functions:

Control of the type of payment notice which is sent to the customer

Control of the account where a residual item is posted
Automatic posting of a residual item to a specified G/L account
Exclusion of residual items from credit limit checks because they are
disputed

EXCHANGE RATE DIFFERENCES

When clearing open items in a foreign currency, exchange rate differences may
occur due fluctuations in exchange rates. The system posts the differences
automatically to the revenue/expense account for exchange rate differences that
you defined during configuration.
The realized difference is stored in the cleared line item.
Exchange rates are also posted when open items are valuated for the financial
statements. These exchange rates differences from valuation are posted to
another exchange rate difference account and to financial statement adjustment
account. When clearing an open item that has already been valuated, the system
reverses the balance sheet correction account and posts the remaining exchange
rate difference to the account for realized exchange rate differences.
Account Determination
All reconciliation accounts and all G/L accounts with open item transactions in
foreign currency must be assigned revenue/expense accounts for realized losses
and gains. One gain/losses account can be assigned to:

All currencies and currency types

Per currencies and currency types
Per currency
Per currency type

CASH JOURNAL
CASH JOURNAL CONFIGURATION

Is a tool for managing cash that support posting cash receipts and payments. This
tool allows:

Create separate cash journal for each currency

Post to customer, vendor and G/L accounts
Run several cash journals in each company codes
Choose random number for cash journal identification (4 alphanumeric digit
key)

To set up a new cash journal for a company code, you have to enter the
appropriate values for the following fields:
The company code in which you want to use the cash journal

 The four digit cash journal identification and name

The G/L accounts to which you want to post the cash journal business
transactions
The currency in which you want to run the cash journal
The document types
Within the cash journal you process different transactions that you have to set up
beforehand using business transaction categories.
There are two places where you can define new cash journal business
transactions: in the cash journal itself or in Customizing (IMG). To create a
business transaction
CASH JOURNAL TRANSACTIONS

The cash journal is one of the Enjoy business transactions that you can process on
a single screen. You can save cash journal entries locally in the cash journal
subledger, and copy or delete them. The cash journal entries saved are posted to
the general ledger, for example, at the end of the working day. You can also print
the cash journal entries. You can also copy and delete cash journal entries saved
and display the deleted cash journal entries. Also is possible enter checks in the
cash journal.
In the SAP system you can enter a cash journal document with a document split. In
other words, a cash journal document can contain several items with different tax
codes and/or account assignments relevant to cost accounting. When the cash
journal document is forwarded to Financial Accounting, only one accounting
document is therefore created.
If you use a one-time account in the cash journal, the dialog box for entering the
one-time data is called automatically and the entries saved in the cash journal.

FUNDAMENTALS
CUSTOMER VENDOR ACCOUNTS

With customer/vendor accounts, the following are important:

The structure
The relationships between customer/vendor accounts
Have two segments in the financial accounting view:
1. One segment at client level that contains general data. This data can be
accessed throughout the whole organization
2. A segment with company code specific data at company code level. Any
company code that wishes to do business with a specific customer or
vendor has to create a company code segment for the customer or vendor
has to create a company code segment for the customer or vendor. A
customer/vendor is created as result.

Important Fields

Search term

Group key: group together customers or vendors who belong to

one corporate group with a user-defined group key.

Accounting clerk: for which the clerk is responsible. The clerk's

name is then automatically printed on all correspondence. The
code is also used to sort dunning and payment proposal lists.

Line item display and open item management are always preset to on for every
customer/vendor account.
Also create a new customer/vendor master records with reference to an existing
master record. Only data that does not directly refer to customer/vendor is copied
from the reference account to the new account, that is, no address information, and
so on. It is a good idea to create a template account for every account group.
Account groups
When creating customer/vendor master records, enter the account group. In
financial accounting, once the customer/vendor account has been created, can no
longer change the account group. The account group controls:

The number ranges of the account

Whether the account is a one-time customer or vendor
The status of the fields in the master record

You can no longer change the account group.

Controlling the field status
The layout of customer/vendor master data screens can be affected by several
factors:

Account group-specific control:

field status only controlled by
the acc. group. It ensures all acc.
has the same screan layout

Transaction-specific control:
field status can depend on the
master data transaction (create,
change, display). It shpuld be set
to displaay for the change
transaction if the field should
not be changed after creation

Company code dependent

control: field status for fields in
the company code segment for
customer/vendor master
records, be controlled by
company code dependent
screen layout

Field status definitions of account groups, the transaction, and company code are
combined and the one with highest priority is used. Fields that are accessed with
the display transaction are always either displayed or suppressed.
International Bank Account Number
Is an international recognized and unique number that identifies a specific bank
account. It was designed to facilitate the handling of international payment
transactions. The IBAN contains a maximum 34 alphanumeric characters and is
structured differently in every country. It usually contains the country code, bank
key, and account number.
It is uses in addition to the standard country-specific bank details.

The IBAN can only be entered in a vendor or customer master record if the
business partner provides his or her IBAN and requests the entry. Enter
manually in each master record. For certain countries, the system generates
a proposal.
When IBAN is entered for new bank details, the system can generate the
country-specific bank details for certain countries.
Activate IBAN without Bank Account Number indicator set, user can enter
manually without requiring knowledge of the corresponding bank account
number.

Make sure that the payment medium programs used can also output the IBANs.
Clearing customer/vendor
If a customer is also a vendor, or vice versa, the payment and the dunning program
can clear open items against each other. Open items of the assigned account
can also be displayed on the line item display and the open item selection screen.

To clear open items

The vendor account must be entered in the customer account, the customer
account number must be entered in the vendor account

Each company code can decide separately whetherit wants to clear open
items. If clearing is to be used, you have to select the clearing with vendor
field in the customer account, or the corresponding field in the vendor
account

Alternative Payer or Payee

The entry in the company code segment has higher priority than the entry at client
level.
If you set the Individual Specifications indicator, you can enter information about an
individual payer/payee for a customer/vendor that has not been created in the SAP
System. If the alternative payer/payee is an existing customer or vendor, you can
enter the customer/vendor account number(s) as a permitted payee/payer in the
master record. When you enter an invoice, you can choose one of these
payers/payees using matchcodes.
Head Office Branch
All items posted to a branch account are automatically transferred to the head
office account. Usually, dunning notices are sent to the head office, which handles
the payments. If the Decentral Processing field is selected in the head office
master record, however, the dunning and payment programs use the branch
account instead.
BANK ACCOUNTS

You have to create a bank master record for every bank that is used in the system.
Every record in bank master records is identified by the bank country and the bank
key. Bank master records included address data and control data.

Banks that are used by the company are defined as house banks. Create a house
bank in customizing, it contain bank master data, information for electronic
payment transactions, the bank accounts for each house bank, and the general
ledger accounts for each bank account.
The payment program uses the house bank ID to determine the bank to be used.
When is entered bank details in the customer and vendor master record, can
access banks already created in bank directory. Then you only have to enter the
bank country and the bank key, the name and address of the bank are determined
automatically.
In the customer/vendor master record, the bank type field is used to distinguish
between different banks. When processing invoices, if the customer/vendor has
more than one bank, the user can choose a bank by using the match code in the
partner bank field.
Bank accounts
Each bank account is represented by a combination of house bank ID and account
ID. This combination is entered in a G/L account that represents the bank account
in the general ledger.

Also define banks accounts that are managed at the house banks, the accounts
can be identified by an account ID that is unique for each house bank. The bank
account data contains the number of the account at the bank, the account currency
and the relevant G/L account. A G/L account must be created for each bank
account. This G/L account is assigned to the bank account and vice versa. Both
accounts must have the same account currency.

SIMPLE DOCUMENTS IN SAP FINANCIAL ACCOUNTING

Document principle: a document is saved for every posting.

The document remains as a complete unit in the system until is archived. Every
document is uniquely identified by the following fields:

Document number
Company code
Fiscal year

Document in financial accounting consist of:

A document header (information that applies to the entire document)

Between 2 and 999 line items (information that is specific to that line
item)

Detailed data for the document header and line items (optional ). Two important
control keys:
1. Document type for the document header
2. Posting key for the line items

Simple Postings
There are different posting transactions for different postings:

G/L account postings

Customer invoice postings
Customer credit memo postings
Vendor invoice postings
Vendor credit memo postings

You can define a document type for each transaction, which then appears as a
general default value. You can overwrite this proposed document type at any time
as long as the document type field is ready for input during document entry. By
choosing the Tree button, you can access screen variants, account assignment
templates, and held documents that you can select as templates.
You can choose Park, Post, or Hold to complete the document entry transaction
once the balance is zero.

AUTOMATIC PAYMENTS
PAYMENT RUN OVERVIEW

Every company needs a way to pay its vendors, the automatic payment program is
a tool that will help users manage payables.

PAYMENT
PROCESS

Invoice is
entered

Open invoices
are analyzed
for due date

Invoices due
for payment
are prepared
for review

Payments are
approved
and/or
modified

The payment program lets automatically do:

Select open invoices to be paid or collected

Post payment documents
Print payment media, use Data media exchange (DME), or generate
Electronic data interchange (EDI)

The payment program has been developed for both national and international
payment transaction with vendors and customers, and handles both outgoing and
incoming payments. It is flexible enough to allow users to define those payment
features that vary from country to country such as payment methods, payments
forms, or data carrier specifications.

Invoices
are paid

The payment process consists of four steps:

1. Setting parameters
2. Generating a proposal: Invoices can be blocked or unblocked for payment.
3. Scheduling the payment run: Once the payment list has been verified, the
payment run is scheduled. A payment document is created and the general
ledger and subledger accounts are updated.
4. Printing the payment media: The accounting functions are completed
and a separate print program is scheduled to generate the payment media.
PAYMENT PROGRAM CONFIGURATION

The main payment program configuration menu has pushbuttons for each area. To
ensure that the configuration is complete, work from left to right through each push
button.
The first three areas will require minimum configuration changes. The standard
system contains the common payment methods and their corresponding forms,
which have been defined separately for each country.
Most of the settings for the payment program can be accessed directly through the
user side of application. The settings are divided into the following categories:

All company codes: Define intercompany payment relationships, the

company code(s) that process payment, cash discounts, tolerances
days for payments, the customer and vendor transactions to be
processed.
Paying company codes: Define Minimum amounts for incoming and
outgoing payments, forms for payment advice and EDI, bill of
exchange specifications
Payment method/country: Define: Methods of payment
o Basic requirements and specifications for each payment
method: create a check, bank transfer, bill of exchange, etc.;
master record requirements, document types for postings, print
programs, permitted currencies.
Payment method for company code: minimum and maximum payment
amounts, whether payments abroad and foreign currencies are
allowed, grouping options, bank optimization, forms for payment
media.
Bank selection (also house banks):
o Ranking order: which house bank should be considered for
payment first, second, third, etc.; Currencies, bill of exchange
account

o Amounts/ Accounts: the offset account to the subledger

posting, clearing accounts for bills of exchange, available funds
in each bank
o Expenses/charges: Assess additional bank charges for
incoming and outgoing payments, used with bills for exchange,
additional automatic posting configuration
o Value date: Used with management and forecast, the number of
days until value date plus the posting date

RUNNING THE PAYMENT PROGRAM INDIVIDUAL STEPS

Parameters. Every payment program run is identified by two fields:

1. Run date: is recommended as the actual date when the program is
executed. It is main purpose is to identify the program run.
2. Identification (field): is used to differentiate between program runs that
have the same run date.
Open Item selection
All documents that were entered up to the documents entered up to date are
included in the payment run. The posting date is the date when the G/L is updated
with postings. This date defaulted from the run date on the previous screen. If
multiple company codes are listed, they have to be separated by commas.
The company codes in a payment run must be in the same country. For each
country, defined payment methods that can be used within that particular country.
From these payment methods, choose the ones to be used in the current payment
run. If it is used more than one payment method in the payment run, the order in
which is entered is important. The system makes the payment using the highest
priority possible after the check.
Proposal run
After the parameters are entered on the main payment program screen, schedule
the payment proposal to be created.
In the proposal run, the program selects documents and accounts with items that
are pending payment. To do so, it uses the search criteria. The system the groups
these items to payments and assigns the payment methods and bank details to be
used. If the system cannot find a valid payment method or bank data, or if an item
is blocked for payments, it adds these items to the exception list.

Once the proposal run is completed, the system generates two reports:
1. The payment proposal list: a list of business partners with the amounts
they have to pay/are due, generated based on the specified parameters,
takes terms of payment and discount into account
2. Exception list: items that cannot be paid are detailed on the exception list
a. Possible reasons:
i. Invoice is blocked
ii. Invalid data in the master record
iii. Invalid payment method
iv. Invalid house bank
v. Payment amount is less than the minimum amount specified
for payment
vi. Not enough money in the house bank per configuration
vii. Debit balance
Selecting additional log, the list shows why the invoice cannot be paid.
Payment Blocks

If a problem arises during the invoice verification process, the invoice is usually
blocked for payment. You can configure this type of block in such a way that the
block can only be removed during the invoice verification process. If there is a
reason why a vendor should not be paid, you can create a payment block in the
master record.
You can also configure the block so that it has to be removed manually in the
master data record before a payment can be processed. When an AP invoice is
entered, an invoice may be blocked for payment.
Edit payment proposal
To further to analyze the proposal list, users can edit the list to view the details of a
particular payment, change the payment terms, or add payment block. After the
payment run is created, it can be edited by accounting clerks. Users can assign an
accounting clerk to a customer/vendor by entering the clerks key in the
customer/vendor master data.
By double-clicking a payment, you can display a list of all the open items that are
due to be paid with the payment. You can also assign the item to a different
existing payment, or create a new payment by choosing a payment method and
house bank.
Payment run
Once the payment proposal has been edited and saved, the payment run uses the
changes as a basis for the actual payments. Up to this point, no postings have
occurred. The documents included in this payment run have been locked against
any other postings, that is, an invoice eligible to be paid in the current payment run
is blocked for manual payment or payment, or in a different payment run. Payment
documents are created, open items are cleared, and the general and subledgers
are posted to.
The payment run uses the data from the payment proposal to:

Post the payment documents to the general ledger and clear paid open
items
Post related postings for taxes, discounts and exchange rate differences
Select the payments that can be paid with EDI
Supply the print programs with necessary data

The payment program automatically posts payments and related postings, such as
those for tax, tax adjustments, exchange rate differences, or cash discounts. You
can set the Generate payment order only indicator. In this case, the payment

program does not post a payment document. The payment document is generated
by entering the payment order. Until then, the paid items are blocked for other
clearing transactions.
It is advisable to use bank subaccounts for posting incoming and outgoing
payments, for example, accounts for outgoing checks, outgoing transfers, incoming
checks and transfers received. The subaccounts contain all incoming and outgoing
payments until the money is actually debited. The postings at the bank are usually
entered using the manual or electronic bank account statement.
The bank subaccounts have to be assigned to the payment methods when the
bank selection settings are configured. Subaccounts are generally managed on an
open item basis and with line item display.
Bank subaccounts
It is advisable to use bank subaccounts for posting incoming and outgoing
payments.

Advantages bank subaccounts

Reconcile the bank
account balance at any
time w/the
corresponding G/L
account

Subacc. contain all

incoming and outgoing
payments until the
money is actually
debited from/credited
to the bank acc. (value
date)

Item is then
transferred from the
subacc, to the bank
acc.

Postings at the bank

are usually entered
using the manual or
elctronic bank acc.
statement

The bank subaccount have to be assigned to the payment methods when the bank
selection settings are configured. Subaccounts are generally managed on an open
item basis and with line item display.
Payment Document
The document type for payment documents is defined in the country-specific
specifications for the payment method. For cross-company-code payments, can
enter a further document type that is used for the clearing postings. Both document
types must be defined using internal number assignment.

Documents from the payment run contain the date and identification number of the
run in the document header text. The value date of the clearing document is
calculated by adding the day to value to the posting date. The days to value date
depend on the payment method, bank, account, currency and the account limit. If
no entry is made, the system uses the posting date as the value date.
For calculating the value date of check payments, you can enter a check
cashing time in the master data. This has priority over the days to value date
for checks. If payments are made for individual business areas, the bank postings
is made for the business area to which the paid items belongs. In all other cases,
the postings to the bank subaccounts are carried out without reference to business
areas.
Printing payment media
The print run starts the print programs, which do the following:

Transfer the payment media, payment advice notes, and the payment
summary to print administration
Transfer the DME payment data to DME administration
Create intermediate documents for selected payments, which can be
forwarded to EDI subsystem

Variants for print programs

A print program is assigned to each payment method for each country when it is
configured. To run the print programs, the system needs at least one variant for
each permitted and used payment method. If several variants are assigned to a
print program, the system runs the program once for each variant.
The variants contain series of selection criteria, which are used to separate the
data in the print data set. Separate print jobs are created in print administration for
each variant called up from a data medium print program. The variants also contain
printing specifications.
Forms of payment media
In the configuration settings for the payment program, you have to assign payment
medium forms either to the paying company code or to each payment method for
each company code.

Form for the payment media advice and the balance zero notice
EDI accompanying sheet form
Next form (eg. DME accompanying sheet form)

In configuration settings for payment program, assign payment medium forms

either to the paying company code, or to each payment method for each company
code.

Payments advice notes can be

sent either by email or by EDI,
depending on whether the
customer/vendor can receives
EDI messages

A report chooses all the

payments that are selected for
EDI, creates intermediate SAP
docs, Forwards to EDI system. EDI
subsys. converts the intermediate
docs into EDI data, which is sent
to the bank

Data Media Exchange

A file is created that contains all the relevant payment information in accordance
with the banking rules of the country in question. The DME file is stored in DATA
MEDIUM ADMINISTRATION. DME can usually be used with all payment methods
in which the payment medium is handed to the bank for further processing, such as
bank transfer, direct debit, and so on. It cannot be used with payment methods
where the payment medium is sent to the customer/vendor.
Identify the payment run, the house bank and where the checks and any
accompanying documents are printed. Checks can be printed with predefined
check numbers (with check management) or the document number can also be
used as the check number (without check management).
The printing program:

Assigns check numbers to payment documents

Updates the payment documents and original invoice documents with the
check information
Prints checks and accompanying documents

If you are using check management, you have to use check lots to print checks.
Checks are managed in batches, or lots. If you are using prenumbered checks
from the bank, specify the check number ranges in lots.
Check lots are used for both manual and automatic payments, for monitoring
purposes, it is advisable to use a separate lot for each type of payment.

PAYMENT MEDIUM WORKBENCH (PMW)

Tool used to configure and create payment media sent by organizations to their
house bank. It uses the data medium exchange engine (DMEE). In the PMW,
however, these formats are defined outside the payment media program.
Uniformity
Formats can be easily changed without making modifications
New formats can be created
In the Payment Medium Workbench, payment advice notes are created with the
new program RFFOAVIS_FPAYM.

Uniformity
All advice notes output in one print file
Better sort options for advice notes

Note to payee can be defined and assigned according to origin and payment
method in customizing.
Improved performance for mass payment

Conventional
payment media
program RFFO*

1.Changeover to
PMW
2. Define PMW
format

3.Fill note to
payee according
to origin

4.Enter PWM
form
accompaying
sheet

5. Remove
payment media
form
6. Create and
assign selection
variants

CONVERTION
OF A PAYMENT
METHOD TO
PMW

One of the standard payment program is started as usual. After creation of the
payment media has been triggered, the individual payment methods are
processed.

With a PMW payment method, the new Payment Medium Workbench programs
are launched
This first carries out a pre-service. The pre-service processes the data supplied by
the payment run again specifically for the PMW:
The payments are sorted according to PMW format and other format-specific
fields.
Payment groups are created based on the level of granularity (one payment
medium file is usually created later for each group).
The note to payee is formed.
The payment program SAPFPAYM and advice note program RFFOAVIS_FPAYM
are launched based on the data generated by the payment program.
The program RFFOAVIS_FPAYM generates all the required advice notes and the
zero balance notices.
A payment medium format contains carious fields that are filled with content form
SAP system. This process is called mapping and can be carried out in one of two
ways:
1. With programmed function modules: The payment medium format is
defined using tables in which, among other things, the call up points from

the payment medium program are assigned to the suitable function modules
for the format
2. Using the DME Engine: Enables to define file formats that meet the banks
requirements for data medium exchange. This particularly important
because no international or regional standard are defined. Some countries
do not even have their own domestic standards, which means the file has to
follow the banks specific standards. The DMEE lets define new formats
and change existing ones flexibility and easily.
Granularity and Payment methods
Granularity is specified in the definition of the payment medium format and
determines how the payment media are to be output separately in payment
groups. A payment group usually corresponds to one payment file.
At least one selection variant must be defined in the generic payment
medium program SAPFPAYM for each possible payment group.
Granularity can be refined, but no reduced, for the PMW formats shipped with the
system. This because the granularity shipped by SAP is based on the format
requirements (usually specified by the banks).
Note to payee
A PMW payment method is always assigned a PMW format and a content
template for the note of payee.

Every PMW format (with or without supplement) has up to three types of text fields
for reference information:
1. Invoice information (classic note to payee)
2. Internal reference (in case the payment media is returned)
3. External reference (for the business partner)
The contents of the note to payee are defined in a content template, independent
of the format either in customizing or by means of a function module. The content
template supplies information to the reference fields when the payment medium is
created.
DEBIT BALANCE CHECK

In some cases, the payment run can result in payments being made even though
the account has a debit balance.
The debit balance check can be carried out after a payment proposal has been
created. The check offsets all the due debit items without an incoming payment
method against to proposed payments. If the resulting debit balance or credit
balance is less than the minimum payment amount, the payments are added to the
exception list and the account is placed on a list of blocked accounts.
The relevant accounts remain blocked even if the payment proposal is then
deleted. This means that the payments for the blocked accounts are not made in
the subsequent update run with the same payment run identification. The blocks
are not removed until the proposal is created again with the same identification.
Blocked account can be released manually.
AUTOMATING THE PAYMENT PROCESS

Programs can be scheduled to run periodically using job management or the

schedule manager.

The use of Schedule Manager is to automate periodically recurring activities. The

task list is the element in the Schedule Manager, it presents a collection of
activities to be carried out over a period of time. The system provides a set of
instructions to help to create tasks.
Different types of tasks in the task plan:

Program with variant

Notes
Transaction
Process definition

Use the Schedule Manager and program scheduling functions for payment
process.

AUTOMATIC DUNNING
DUNNING RUN OVERVIEW

By entering parameters in the dinning program, specify how it is run. Also use the
parameters of an existing dunning run and adjust the dates.
During the dunning run, the system chooses the accounts and checks them for
items that are overdue. Finally, a check is made whether reminders have to be
sent and dunning levels are allocated. All dunning data is saved in one dunning
proposal.
The dunning proposal can be edited, deleted and re-created as often as required
until the accounting clerk is satisfied with the result.

(Possible to skip). After the dunning run has been completed, available print out
the dunning notices immediately.
In just one step, dunning notices are printed and dunning data is updated in the
master records and associated documents.
DUNNING PROGRAM CONFIGURATION

Most of the settings for dunning program are set in the dunning procedure which
can be accessed directly through the user side of the application.
Dunning procedure
It controls how dunning is carried out. Every account that is to be included in the
automatic dunning process needs to have a dunning procedure. One-time
accounts also have a dunning procedure that is valid for all one-time customers.

Dunning
procedures
Dunning
levels

Environment

Dunning
Categories
Expenses /
charges

Dunning texts

Minimum
amounts

During the dunning run, the system checks whether the run date is at least this
number of days after the date of the last dunning run. If this is not the case, a new
dunning note cannot be created.
This even applies if new items have become overdue in this account, or if the
dunning level of the items has changed. The number of dunning levels represents
the highest dunning level that is possible in this procedure.
The minimum days in arrears (account) are the days that at least one item in the
account must have. Otherwise, the account is not dunned. An item whose number

of days in arrears is less than or equal to the number of grace days is not
considered due for this dunning notice.
For each dunning process, define:

The key for the dunning procedure to be used

A description of the dunning procedure
The dunning interval days
The minimum days in arrears (account) after which a dunning notice will be
sent
Grace periods per line items
Interest calculation indicator for calculation of dunning interest
Dunning letter even if account balance is positive

Maintaining Dunning levels

Minimum number of days, referring to the due date of net payment, to reach
a certain dunning level (line item grace period as 1st. dunning level)
If interest is to be calculated
Print parameters
Optional, get a dunning notice although no further accounts movements
occurred

The minimum number of days in arrears is set as a default in the system: The
system proposes the Line Item Grace Period as the first dunning level. For all
further dunning levels, the system adds the dunning interval in days to the days in
arrears of the previous dunning level. For each dunning level, you can specify that
interest is to be calculated. If you choose the Always Dun option, dunning notices
are printed even if the dunning proposals have not changed since the last dunning
run. A dunning proposal is considered changed if it fulfills at least one of the
following criteria:
At least one item has reached a different dunning level
A new item was added to the dunning notice
The dunning level of the account was changed
You can enter a number of days if a payment deadline for payment of the overdue
items is to be specified in the dunning notice. This number is added to the issue
date of the payment run. The result is the payment deadline. You can print a
dunning notice in a legal dunning procedure, even though no further account
movements have occurred.

Expenses/charges
Dunning charges are defined for each currency and depend on the dunning level.
Can use the word processing features to print these charges on dunning forms.
The dunning charge can be either a fixed amount or percentage of the dunned
amount. If is defined a percentage, cannot enter a fixed dunning charge at the
same time. You can set a minimum at each dunning level.
Dunning charges depending on the dunning level:

Can be either a fixed amount of or a percentage of the dunned amount

Set a minimum amount for the dunning charges (each dunning level)

Minimum amounts
If the minimum amount for the overdue items is not reached in a dunning level, the
items in this dunning level are assigned to the next lowest level and the system
checks whether a dunning notice can then be created in this dunning level.
If it is specified a minimum percentage, the limit must also have been reached or
exceeded.

Minimum amount or percentage of the overdue items to reach a dunning

level
Minimum amount required before interest is calculated for each dunning
level

Dunning Texts
The dunning program can generate payment advice notes, dunning notices, and
payment forms.
It maintain the name of the form that will be used at each dunning level. The
dunning program can generate payment advice notes, dunning notices, and
payment forms.
Environment
In the Company Code Dunning Control screen, you can specify whether dunning
notices are to be created separately by dunning area rather than by account for a
company code.

Company
code
data

Sort
fields

Sender
details

Dunning
areas

Dunning
keys

Dunning
block
reasons

Interest

Dunning
grouping

A dunning area is an organizational entity, that is, a substructure of a company

code that is responsible for dunning. In contrast to standard dunning, where all
items at all dunning levels are dunned with one dunning notice, you can choose to
use a separate dunning notice with a different accompanying text for each dunning
level in an account.
Standard texts have to be assigned to a company code and (optionally) a dunning
area. A dunning key determines that the line item can only be dunned with
restrictions or is to be displayed separately on the dunning notice.
A dunning block prevents accounts and items from being dunned. You can
maintain the interest rate to be used to calculate for the interest due on debit
balances.
PARAMETERS FOR THE DUNNING RUN

Maintain parameters
Every dunning program run is identified by the following two fields:
1. Run date: it does not have to be the actual date when the program is
executed, but this is recommended. Its main purposes is to identify the
program run
2. Identification: is used to differentiate between programs that have the
same run date.
The parameters provide the dunning program with information on the dunning run.
Open Item Selection
With the parameters, tell the dunning program which documents and accounts in
which company codes it should examine for overdue items. Also activate
additional log, which can check after the dunning run to see whether the run was
successful. Use this log for testing and training purposes only since it requires a lot
of system resources.

THE DUNNING RUN

It creates a dunning proposal that can be edited, deleted, and re-created as often
necessary. If necessary, allows print out the dunning notices directly after the
dunning run. In this case, decide not to edit the dunning proposals.

The dunning run can be divided into the three steps above for more clarity.

Account Selection

Dun Line Items

Dun Accounts

The program checks which

accounts shall be considered
in the dunning run according
to the parameters and config.
If the acc. fulfill w/the
criteria, are included in
dunning run. Otherwise, are
ignored.

The system checks which line

items are overdue in the
selected accounts and which
dunning level should be
applied
It items are overdue but
there is a dunning block in
the item, teh system adds
these items to the blocked
items list.
Each dunning procedure
contains up to nine dunning
levels

The system checks whether

payments have to be dunned
for an account and, if so,
which dunning level should
be used
If payments have to be
dunned for an account, but
the account contains a
dunning block the system
adds the account to the list of
blocked accounts.

Criteria:
Dunning procedure must be
entered in the master data
The date of the last dunning
run entered in the acc. must
be earlier than the dunning
interval date of the dunning
procedure

Due dates for Receivables and credit memos

Receivables are due at the due date for net payment. Usually the payment terms
of a credit memo do not apply. Instead, the following rules are valid:

If a credit memo is invoice-related, it has the same due date as the

invoice
All other credit memos are due at the base line date.

If you want the payment terms in a credit memo to apply, you have to enter V
in the Invoice reference field.
Clearing with credit memos or vendor items
The due net debit items on the account are cleared with the due net credit items.
The credit items are assigned to the debit items with the highest dunning level and
are cleared with these items.
Clearing between customer and vendor, the due net credit items in the vendor
account are also cleared with the items with the highest dunning level. The same
dunning procedure must be defined for both (customer and vendor).
General check: after all the due debit items have been cleared with the due net
credit items, the account must have a debit balance for it to be dunned.

Dunning letters are created regardless of the account balance. In any case, the
total of overdue items for each dunning notice must be in debit; otherwise no
dunning notice is generated. The dunning notice lists all the items that were
cleared.
Dunning Dates
The difference between the due date and the dunning date is the following:

Due date: Day by which the liabilities should have been paid
Dunning date: Day when the overdue items are dunned

Every dunning item must be overdue, but not all overdue items are dunned.
Usually all items which are overdue at the date of issue have to be dunned. If line
item grace periods have been defined in the dunning procedure, only those items
that are still overdue after the grace days have been deducted are dunned.
Dunning block
If items are overdue but there is a dunning block in the item, the system adds these
items to the blocked item list.
If payments have to be dunned for an account, but the account contains a dunning
block, the system adds the account to the list of blocked accounts.
Payment method in the item or account
If a payment method for incoming payments has been specified for an item, the
item is usually not dunned because the payment program is responsible for
collecting the money. These items are only dinned if they have a payment block.
If payments for accounts are to be dunned, a payment method for incoming
payments is specified in the master data, the system usually does not dun them
because the payment program is responsible for collecting money. These accounts
are dunned only if they have a payment block.
Dunning levels for line items
Each dunning procedure contains up to nine dunning levels. The dunning notice
wording is usually influenced by the dunning level. The higher the dunning level,
the stronger the formulation in the dunning text.
Each item to be dunned is assigned a dunning level according to its days in
arrears. For invoice-related credit memos, the dunning level of the invoice is used.

From one dunning run to another the dunning level can only be raised by one, that
is, no dunning levels can be skipped.
Payment reminders: Dunning procedures with only one dunning level are referred
to in the system.
Dunning keys: By assigning dunning keys to certain items, to prevent these items
from exceeding a certain dunning level.
Minimum amounts per dunning level
The total amount of all the items in an account with a certain dunning level must be
greater than a defined amount. The relationship between the total amount and the
total open items must be greater than a minimum percentage.
The account can only be dunned if at least one item has reached the minimum
days in arrears per account. If this is not the case, the items are set to a lower
dunning level.
The account can only be dunned if at least one item has reached the minimum
days in arrears per account.
Dunning level in account
The account gets the highest dunning level of all the items to be dunned. If all
items are dunned with ONE dunning notice, the dunning text is worded according
to highest dunning level. Note that the dunning levels are not yet entered in the
items or accounts. This happens later when the dunning notices are printed. At this
point, the dunning levels have already been determined.
Dunning requirements
After it has determined the dunning data, the system checks whether dunning is
really necessary. Normally, it is not necessary to send a dunning notice if the
dunning data has not changed since the last dunning run. This means that an
account is only dunned if one of the following conditions is fulfilled:

The dunning data has changed since the last dunning run
The always dun (?) check box has been selected for the dunning level.
(usually selected for the last dunning level and for payment reminders, -only
one dunning level-)

Accounts in a legal dunning procedure are subject to different rule. If the start date
of the legal dunning procedure is entered in the account master data, the account
is always dunned if one of the following conditions is fulfilled:

Postings have been made since the last dunning run

The always dun in legal dunning procedure indicator is selected

In legal procedures is not sent a dunning notices. The system does not send any
dunning notices to a customer with legal dunning procedure, even if the dunning
data has changed. It does not make any sense to send a dunning letter to a
customer who has obviously not responded to any previous dunning notices. The
Always Dun in Legal Dunning Procedure field should be selected to prevent any
open items that were posted before the start of the legal dunning procedure from
being overlooked.
EDITING THE DUNNING PROPOSAL

After the dunning proposal has been created, it can be edited by a clerk. To
support the clerks work, the following list can be printed:

Dunning statistics
Dunning list
Blocked accounts
Blocked items
Dunning history

If a dunning proposal is not to be used for printing, it must be deleted.

Otherwise, it blocks the selected items for processing in other dunning runs.
A sample printout can be made or displayed on screen. The changes to the
dunning proposal are saved. If a dunning proposal is not to be used for printing, it
must be deleted; otherwise it blocks the selected items for processing in other
dunning runs.
The clerk can:

Block an account in the current dunning proposal or remove the dunning

block
Block a line item in the current dunning proposal or remove the dunning
bock
Lower the dunning level of an item in the current dunning proposal
Change the dunning and correspondence data of an account in the master
record (this change does not apply to the current dunning run)
Change a document (this change does not apply to the current dunning run)

Only the changes in the dunning proposal apply to the current dunning run. The
dunning level can be raised or lowered as required in the master data and
documents

PRINTING DUNNING NOTICES

This function is to create dunning notices to be sent to the relevant business

partners. If the dunning notices are to be sent to one-time customers, the dunning
data is updated only in the relevant items.
Dunning items are printed in a sequence defined by sort criteria.

Group items to
be dunned qith a
dunning notice
according to
various rules

PRINT PROGRAM
(DUNNING
PROCEDURE)

Generates a
dunning notice
for each group

Enters the
dunning date and
level in the
dunned items
and accounts

Group items in dunning notices

Items that are to be dunned are grouped together in dunning notices as long as
they have the same:

Company code
Dunning are (if dunning areas are used)
Account

Items in one-time account are grouped together in one dunning notice if they have
the same address. The items in a dunning notice are sorted according to various
sort criteria. Also can group items by the following criteria:

Dunning by dunning level (separate dunning letter for each dunning

level):In this case, the text for the dunning notice is selected according to
the dunning levels of the group items.
Grouping key: enter a grouping key in the customer/vendor account to
group items in dunning notices that have the same values in the fields
assigned to the grouping key.

Decentralized processing: If it is selected in the branch accounts, dunning

is processed locally, that is, the notices are sent to the branch offices. If
customer has a head office with several branch offices, items are posted to
the central account.

Special Grouping
Use cross-company code dunning to combine overdue items from different
company codes in one dunning run. The overdue items from one customer that
exist in different company codes are dunned with one dunning notice. The items
are grouped according to predefined rules. This means is not necessary to send
the customer separate dunning notice for each company code.
If you want to dun different company codes at the same time, you have to assign
the relevant company codes to a shared dunning company code. If a date for the
legal dunning procedure has been specified for an account in the dunning
company code, this also affects the dependent company codes.
Data in the dunning text element: The dunning interest depends on the dunning
level and is calculated using an interest indicator. Minimum amounts for interests
can be used. To prevent the payment deadline from falling on a holiday, a public
holiday calendar ID is assigned to the dunning procedure. The total of all due items
from a specified dunning level is calculated and can be used in the dunning text.
All items are generally printed at higher dunning levels to provide customer/vendor
with an overdue of the overall account balance. Items with block or collection
method are not displayed. Items with special dunning keys can be printed
separately.
The dunning charges depend on the dunning level and can be either a fixed
amount or percentage of dunned amount. A minimum amount for the dunning
charges can be set.
The payment form can be attached to the dunning notice or printed a separate
page. The dunning notice must only contain items with the company code
currency. The payment program can create a payment advice note containing the
items in the dunning notice.

CORRESPONDENCE
CORRESPONDENCE OVERVIEW

There are various types of correspondence in the system. Periodic

correspondence is triggered be specifications made in the master record, such as
invoices and account statements. The interval is specified in the customer/vendor

master record. You can create correspondence online when you process payments
manually and from the line item display.
There are many opportunities to generate correspondence ad hoc:

Document creation
Display/change line items
Balance display
Line item processing
Payment

And automatically generate:

Periodic bank account statements

Balance confirmation

To create correspondence online, process payment manually and from the line
item display. The correspondence creation process comprises the following steps:
1. Request the required correspondence: The system initially only notes
internally which correspondence types are to be created.
2. The requested correspondence types are printed: Typically,
correspondence is printed automatically with a particular frequency. In
certain cases, it is possible to print certain correspondence type individually
and on demand.
The print request is sent to the spool system. Following this, the correspondence is
printed on the selected printers.
CORRESPONDENCE TYPES

It represents a type of form letter in the SAP system. Must be created for each type
of correspondence is desire.
Standard correspondence types:

Payment notice (SAP01)

Account statement (SAP06)
Individual correspondence (SAP10)
Open item list (SAP14)
User-defined

The correspondence types can be selected by the user when processing business
transactions or are used automatically according to rules defined by the user or the
system. Define the following information for correspondence types:

The required information

o Account number
o Document number
If additional text can be added to the form
If the correspondence can be used across company codes
o Establish intercompany relationships with correspondence company
code
The number of date fields required

Data from several company codes can be combined in one letter. For printing
correspondence consider:

Each correspondence type has a corresponding print program

Each print variant has a selection variant:
o Contains parameters to generate the desired correspondence
o Used when creating correspondence automatically
Each program is assigned a from

A suitable print program and selection variant are defined for each correspondence
type. The selection variant is used to print the requested correspondence. Define
the form that the program is to use to create the correspondence. A
correspondence type can have several different from letters. The individual forms
are distinguished by their form ID.
Linking correspondence types with transactions, it specify which correspondence
types can be used in conjunction with various online functions.
Make your specifications dependent on the company code. If no entry exists for a
company code, the correspondence types specified without a company code are
offered.

Linking correspondence types and reason codes, for the different tolerance groups,
specify the default correspondence type in cases of payment differences.
If you want to always issue the same type of correspondence, enter the
correspondence type in the Message Required field. If you want to choose the
correspondence type during payment settlement, leave the field blank.
If you are using different types of correspondence depending on the reason code,
select the According to Reason Code checkbox.
A payment notice is only created according to reason code as long as all of the
reason codes carry the same correspondence type. If reason codes occur with
different types of payment notice defined for the tolerance group is sent. If the
reason code occur with allocated payment notices, the system again uses the
tolerance group to determine the type of payment notice.
However, if a document has several line items, some of the line items may have
different reason codes and associated correspondence types. In this case, the
automatic payment notice cannot be sent according to the reason code because
the system does not know which correspondence type to choose. As a result, it
uses the payment notice assigned to the tolerance group, independent of the
reason codes.

CLOSING PROCESS
MONTH END AND YEAR END CLOSING PROCESSES

Pre-closing activities that begin in the old month include:

Technical open new accounting period (FI)

FI Enter accruals and deferrals, process recurring entries and bad debt
expense in AR, post depreciation and interest expenses in asset accounting
MM Maintain GR/IR clearing account, post material revaluations
HR Post payroll expenses
SD Post goods issues for deliveries to customers
Technical Close old month in (MM), close subledgers (FI), preliminary
close of the G/L (FI)

Closing activities for external purposes include:

FI Foreign currency valuations
Technical Final closing of the old period
FI/CO Creating external and internal reports

FINANCIAL STATEMENTS
FINANCIAL STATEMENT VERSIONS

It is used in the structured balance list, drilldown reporting, planning, and

transferring data to consolidation. It enables to configure the report format.
Determine the following:

Which items are to be included and the subsequence and hierarchy of these
items
The text describing the items
The charts of accounts and the individual accounts relevant to the report
The totals to be displayed

Define a financial statement version in two steps:

1. Enter it in the directory of financial statement versions
2. Define hierarchy levels and assign accounts
Each version must have the following special items:

Assets
Liabilities
Profit

Loss
P&L results
Accounts no assigned
Notes to financial statement

In addition, the report lists the accounts that were not assigned to an item in the
financial statement version under the item Non-assigned Accounts. A financial
statement version consist a maximum of 20 hierarchy levels.
a) Assign items to each level. The system calculates a total/subtotal for each
item, which is the displayed when the program is run
b) Assign texts to each item
c) Assign the accounts whose balance and account name are to be listed to
the lowest levels
You can write additional texts for each item in a financial statement. The texts for
the financial statement versions are translated. You can output graduated totals in
the profit and loss part of the structure in the standard system using this function.
The system allows use account group assignment to determine in which cases the
balance of a specific account group is to appear in specific financial statement
item. The balance will always appear here irrespective of whether the balance of
the accounts is a debit or credit. You maintain the profit and loss statement
hierarchy in the same way as you maintain assets and liabilities in the balance
sheet.
DRILLDOWN REPORTING

Is a tool that enables to analyze G/L account transaction figures and financial
statements. It make navigating through the data simple. Also provide functions for
processing lists, such a sorting, conditions (threshold values), ranking lists, etc.
Characteristics and key figures form the basis of the drilldown report presentation.
Characteristics define how the data can be classified or provide a time reference.
Key figures include stored values or quantities and calculations based on these
values and quantities, in G/L drilldown reports:

Characteristics can include company, company code, business area,

segment, profit center, chart of accounts, financial statement item, currency,
fiscal year period, and so on.
Key figures can include total credit balance, total debit balance, balance
sheet value, accumulated balance, balance carry forward and so on.

Each report consist of a number of lists that are dived into two categories
according to their content:

Drilldown lists: display a selection of key figures in combination whit at

least one characteristic for number of drilldown characteristics.

Detail list: always shows all the key figure and characteristic combination for a
single combination of drilldown characteristic values.

RECEIVABLES AND PAYABLES

BALANCE CONFIRMATION

At the beginning of the fiscal year, the balance carry forward program is run,
carrying forward the balances of the customer accounts to the next fiscal year. The
posting periods of the old fiscal year are blocked and the special periods for closing
postings are opened. A technical reconciliation guarantees that the posting of
document is technically problem-fee.
The balances are then confirmed, the foreign currency documents valuated, the
values adjusted, and the receivables regrouped. Once complete, the special
periods can be closed. Balance confirmations are generated, foreign currencies
valuated and receivables regrouped in the same way as in accounts payable
accounting.
Balance confirmation
The program for creating balance confirmations automatically creates balance
confirmations (including reply slips) for a freely definable number of customers and
vendors, as well as a reconciliation list and a results table. The customers or
vendors check the balance information they receive and send their reply to the
control center. Here, the replies are compared with the reconciliation list and the
results entered in the results table.
Procedures:

Balance confirmation
Balance notification
Balance request

For each company code, the reports output a checklist and error list. Use these to
check the receipt of balance confirmations. In the error list, the report logs the
errors that occurred during the evaluation.

You must specify at least one address to which balance confirmations should be
sent.
FOREING CURRENCY VALUATION

You carry out the foreign currency valuation before you create the financial
statements.
Determining the valuation difference:

Proposal list
Valuation at balance sheet key date + reversal
Valuation at balance sheet key date with delta posting logic

The foreign currency valuation includes:

Foreign currency balance sheet accounts

Open items posted in foreign currency

The posting document generated by the foreign currency program is

reversed automatically with the same program, on the first day of the next
month. A foreign currency valuation is necessary if vendor accounts contain open
items in a foreign currency. The amounts of these open items were translated unto
the local currency at the time were entered using the current exchange rate. The
exchange rate is probably different at the time of closing, and open items need to
be valuated again.
A valuation cannot be made by a posting to the payables account, since
reconciliation accounts cannot be directly posted to. A valuation method
determines how the individual line items are valuated.
A program valuates the open items using the new exchange rate and enters the
valuation difference in the valuated line items.
It also creates the valuation posting:
Expense from currency valuation to adjustment account for foreign currency
A valuation cannot be made by a posting to the payables account, since
reconciliation accounts cannot be directly posted to. For this reason, the amount is
posted to an adjustment account which appears in the same line if the balance
sheet as the reconciliation account.
A valuation method determines how the individual line items are valuated. This has
to be set up in conjunction with the country-specific valuation regulations.

Valuation of open items

The above accounts show the posting transactions when valuing items in foreign
currency. In the period that the valuation is performed (as defined by the key date),
a posting is made to adjust the overall receivables balance for the change in
exchange rates. The posting is reversed in the next period, to bring balances back
to the original position. A subsequent valuation or the payment clearing is the
based on the original posting. The adjustment posting is made on the key date as
usual, and then reversed on the following day. The user however define another
posting date.

For valuation run run to function, must enter a valuation area (For FI)
This area must be defined in customizing and be assigned a valuation
method
o Valuation method defines, as before, how/with which valuation
approach (such as the lowest value principle) the valuation is carried
out.
Mandatory for balance valuations and/or if there are several new G/Ls/not
mandatory (but still ok) for OI valuations of ONE ledger: Linking the
valuation areas with an accounting principle.

The valuation areas to define should not be confused with the depreciation areas in
Asset Accounting. These are the original FI valuation areas.
Valuation method
It contains the valuation approach to be used for carrying out a foreign currency
valuation as part of closing operations. In a valuation method, make the following,
general specifications for the foreign currency valuation:

The valuation procedure to be used.

How the exchange rate differences determined should be posted.
The basis on which exchange rate should be determined

Also define which valuation method will be used for each valuation area in
customizing. To carry out foreign currency valuations in accounts managed on an
open items basis, define entries for: valuated exchange rate gains and losses for
each reconciliation account in subledger accounts. The system posts the account
entries for realized exchange rate differences in foreign currencies during the open
item clearing.
The number range interval is needed to (internally) count the update runs. But the
number of the run is also displayed in the result screen of an update run. Only one

interval per client is defined. The interval has to have number 01 and the number
range should be as large as possible.
For valuation with delta posting: the next valuation run then reverses the total of
the valuation postings for the line items cleared since the last valuation run.
Valuation of foreign currency balance sheet accounts
Depending on the valuation method used and the balance of the foreign currency
balance sheet account, may end up devaluing or revaluing the accounts. Execute
the valuation run with the same selection criteria as many times as it is like. If new
transactions have been posted to the account since the last valuation run, these
are valuated during the current run.
Foreign accounts are valuated by balance. Exchange rate differences in foreign
currency balance sheet are posted to various gains and losses accounts based on
the exchange rate difference key that is enter in the G/L accounts master record.
Define this keys in customizing.

VALUE ADJUSMENTS

The following options are available for creating value adjustments for receivables:
1. You enter individual value adjustments (IVA) as a special G/L transaction E.
2. You use the program SAPF107V Additional valuations to carry out a flat-rate
individual value adjustment.
3. Once you have determined the amount of the value adjustment, you adjust the
flat-rate value by making a manual G/L account posting. The posting record is as
follows: Expense from flat-rate value adjustment to value adjustment.
Doubtful receivables are written off as an individual value adjustment (IVA) during
year-end closing. The special G/L method is suitable for this procedure since the
transaction is entered in the customer account and is also posted to a special G/L
account, individual value adjustments for receivables. Use the tax code that
represents a tax rate of zero percent for the posting.
After have ascertained that the debt is irrecoverable or that the receivable has
been paid, the individual value adjustment is reversed. If the debt is irrecoverable
has been paid, the individual value adjustment is reversed. If the debt is
irrecoverable, the receivable is cleared from the customer account and the amount
is posted to the account for depreciation of receivables. The sales tax is adjusted in
posting.

In Accounts Receivable configuration, you define the debit rate percentage for a
valuation adjustment key and an overdue time period in days. You must also set up
the appropriate adjustment and bad debt expense accounts for doubtful
receivables in the account determination table.
Periodically, you carry out a valuation run to calculate the bad debt expense
posting for overdue items. The valuation run produces a valuation proposal that
you can manually change . The system then makes the adjustment posting for the
relevant key date and the reversal posting for the day after the key date.

REGROUPING

Payables and receivables have to be listed separately in the balance sheet. Since
it is possible for some vendors to have a debit balance, these balances need to be
changed to customer-like vendor accounts prior to creating the financial
statements. In some countries it is also a requirement that payables are grouped in
the balance sheet according to their remaining life.
Both regroupings are carried out using a special program. At the same time, these
regroupings are removed for the first day of the next period, since regrouping are
not necessary for daily processing.
Is allowed change the reconciliation account in the customer/vendor master record
during a fiscal year. This program is also used if the reconciliation account for a
vendor was changed during the year.
Scenario: Your company code has receivables from and payables to a business
partner that:
Is a customer as well as a vendor
Is an affiliated company (for example, another company code in your group)
Non-SAP system:
In the general control data in the customer and vendor master data, define the
same company ID in the Trading Partner field.
We recommend that you define an alternative reconciliation account in the master
data (receivables from, payables to affiliated companies).
You can change the reconciliation account in the customer/vendor master record
during a fiscal year.

ACCRUALS AND DEFERRALS

ACCRUAL/DEFERRAL POSTING

To ensure that expenses are posted to the correct period, enter accrual/deferral
documents, and then reverse them in a later step (collective processing) the
reversal date (indicator) in that document is then regarded as the posting date of
the reversal document.
When is entered the accrual/deferral document, enter a reversal reason. The
reason is noted in the document that is reversed. The reversal reason also defines
whether:

The reversal document can have a different posting date

The reversal document can be comprised of negative postings

Accrual/deferral of expense revenue

Expenses and revenue posted in one period can be often originate in other
periods. For this reason, expenses and revenue have to be accrued/deferred, in
other words, they are distributed to the periods from which they resulted. A
distinction is made between:

Accruals
Economically,
expenses/revenue belong in
the current period and are
only posted to subsequent
period once an invoice has
been received or issued

Deferrals
Expenses/revenue were
posted to the current period
on receipt/issue of an
invoice, bue economically
they belong at least
partially, in a future period

Accruals and deferrals can be manage differently in FI.

Accruals
To create accruals when an expense or revenue is to be received in the future, but
is incurred or earned partly or completely in the current period. The recurring entry
program is suitable for posting accruals, since the exact same amount is posted to
the same accounts in each period.
In each period, the posting record is Expense to other payables (or provisions) it
is posted to the account:

Other payables: Is certain about the reason and amount of the accrual
Provisions: is uncertain about the amount and/or reason of the accrual and
can only estimate it

In each period in which carry out accruals, the credit balance on the account other
payables or provisions increases.
THE ACCRUAL ENGINE

Is a generic tool for calculating and creating accrual postings. As input it receives
basic data that describes the subject matter to be accrued. The accruals engine
uses this data to calculate the accruals and creates the related periodic postings.
The user works with the application components of the Accrual Engine. The
subjects to be accrued are entered there and are forwarded to the Accrual Engine.
SAP develops and delivers the application components of the Accrual Engine.
They cannot be developed by customers.
The accrual engine is used amongst other things for:

Manual accruals in financial accounting

Provisions for awards
Lease accounting
Intellectual property management

Additional application components will be delivered in future extensions.

The accrual engine stores two types of data:

1. Basic data: consist a description of the subject to be accrued (accrual
object) and all other information required for carrying out the accruals. Basic
data is time-dependent

2. Accrual engine documents and totals records: all accruals postings

creates documents in the accrual engine (accrual engine documents) and
update fiscal year-specific totals records. The accrual engine documents
automatically create corresponding documents in FI. Various levels of
summarization are possible. If errors occur during FI update, trigger this
manually.
Usually, two main processes are triggered from application component:
1. Create/change basic data: depending on the customizing settings, an
opening posting may be made immediately
2. Periodic start of the accrual run: or reversal of an accrual run

Advantages of Accrual Engine

An info system gives you direct access to totals records and documents in the
accrual engine. Also carry out accruals simulations.

Automatic calculation of accruals

Recurring entry documents with

fixed values no longer needed

Automatic periodic postings (selfadjusting)

Supports parallel reporting

Extensive inforamtion system

Application components are

delivered by SAP and do not have
to be created by the customer

Active the application component

Assign application components to the company codes that are to use them
Define accounting principles (is not already done)
Assign application components to the required combinations of accounting
principles/company code

Open the fiscal year for the required application component (usually
previous and current fiscal year)

To activate an application component of the accrual engine, carry out the following
customizing activities:

The application component must be assigned to the company codes that

are to use it
The required accounting principles must be defined if this has not already
been done
The application component must be assigned to the required combination of
accounting principle and company code
The current fiscal year must be open for the application component

Closing activities of
the accrual engine

Reconciliation: Accrual Engine/General Ledger

-Accrual Engine documents and G/L documents are reconciled with one another
check whether the transfer to the general ledger was completed without errors
Balance carry forward
-At the end of the fiscal year, have to carry froward the balances of the accruals
objects into the next fiscal year. This has nothing to do with the balance
carryforward in the G/L

MANUAL ACCRUALS

This application component allows create the basic data manually via a simple
user interface. The basic data is usually subject matter to be accrued based on
different contracts, such as rental agreements, insurance contracts, and so on.
Create a deferrals when an expense or revenue is posted in the current period,
but is incurred or earned partly or completely in the future. Create accruals when
an expense or revenue is to be received in the future, but is incurred or earned
partly or completely in the current period.
The posting record for accruals is Expense to other payables or provisions in
each period. It is posted to the account. When the invoice is finally received, it is
posted as other payables or provisions to vendor. The other payables are thereby
converted into real payables.
The subject to be accrued is defined as an accrual object. You make this definition
manually in the application component Manual Accruals. Accrual objects in this
application component are identified uniquely for each company code using an
accrual object number from a defined number range. The accrual objects are
grouped in accrual object categories for manual accruals. These summarize the
subject matter of similar accrual objects.

Use accrual object categories:

As a navigation level to find accrual objects more easily

To assign special customer-defined parameters that describe the accrual
object in more detail

Each accrual object can have several accrual items. An accrual item describes
how a related accrual type (usually costs or revenues) is accrued using a specific
accounting principle.
Accrual calculation
The accrual is calculated for each accrual item, for each combination of accrual
type and accounting principle specified. In addition to the amount to be accrued
and possibly also a quantity to be accrued, the accrual item contains an accrual
method.
A function module is defined for the accrual method, and this calculates the
accruals. For the manual accruals area, several function modules are delivered.
POSTING CONTROL AND ACCOUNT DETERMINATION

Is defined for each:

Company code
Accounting principle
Accrual type

Define

How frequently accruals are carried out

Level of summarization for postings before the update to FI make the
following settings:
o No summarization: a separate line item is created for each accruals
item
o Summarization at accrual object level: a line item is created for each
accrual object
o Maximum summarization: the postings are summarized to the level to
different additional account assignments

The purpose of account determination is to:

Determine the document type

Determine the debit account
Determine the credit account

For each accrual type, you define in Customizing which postings are to be made
automatically and, therefore, for which postings account determination is required.
None (the accruals are calculated in the Accrual Engine, but not posted)
Only the opening posting
Only periodic postings (useful, for example, for accruals)
All (opening posting, periodic accruals, and - if the accrual object is terminated
prematurely - a closing posting)
For parallel accounting, the Accrual Engine supports
Parallel accounts
Parallel ledgers
Accounts are determined using derivation rules. This rules consist of:

Conditions under which the derivation rule is executed (optional)

Determination of fields used in the derivation rule
o Source fields
o Target fields
The rule entries themselves that derive the input for the target fields from
the content of the source fields

Account determination rules

The derivation rules are summarized in a set of rules. Depending on how the
derivation rules are defined, they are processed either in parallel or sequentially.

Parallel derivation rules are processed sequentially and determine

independent results
o For different accrual objects that can be differentiated by means of
user-defined parameters. In the conditions, the system queries the
content of the user defined parameters and the derivation rule is only
executed if the condition is fulfilled
o For different elements of the accounting document, that is, one rule
for the document type, other rules for the accounts.
Sequential derivation rules must be created in the correct order, because
their results are cumulative.
o For account determinations with different levels of detail, that is, the
first derivation rule provides a very basic account determination, the
second a more detailed account determination for other transactions

o Use of extended account determination. Using the extended account

determination can summarized combinations of source fields with a
derivation rule for characteristic combinations. In a second derivation
rule, account symbols are determined from characteristics
combinations. In a third derivation rule, the accounts are derived from
the account symbols.

TECHNICAL, ORGANIZATIONAL, AND DOCUMENTARY STEPS

TECHNICAL STEPS

At the beginning of the fiscal year, the balance carried forward program is run,
carrying forward the balances of the G/L accounts to the next fiscal year. The
posting periods of the fiscal year are blocked and the special periods for closing
postings are opened. A technical reconciliation between transaction figures and
documents guarantees that the posting of documents is technically problem-free.
The system calculates the balance carried forward to the new fiscal year for each
balance sheet account. As of version 4.6C: You can display the balances of
individual P&L accounts that are carried forward to a specific retained earnings
account. This enables you to understand how the total balance of the retained
earnings account is made up.
Foreign currency documents are then valuated, accruals are carried out , and
GR/IR clearing accounts are analyzed, including regrouping of the balance. Once
complete, the special periods can be closed. The system calculates the balance
carried forward to the new fiscal year for each balance sheet account.
The system uses the posting date that specify during document entry to determine
to which posting period the document is posted.
The posting periods for your company are defined by the fiscal year variant. The
posting periods table is used to open and close posting periods.
You can have as many or as few posting periods open as you want. The next
column contains the account type. Account types include + for all accounts, A
for assets, D for customer accounts, K for vendor accounts, and S for G/L
accounts. This allows you to control the open posting periods by account type.
Accounts are open for the periods specified in the table and closed for periods not
specified. The line with account type + (valid for all accounts) determines the
maximum length of the open periods for an account type. You can assign an
authorization group to the periods open.

Activated Real-Time Integration of Controlling That means that the CO transaction

can only be executed successfully if the respective FI period is open. But at least
during period close the Controlling department typically has to post in periods,
which are already closed in FI. To minimize coordination time, SAP invented the
period interval 3. It controls the postings to FI which are triggered in CO.
Technical Reconciliation
The report carries out an extended reconciliation in Financial Accounting. As part
of general ledger month-end closing, the following consistency checks are
performed:
1. Debit and credit transaction figures for customer accounts, vendor accounts, and
G/L accounts (table FAGLFLEXT) with the debit and credit totals of the posted
documents (table BSEG).
2. Debit and credit transaction figures for customer accounts, vendor accounts, and
G/L accounts (table FAGLFLEXT) with the debit and credit totals of the application
index (secondary index tables BSIS/BSAD, BSIK/BSAK, BSIS/BSAK).
The application indexes are used for the general ledger view of accounts with open
item management or line item display.
All the results of the reconciliation are added to historical management.
DOCUMENTARY STEPS

Legislation usually stipulates that it is must possible to explain account balances at

any time for more than one fiscal year using the relevant document items. This is
possible while the relevant documents are still stored in the system. Starting
balance audit trail before archived any documents , generates the compact journal
for a period in the form of a list. The balance audit trail displays the balance at the
beginning of a period and the changes to the account period to the period end.
LEDGER GROUP POSTING

Parallel financial reporting means that the financial statements for a company must
be created in accordance with different accounting rules. This is because a local
view is no longer sufficient by itself in a globalized world if creditors and business
partners. An internationally respected standard is in increasing demand.
Different accounting rules can (still) be modelled using the account-bases solution
in the new G/L. in addition to accounts, New G/L let use different ledger to save the
different valuation approaches-this is called ledger solution. SAP generally
considers the ledger solution and the account-based solution as equivalents.

A change of the leading view should always be dealt with in a separate project, as
before. The leading ledger is the (only) ledger that is integrated with CO. However,
a new ledger group is created automatically for each ledger in the new G/L. This
new ledger group contains the relevant ledger and has the same name as it. The
document is then only posted to the selected ledgers.

FINANCIAL CLOSING COCKPIT

FINANCIAL CLOSING COCKPIT

Various persons
responisble
Process flow
deined
chronologically (or
by determined by
dependences)

Recurring periodic
tasks

Documentation of
status of all
periodic activities

Advantages
Closing
Cockpit

Same uniform
interface for all
users involved

This support function enables to create a structured interface executing

transactions and programs that form part of complex processes, such as closing
processes. The structural layout supports processes within an organizational
structure, such a company code, as well as scenarios affecting multiple
organizational structures. SAP provides with the SAP Financial Closing cockpit
web access to the closing tasks and related files for all users associated with the
close.
Parallel processing of process chains in combination with cross-system, crossclient, and very important while reducing the overall amount of down-times and
increasing the level of automation tremendously The financial closing cockpit can
be used as an application tool in the following cases in particular:

Activities recur periodically

More than one person responsible may be involved

Activities are performed within a process that has a fixed chronological

sequence or is determined by dependencies
The activities are performed within a process that has a fixed chronological
sequence or is determined be dependencies
Activities need to be supported by a shared, uniform interface for all
involved and available for all involved
The closing tasks are documented for later checks

To support the closing process, the financial closing cockpit offers the following
options:

Hierarchies to display the organizational objects involved in the closing

process
A task list template based on organizational structure
A detail view of the characteristic values of the individual hierarchy levels
used in the task list template
Task lists that are derived from the task list template
A list display in which all tasks to be managed or executed from respective
task list are made available for processing or monitoring tasks progress
A monitor that provides an overview of the sequence of tasks, their status
and dependencies, and critical paths in graphical form
Detailed information for evaluating the technical settings of task as well as
for analysing background programs

Dependencies for displaying the conditions that are prerequisite to

processing the individual tasks

The organizational hierarchy allows you to organize the closing process according
to organizational structures.
The Financial Closing Cockpit can be used once a task list template has been
created and assigned to an organizational structure, tasks have been assigned to
the task list template, and a task list has been derived and released for the
application.
The system generates a proposal for a task list template in accordance with the
selected hierarchies and using all organizational objects available in the system.

PROGRAMS:with program variant

(background processing) standard programs
are generally available for processing
activities in the background. If these program
are include in the task list template with
corresponding parameters, let process online

ONLINE TRANSACTIONS: start these

transactions manually from the task list and
go directly from financial clocing cockpit to
the relevant application transaction

TASK TYPES

NOTE: used as reminder or milestone

FLOW DEFINITION: used for multiple

programs with variants that are be processed
automatically. Such programs are combined
to form a logical flow chain with unique
pedecessor and sucessor relationships

You can now create different tasks in the task folders: Select the task or hierarchy
folder to which you want to assign tasks. When you assign the task to a user as the
person responsible or as the person processing the task, you build the List Display.
To perform programs included in a task list, you need to specify variant values.
SAP NETWEAVER PORTAL offers a single point of access to SAP and non-SAP
information sources. SAP Netweaver Business Client (NWBC) is an SAP user
interface which offers a unified environment to work in the classic SAP GUI-based
transactions and newer web dynpro-based applications.