FINANCE BASIS

Client: In commercial, organizational and technical terms, a self-contained unit in an R/3

System with separate master records and its own set of tables.

Company Code: The smallest organizational unit of Financial Accounting for which a complete
self-contained set of accounts can be drawn up for purposes of external reporting.

Business Area: An organizational unit of financial accounting that represents a separate area of
operations or responsibilities within an organization and to which value changes recorded in
Financial Accounting can be allocated.

Enterprise structure: A portrayal of an enterprises hierarchy. Logical enterprise structure,

including the organizational units required to manage the SAP System such as plant or cost
center. Social enterprise structure, description of the way in which an enterprise is organized, in
divisions or user departments.The HR application component portrays the social structure of an
enterprise

Fiscal year variant: A variant defining the relationship between the calendar and fiscal year.
The fiscal year variant specifies the number of periods and special periods in a fiscal year and
how the SAP System is to determine the assigned posting periods.

Fiscal Year: A period of usually 12 months, for which the company produces financial
statements and takes inventory.
Annual displacement/Year shift: For the individual posting periods various entries may be
necessary. For example, in the first six periods the fiscal year and calendar year may coincide,
whereas for the remaining periods there may be a displacement of +1.

Chart of Accounts: Systematically organized list of all the G/L account master records that are
required in a company codes. The COA contains the account number, the account name and
control information for G/L account master record.

Financial statement version: A hierarchical positioning of G/L accounts. This positioning can
be based on specific legal requirements for creating financial statements. It can also be a self-
defined order.

Account group: An object that attributes that determine the creation of master records. The
account group determines: The data that is relevant for the master record A number range from
which numbers are selected for the master records.

Field status group: Field status groups control the additional account assignments and other
fields that can be posted at the line item level for a G/L account.
Posting Key: A two-digit numerical key that determines the way line items are posted. This key
determines several factors including the: Account type, Type of posting (debit or credit),Layout
of entry screens .

Open item management: A stipulation that the items in an account must be used to clear other
line items in the same account. Items must balance out to zero before they can be cleared. The
account balance is therefore always equal to the sum of the open items.

Clearing: A procedure by which the open items belonging to one or more accounts are indicated
as cleared (paid).
Reconciliation account: A G/L account, to which transactions in the subsidiary ledgers (such as
in the customer, vendor or assets areas) are updated automatically.
Special G/L indicator: An indicator that identifies a special G/L transaction.Special G/L
transactions include down payments and bills of exchange.

Special G/L transaction: The special transactions in accounts receivable and accounts payable
that are shown separately in the general ledger and sub-ledger.

They include:
Bills of exchange
Down payments
Guarantees

House Bank: A business partner that represents a bank through which you can process your own
internal transactions.

Document type: A key that distinguishes the business transactions to be posted. The document
type determines where the document is stored as well as the account types to be posted.
Account type: A key that specifies the accounting area to which an account belongs.
Examples of account types are:
Asset accounts
Customer accounts
Vendor accounts
G/L accounts
Dunning procedure: A pre-defined procedure specifying how customers or vendors are dunned.
For each procedure, the user defines
Number of dunning levels
Dunning frequency
Amount limits
Texts for the dunning notices
Dunning level: A numeral indicating how often an item or an account has been dunned.
Dunning key: A tool that identifies items to be dunned separately, such as items you are not sure
about or items for which payment information exists.
Year-end closing: An annual balance sheet and profit and loss statement, both of which must be
created in accordance with the legal requirements of the country in question.
Standard accounting principles require that the following be listed:
 All assets
All debts, accruals, and deferrals
All revenue and expenses
Month-end closing: The work that is performed at the end of a posting period.

Functional area: An organizational unit in Accounting that classifies the expenses of an

organization by functions such as:
Administration
Sales and distribution
Marketing
Production
Research and development
Classification takes place to meet the needs of cost-of-sales accounting.
Noted item: A special item that does not affect any account balance. When you post a noted
item, a document is generated. The item can be displayed using the line item display. Certain
noted items are processed by the payment program or dunning program for example, down
payment requests.
Accrual and deferral: The assignment of an organizations receipts and expenditure to
particular periods, for purposes of calculating the net income for a specific period.
A distinction is made between:
Accruals -
An accrual is any expenditure before the closing key date that represents an expense for any
period after this date.
Deferral -
Deferred income is any receipts before the closing key date that represent revenue for any period
after this date.
Statistical posting: The posting of a special G/L transaction where the offsetting entry is made
to a specified clearing account automatically (for example, received guarantees of payment).
Statistical postings create statistical line items only.
Valuation area: An organizational unit in Logistics subdividing an enterprise for the purpose of
uniform and complete valuation of material stocks.
Chart of depreciation: An object that contains the defined depreciation areas.It also contains
the rules for the evaluation of assets that are valid in a specific country or economic area. Each
company code is allocated to one chart of depreciation. Several company codes can work with
the same chart of depreciation.The chart of depreciation and the chart of accounts are completely
independent of one another.
Asset class: The main criterion for classifying fixed assets according to legal and management
requirements.
For each asset class, control parameters and default values can be defined for depreciation
calculation and other master data.
Each asset master record must be assigned to one asset class.
Special asset classes are, for example:
Assets under construction
Low-value assets
Leased assets
Financial assets
 Technical assets
Depreciation area: An area showing the valuation of a fixed asset for a particular purpose (for
example, for individual financial statements, balance sheets for tax purposes, or management
accounting values).
Depreciation key: A key for calculating depreciation amounts.
The depreciation key controls the following for each asset and for each depreciation area:
Automatic calculation of planned depreciation
Automatic calculation of interest
Maximum percentages for manual depreciation
The depreciation key is defined by specifying:
Calculation methods for ordinary and special depreciation, for interest and for the cutoff value
Various control parameters
Period control method: A system object that controls what assumptions the system makes when
revaluating asset transactions that are posted partway through a period.
Using the period control method, for example, you can instruct the system only to start
revaluating asset acquisitions in the first full month after their acquisition.
The period control method allows different sets of rules for different types of asset transactions,
for example, acquisitions and transfers.
Depreciation base: The base value for calculating periodic depreciation.
The following base values are possible, for example:
Acquisition and production costs
Net book value
Replacement value

Accounts Receivables Basics

SAP R/3 has a dedicated module FI-AR which is specialized to maintain the accounts receivable
sub-ledger of the FI-GL General Ledger. The accounts receivable module stores its own master
data, transaction data and has its own reporting system. One important point is that both the
general ledger and the AR sub-ledger use the same chart of accounts. Similarly, the master
records are also shared with GL. As a concept, every transaction creates an SAP
document. Document data is immediately posted to the General Ledger. Business transaction
recorded in this way automatically update the balance sheet and the profit and loss statement.
This is one of the most unique features of an ERP like SAP.

SAP FI-AR keep a record of all customer transactions. The three most important functions which
the AR module performs are

- collecting money from customers

- Processing of Cash Receipts
- Dunning for late paying customers
Many times users confuse the SD module with the FI-AR module. Both SD and AR share a lot
of master records and are fully integrated at the software code level. In SAP, transaction data is
stored centrally in the document database. All corresponding line items and details are stored in
the respective subledgers. SAP automatically updates a subtotal of a balance sheet account for
every business transaction and reconciles the account subtotals and the line items to ensure that
the financial information is always correct and current.

SAP R/3 has a dedicated module FI-AR which is specialized to maintain the accounts receivable
sub-ledger of the FI-GL General Ledger. The accounts receivable module stores its own master
data, transaction data and has its own reporting system. One important point is that both the
general ledger and the AR sub-ledger use the same chart of accounts. Similarly, the master
records are also shared with GL. As a concept, every transaction creates an SAP
document. Document data is immediately posted to the General Ledger. Business transaction
recorded in this way automatically update the balance sheet and the profit and loss statement.
This is one of the most unique features of an ERP like SAP.

SAP FI-AR keep a record of all customer transactions. The three most important functions which
the AR module performs are

- collecting money from customers

- Processing of Cash Receipts
- Dunning for late paying customers

Many times users confuse the SD module with the FI-AR module. Both SD and AR share a lot
of master records and are fully integrated at the software code level. In SAP, transaction data is
stored centrally in the document database. All corresponding line items and details are stored in
the respective subledgers. SAP automatically updates a subtotal of a balance sheet account for
every business transaction and reconciles the account subtotals and the line items to ensure that
the financial information is always correct and current.

Controlling Area: An organizational unit within a company, used to represent a closed system
for cost accounting purposes. A controlling area may include single or multiple company codes
that may use different currencies. These company codes must use the same operative chart of
accounts.
Cost center std Hierarchy : Indicated hierarchy of cost center groups in which all cost centers
in a controlling area are gathered together.
Cost element : A cost element classifies the organizations valuated consumption of production
factors within a controlling area. A cost element corresponds to a cost-relevant item in the chart
of accounts.
Primary cost element: A cost element whose costs originate outside of CO and accrual costs
that are used only for controlling purposes

Primary Cost Elements / Revenue Elements:

When creating a primary cost element or revenue element, it must be listed first as a G/L account
in the chart of accounts and defined as an account in Financial Accounting. In other words,
primary cost elements and revenue cost elements require counterparts in FI. When you create a
primary cost/revenue element, the SAP System checks whether a corresponding account exists in
FI.

Secondary cost element: A cost element that is used to allocate costs for internal activities.
Secondary cost elements do not correspond to any G/L account in Financial Accounting. They
are used only in Controlling and consequently cannot be defined in FI as an account.

FI.

Secondary Cost Elements:

Secondary cost elements are used exclusively in Controlling (CO) and need not be defined in FI.
It can be used for internal allocation purpose.

Integration with FI (Financial Accounting):

Cost Elements track the type of costs or spend. They form categories of costs that are
independent from external or financial reporting requirements, but help management to track
costs according to internal accounting policies. The primary Cost Elements are more or less
mirror images (copies) of P&L revenue and expense accounts from the financial chart of
accounts. The integrated mass processing moves (and allocates) costs from primary into
secondary Cost Elements. Those secondary Cost Elements no longer are tied to the accounts
used by financial and tax reporting (chart of accounts).

Cost element category: The classification of cost elements according to their usage or origin.
Examples of cost element categories are:
Material cost elements
Settlement cost elements for orders
Cost elements for allocating internal activities

The Statistical Key Figure (SKF) is used as the basis (tracing factor) for making allocations
(assessments/distributions). They are the statistical data such as number of employees, area in
square meters, etc. You will make use of a SKF when you are faced with a situation where it is
not possible to use any other conventional method or measure to arrive at the share of costs to be
allocated to cost centers.
Suppose that you are incurring a monthly expense of USD 5,000 in the cost center cafeteria, the
cost of which needs to be allocated to other cost centers. You can achieve this by the SKF.
Imagine that you want this to be allocated based on the number of employees working in each
of the other cost centers such as administrative office (50 employees) and the factory (200
employees). You will now use the number of employees as the SKF for allocating the costs.

In SKF allocation, you have the flexibility of using two different SKF Categories; namely,
Total value or Fixed value. You will use fixed values in situations where the SKF does not
change very often, as in the case of the number of employees, area, etc. You will use total values
in situations where the value is expected to change every now and then, as in the case of power
use or water consumption and the like

Reconciliation ledger: A ledger used for summarized display of values that appear in more
detailed form in the transaction data.
The reconciliation ledger has the following functions:
o Reconciles Controlling with Financial Accounting: The reconciliation ledger provides reports
for monitoring the reconciliation of Controlling with Financial Accounting by account.
o It can identify and display value flows in Controlling across company code, functional area, or
business area boundaries
o Provides an overview of all costs incurred : Reconciliation ledger reports provide an overview
of the costs and are therefore a useful starting point for cost analysis. For example, an item in the
profit and loss statement from the Financial Information System (FIS) can be examined in the
reconciliation ledger reports with respect to the relevant costs. For more detailed analysis, reports
from other components within Controlling can be accessed from the reconciliation ledger
reports.

How to Reconcile CO and FI Modules in SAP

The Reconciliation Ledger is a functionality available in the SAP Controlling module which
helps in reconciling CO and FI. In the reconciliation ledger, Controlling CO data is totaled and
valuated. The reconciliation ledger displays data in all CO applications. This data could be for a
cost element, business area, object types, object classes, totals of company codes etc.So how
does the reconciliation ledger reconcile FI and CO records. The reconciliation ledger uses
reconciliation postings for this purpose. Some of the features of reconciliation ledger are given
below:

1. In SAP, external postings to financials which are relevant to cost are automatically transferred
to the corresponding CO application component. SAP automatically executes such transfer in
real time. The CO totals are updated directly so as to enable reconciliation.

2. In case SAP is configured such that amounts are posted directly across company codes,
business area or functional area, the information is to be transferred back to FI. SAP updates
such information in the reconciliation ledger. However, postings have to be manually done in the
financial.

3. Reconciliation ledger can be used to create a posting, to reconcile FI and CO. Apart from this,
the reconciliation ledger also provides some informative reports such as cost analyses, CO P & L
etc.

Reconciliation Account & Special GL Indicator

Cost Center: An organizational unit within a controlling area that represents a defined location
of cost incurrence.
The definition can be based on:
Functional requirements
Allocation criteria
Physical location
Responsibility for costs
Cost center category: An attribute that determines the type of cost center.
Example
F Production cost center
H Service cost center
Controlling area: An organizational unit within a company, used to represent a closed system
for cost accounting purposes.
A controlling area may include single or multiple company codes that may use different
currencies. These company codes must use the same operative chart of accounts.
All internal allocations refer exclusively to objects in the same controlling area.
Statistical key figure: The statistical values describing:
Cost centers
Orders
Business processes
Profit centers
There are the following types of statistical key figures:
Fixed value Fixed values are carried forward from the current posting period to all
subsequent periods.
Total value -
Totals values are posted in the current posting period only
Activity type: A unit in a controlling area that classifies the activities performed in a cost center.
Example
Activity types in production cost centers are machine hours or finished units.
Allocation cost element : A cost element used to illustrate activity allocation in terms of values.
The allocation cost element is a secondary cost element , under which the activity type or
business process is allocated.
The allocation cost element is the central characteristic used in all CO postings. It is therefore
also an important criterion for reporting for example, many reports are structured according to
the posted cost elements.
Assessment cost element: A secondary cost element for costs that are assessed between
Controlling objects.

Reposting: A posting aid in which primary costs are posted to a receiver object under the
original cost element (the cost element of the sender object).
Repostings are used to rectify incorrect postings. The following methods are available:
Transaction-based reposting -
Each posting is made in real time during the current period.
Periodic reposting -
Produces the same results as transaction-based reposting. The costs being transferred are
collected on a clearing cost center and then transferred at the end of the period according to
allocation bases defined by the user.
Distribution: A business transaction that allocates primary costs.
The original cost element is retained in the receiver cost center.
Information about the sender and the receiver is documented in the Controlling document.
Assessment: A method of internal cost allocation by which you allocate the costs of a sender
cost center to receiver CO objects (such as orders and other cost centers) using an assessment
cost element.
The SAP System supports the following:
Hierarchical method (where the user determines the assessment sequence)
Iterative method (where the SAP System determines the sequence of assessment using
iteration).
Example:
The costs from the cafeteria cost center could be assessed based on the statistical key figure
employee, which was set up on the receiver cost center.
Receiver cost center I has 10 employees, receiver cost center II has 90. The costs of the cafeteria
cost center would be transferred (assessed) to receiver cost center I (10%) and receiver cost
center II (90%). The credit on the cafeteria cost center and the debit of the two receiver cost
centers are posted using an assessment cost element. Depending on the system setting, the total
costs or some of the costs for the cafeteria cost center would be
Internal order: An instrument used to monitor costs and, in some instances, the revenues of an
organization.
Internal orders can be used for the following purposes:
Monitoring the costs of short-term jobs
Monitoring the costs and revenues of a specific service
Ongoing cost control
Internal orders are divided into the following categories:
Overhead orders For short-term monitoring of the indirect costs arising from jobs. They can
also be used for continuous monitoring of subareas of indirect costs. Overhead orders can collect
plan and actual costs independently of organizational cost center structures and business
processes, enabling continous cost control in the enterprise.
Investment orders Monitor investment costs that can be capitalized and settled to fixed assets.
 Accrual orders Monitor period-based accrual between expenses posted in Financial
Accounting and accrual costs in Controlling.
Orders with revenues Monitor the costs and revenues arising from activities for partners
outside the organization, or from activities not belonging to the core business of the organization.
Order type: A tool that categorizes orders according to purpose.
The order type contains information which is necessary for managing orders. Order types are
client-specific. The same order type can be used in all controlling areas in one client.
Example
Production orders
Maintenance orders
Capital investment orders
Marketing orders

Cost of sales accounting: A type of profit and loss statement that matches the sales revenues to
the costs or expenses involved in making the revenue (cost of sales).
The expenses are listed in functional areas such as:
Manufacturing
Management
Sales and distribution
Research and development
Cost of sales accounting displays how the costs were incurred. It represents the economic
outflow of resources.

Posting Keys are defined at Client Level.

Posting keys determine whether a line item is a debit or credit as well as the possible field status
for the transaction. In this context, it is essential to understand the factors that determine the field
status of a transaction. The field status within a FI document is controlled by Accout Type, field
status of Posting Key and the field status of the G/L account.

Modifying the SAP delivered Posting keys are not recommended. if a posting key is to be
modified the best possible action is to copy the posting key that needs to be modified and then
modify the copy. we can define the posting keys using the transaction OB41.

It also determines the account type to which the debit or credit is to be made and whether it is Spl
G/L transaction. If it is a Spl G/L transaction, then the field for Spl G/L indicator becomes
required entry.

POSTING KEY Vs. Field Status Group

What is the difference among Account group, Posting key and Field status group in terms
field status?

Account group (in GL accounting)defines:

a. no. ranges of the gl account numbers
b. field status of the GL account master data in the company code segment.(which fields to
appear when you create a gl account) (to controldouble click on your GL account group in
Screen transaction code OBD4)

Posting key defines:

a. whether the line item is a debit or credit

b. to which type of account the amount should be posted to(ex: when you use posting key 40,
you will be able to post to gl accounts. When you use Posting key 01, you will be only able to
post to customer account.
c. document screen layout during posting of a document. (which feilds to appear in a
documentdouble click on the posting key and select field status and make the entries as
required /optional etc)

Field status group defines:

Document screen layout during posting of a document. (which feilds to appear in a

documentdouble click on the field status group and select fields and make the entries as
required /optional etc)

LOGIC: you assign field status variant to the company code, FSV is a bundle of field status
groups.

ex: in FSG G001 you have made the text as required entryyou assigned the field status group
g001 to cash account..so when you use cash account and try to post a document it will definitely
prompt you to enter the text (text made as required.)

Both FSG and PK control the same feilds in a document.There is no dominance between FSG
and Posting keys..but we should know the allowed combinations.

If text is made required in PK and suppressed in FSG..the system will issue a error msg..Rules
for PKand FSG.is set incorrectli for SGTXT field.

Permissable combinations:

Pk R/S O/S R/o R S O

FSG S/R S/O o/r R S O

Result e SD RD NP NP NP

R= required
s= suppressed
e=error
SD= Suppressed dominates
Rd= required dominates
np=no problem.

Regards

Aravind

The system always follows the priority rule Hide (Suppressed)

Display
Required
Optional

Only Hide and Required combination gives error. In all other cases the dominace is always in the
above sequence. If you want to take the FSG dominace, set all fields in posting key as optional.

PARKED & HOLDED DOCUMENT

The Parking of a Document in SAP is one of the two preliminary postings (the other being
the Holding of documents) in the system and refers to the storing of incomplete documents in
the system. These documents can later be called on for completion and posting. While parking
a document, the system does not carry out the mandatory validity checking. The system does
not also carry out any automatic postings (such as creating tax line items) or balance checks.
As a result, the transaction figures (account balances) are not updated. This is true in the case of
all financial transactions except in the area of TR-CM (Cash management) where parked
documents will update the transactions.

The parking of documents can be used to park data relating to customers, vendors, or assets
(acquisition only). When a cross-Company Code document is parked, only one document is
created in the initial Company Code; when this parked document is posted all other documents
relevant for all other Company Codes will also be created. However, it is to be noted that
substitution functionality cannot be used with document parking, as substitution is activated
only on transaction processing.

The added advantage is that a document parked by an accounting clerk can be called on for
completion by someone else. The parked documents can be displayed individually or as a list
from where the required document can be selected for completion and posting. The number of
the parked document is transferred to the posted document. The original parked document, if
necessary, can be displayed even after it has been posted to.
During a transaction when you do not have a piece of required information, you can Hold the
Document and complete it later. As in the case of parked documents, here also the document
does not update the transaction figures

Direct Allocation Methods of Posting in Controlling

The Direct Allocation of posting in CO may be an actual cost entry or a transaction-based

posting.
The actual cost entry is the transfer of primary costs from FI to CO, on a real-time basis, through
the primary cost elements. You may also transfer transaction data by making the cost accounting
assignment to cost objects from other modules such as FI-AA, SD, and MM:

FI-AA: Assign assets to a cost center (to post depreciation, etc.)

MM: Assign GR to a cost center/internal order
SD: Assign or settle a sales order to a cost center or internal order

Note that during actual cost entry, the system creates two documents. When you post the primary
costs from FI to CO, the system will create a document in FI and a parallel document in CO,
which is summarized from the point of the cost object/element.
Transaction-based postings are executed within the CO, again on a real-time basis, enabling you
to have updated cost information on the cost centers at any point in time. You will be able to
carry out the following transaction-based postings in CO:

Reposting
Manual cost allocation
Direct activity allocation
Posting of Statistical Key Figures
Posting of sender activities

Purpose of Defining Internal Orders

An example would help us understand this much better.

Lets say in an organization there are various events such as trade fairs, training seminars, which
occur during the year. Now lets assume for a second that these Trade fairs are organized by the
Marketing cost center of the organization. Therefore in this case marketing cost center is
responsible for all the trade fairs costs. All these trade fairs costs are posted to the marketing cost
centers. Now if the management wants an analysis of the cost incurred for each of the trade fair
organized by the marketing cost center how would the marketing manager get this piece of
information across to them? The cost center report would not give this piece of info
Now this is where Internal Order steps in .If you go through all cost center reports this
information is not readily available since all the costs are posted to the cost center.

SAP, therefore provides the facility of using internal orders which comes in real handy in such
situations. In the above scenario the controlling department would then need to create an internal
order for each of the trade fair organized. The cost incurred for each of the trade fair will be
posted to the internal orders during the month. At the month end, these costs which are collected
in the internal order will be settled from these orders to the marketing cost center. Thus the
controlling person is now in a position to analyze the cost for each of the trade fair separately.
Thus internal order is used to monitor costs for short term events, activities. It helps in providing
more information than that is provided on the cost centers. It can be widely used for various
purposes

Direct&Indirect Quotation

It is possible to maintain the exchange rates, in SAP, by either of these two methods. What
determines the use of a particular type of quotation is the business transaction or the market
standard (of that country).
SAP adopts two prefixes to differentiate direct and indirect quotes during entering/displaying a
transaction:

Blank, no prefix. Used in Direct Quotation

/Used in Indirect Quotation

When there is no prefix entered, (blank), the quotation is construed as the direct quote by the
system. Possible scenarios include:

The company in question is mainly using the Indirect Quotation.

Use (blank) as the prefix for default notation for indirect quotation. Use * as the prefix for
the rarely used direct quotation. If someone tries entering a transaction using direct quotation, but
without the * in the exchange rate input field, the system will issue a warning.
The company in question is mainly using the Direct Quotation.
You do not need any specific settings as the default is the (blank) prefix for the direct
quotation, and / for the indirect quotation. So, unless you make a transaction entry with /
prefix, the system takes all the entries as that of direct quotation.
There could be instances where you are required to configure in such a way that a prefix is
mandatory irrespective of the type of quotation. In this case, define the direct quotation prefix as
*, and the indirect one as the system default / prefix. This necessitates a prefix each of the
entries either by * or /. Otherwise, the user will get a warning to correct the entry.

Clearing
Clearing in SAP refers to squaring-off open debit entries with that of open credit entries.
Clearing is allowed in GL accounts maintained on an open item basis and in all
customer/vendor accounts. The clearing can either be manual or automatic. In the case of
manual clearing, you will view the open items and select the matching items for clearing. In the
case of automatic clearing, a program determines what items need to be cleared based on
certain pre-determined open item selection criteria and proposes assignments before clearing
these assigned items. Whatever the type of clearing, the system creates a clearing document
with the details and enters the clearing number against each of the cleared open items. The
clearing number is derived from the document number of the clearing document.

You will also be able to do a partial clearing when you are unable to match open items
exactly; in this case, the balance amount not cleared is posted as a new open item. You may also
configure clearing tolerance and also define rules on how to tackle the situation where the net
amount after clearing is not zero (such as, writing off, posting the difference to a separate
clearing difference account, etc.).

In the case of customers who are also vendors, you will be able to clear between these two
provided it is duly configured in the relevant master data (by entering the customer number in the
vendor master record and the vendor number in the customer master record).

Preliminary Post

The user can use preliminary postings to enter and store incomplete documents in the
system. Preliminary postings do not update any data in the system, such as amounts.
The two types of preliminary postings are:

Parked Document
Hold Document

Parked documents provide the user with the ability to create a posting document, save it to
facilitate additional processes such as manager approval prior to posting. Parked documents can
be posted either individually or via a list. When posting several parked documents via a list, the
system issues a list that details each parked documents disposition, detailing a reason if the
document could not be posted.Should a parked document reject upon posting, the list can be used
to facilitate correction. A batch input (SAPs ability to process multiple documents
simultaneously.) session can be created from the list to subsequently post the parked documents.
Parked documents data is stored in a separate table from standard posting data. When a parked
document is actually posted, the data from the parked document is deleted from the parked
documents database. The document data is then written to the standard documents posting
database? and the appropriate data is updated. Parked documents can be selected for reporting
purposes and their status should be evaluated as part of the monthly close process.

Hold documents are user defined and managed. They are intended to be temporary in nature
offering the user the ability to save incomplete documents when necessary. Workflow
functionality can not be configured for hold documents. Hold documents can only be displayed
and posted by the user that created them. Hold documents should be cleared as part of the
monthly close process

The clearing between the customer and vendor can happen by following the below settings
1. The customer number must be entered in the corresponding vendor master record
a. FK02->General Data -> Control
In the Account control tab, in the Customer field, enter the customer number

b.In the Company Code Data > Payment Transaction Accounting, select the checkbox Clrg
with Cust

note:If you do not fill Customer field ,the Clrg with Cust field can not display.

2. The vendor number must be entered in the corresponding customer master record
a. FD02->General Data -> Control
In the Account control tab, in the Vender field, enter the vendor number

b. In the Company Code Data > Payment Transaction Accounting, select the checkbox
Clearing with vendor

3. For testing, create a vendor invoice through FB60 and customer invoice through FB70. Note
that customer and vendor are properly selected.

4. To see the vendor/customer balance both together use FBL1N/FBL5N, when you execute
FBL1N select customer check box, when you execute FBL5N select vendor check box along
with open item/cleared item check box

5. For clearing the open items. Use the TCode F-32. On clicking the Process open Items, the
vendor invoice (KR) and customer invoice (DR) are shown automatically. It will generate the FI
document with proper entry.

Note: Partial / Residual payment between customer and vendor is also possible

Net Posting

Usually, when a transaction is posted, for example, a vendor invoice (document type: KR), the
system posts the Gross amount with the tax and discount included. However, SAP provides
you the option of posting these items as Net. In this case, the posting excludes tax or
discounts. Remember to use the special document type KN. (Similarly, you will use the
document type DN for customer invoice-Net compared to the normal invoice postings for the
customer using the document type DR.) For using this net method of posting you should have
activated the required settings in the customization.

Posting in ASSET ACCOUNTING

Tables For Postings

Postings in Asset Accounting create or modifies entries in the following tables:

ANEK (Document Header Asset Posting)

ANEP (Asset Line Items)
ANEA (Proportional Values: mostly for retirements and retiring transfers)
ANLC (asset values summarized on area and year level)
ANLB (only for the very first posting on the asset; table is updated)
ANLA (aquisition date, deactivation date, origin)

Fields of Posting Tables

The most important fields are explained in the following slides:
The following fields belong to the tables ANEP, ANEA, ANEK:

BUKRS: company code

ANLN1: asset main number
ANLN2: asset sub number
GJAHR: fiscal year
LNRAN: number of the asset line item

Table ANEK
The following important fields belong to table ANEK:

CPUDT, CPUTM: System date of posting

TCODE: Transaction code, which was used for posting
ANLU1, ANLU2: Asset number of acquired/retired asset for transfer or intercompany
transfers
BELNR: document number (FI or reference number)
AWTYP, AWORG, AWSYS: fields which are the unique link to the corresponding FI
document.

Table ANEP
Table ANEP consists of the following important fields:

AFABE: depreciation area

BELNR: document number (or reference number)
BWASL: transaction type
ANBTR: APC amount of the posting
NAFAB, SAFAB, ZINSB: ordinary, special depreciation, interest on transaction (not
valid anymore for the new depreciation engine!)
XANTW: indicator, that proportional values exists (XANTW = X, if there are entries in
table ANEA)
LNSAN: line item number of the reversal document
AUGLN: number of the clearing line items (is set by the AuC settlement)

Table ANEA
Table ANEA is filled if proportional values/value adjustments have to be considered, e.g. for
retirements and transfers.
In table ANEP field XANTW is set to X
The following important fields are part of table ANEA:

AFABE: depreciation area

NAFAV, SAFAV, AAFAV: proportional value adjustments of previous fiscal years
NAFAL, SAFAL, AAFAL: proportional value adjustments of current fiscal year

Table ANLC
In table ANLC the sum of all asset values are listed per asset, depreciation area and fiscal year :

BUKRS: company code

ANLN1, ANLN2 : asset number
GJAHR: fiscal year
AFABE: depreciation area
KANSW: accumulated APC values
KNAFA, KSAFA, KAAFA: accumulated ordinary, special, unplanned depreciation

Further fields of table ANLC per company code, asset, depreciation area, fiscal year:

NAFAP, SAFAP, AAFAP: Planned ordinary, special, unplanned depreciation of the

current fiscal year
NAFAG, SAFAG, AAFAG: Posted ordinary, special, unplanned depreciation of the
current fiscal year
ANSWL: sum of all the changes of the APC value
NAFAV, SAFAV, AAFAV: Proportional depreciation of previous years
NAFAL, SAFAL, AAFAL: Proportional depreciation of the current fiscal year
What is Splitting? Splitting Structure Definition

Splitting is a process used to assign activity-independent plans/actual costs, both primary

andsecondary, of a cost center to the individual activity types within that cost center. But the
important requirement is that you will use this when there is no account assignment to the
activity types.

You may either use the Splitting rules or the Equivalence number to achieve this. When you
split the costs from a cost center, the cost center temporarily becomes more than one cost center
for the purpose of allocation but again becomes a single cost center when posting happens in the
subsequent period.

If you need to assign different cost elements or cost element groups to activities in more than one
way, then you need to define a Splitting Structure containing splitting rules to determine
the criteria of splitting activity-independent costs to an activity type. If you have created the
splitting structure in customizing and assigned the same to a cost center, then the system uses the
splitting structure for cost apportioning; otherwise, it will use the equivalence number.

The splitting rules determine the amount or the proportion of costs to be allocated to various
activity types of a cost center and is based on the consumption of these activity types. The costs
thus allocated may be a fixed sum, or a percentage, or it can even be based on the tracing factors
or SKFs.

The equivalence number is a basic method for splitting the costs when you manually plan for
each of the activity types. By this, you will plan all activity-independent costs according to the
equivalence numbers (the default is 1).

Automatic Account Assignment in SD

During goods issue in the sales cycle, the system is usually configured to update the relevant GL
accounts automatically and to create the relevant accounting documents. This customization in
IMG is also called material account assignment and is achieved through a number of steps as
detailed below:

1. Determine valuation level (Company Code or plant).

2. Activate valuation grouping code and link it with the chart of accounts for each
valuation area.
3. Link valuation class with material type (FERT, HAWA, HALB, etc.) with the
account category reference (combination of valuation classes).
 4. Maintain account modification codes for movement types.
5. Link account modification codes with process keys (transaction/event keys).
6. Maintain a GL account for a given combination of chart of accounts+ valuation
grouping code + account modification code + valuation classes.

The process of Automatic Account Determination is as follows:

1. Depending on the plant entered during goods issue (GI), the Company Code is
determined by the system which in turn determines the relevant Chart of Accounts.
2. The plant thus entered in goods issue determines the valuation class and then the
valuation grouping code.
3. The valuation class is determined from the material master.
4. Since the account modification code is assigned to a process key which is already
linked to a movement type, the transaction key (DIF, GBB, AUM, BSX, etc.)
determines the GL account as posting transactions are predefined for each movement
type in inventory management.

Why do we pass reversal enteries?

At times some incorrect documents might have been entered in the systems.

If you have entered an incorrect document, you can reverse it. Note that R/3 can reverse
a document only if the following conditions are met:

- Contains no cleared items

- Contains only vendor, customer, or G/L line items
- Was posted within the FI system
- Contains only valid values, such as business areas, cost centers, and tax codes

Ordinarily, you post a reversing document in the same period you posted the original
document. The period of the original document must be open to post a reversing
document. If the period is not open, you can overwrite the posting date field with a date
in an open period, such as the current period.

Reversal can be done individually FB08 or Mass F.80.

If the document to be reveresed contain cleared items, then cleared item must be reset
before the reversal of document.

Currency in Fixed Assets

Currencies in Fixed Asset Accounting is a recurring topic of misunderstandings.The following

explanations usually apply to all postings to Fixed Assets. In individual cases, deeper integration
may cause differences in postings from FI, or there are advanced options for intervening in the
process.

1. Transaction currency

-In Financial Accounting, you can enter a business transaction in any currency. In addition to the
local currencies, the business transaction is also updated in this transaction currency.

-In Asset Accounting, the system ignores the transaction currency.

From Asset Accounting transactions (for example, ABZON, ABUMN, ABAVN, ), it is not
possible to use a transaction currency that differs from the local currency. Usually, the local
currency and the transaction currency are used.

2. Local currency

With local currency SAP means the currency in which a company code is managed. In Fixed
Asset Accounting, areas posting in realtime (technically: T093-BUHBKT = 1) are always
managed in local currency.

3. Parallel currency / parallel local currency

Parallel currencies are also known as the second and third local currency.

In Financial Accounting, you can manage a company code in up to two additional local currency
types (for example, group currency, index-based currency or hard currency). The currencies of
the additional local currency types do not have to differ. For example, you could manage local
currency, group currency and hard currency in the same currency unit (such as USD).

For each additional local currency in Asset Accounting, you have to manage a separate area in
this parallel local currency for each area posting in realtime. This normally applies to the master
area (area 01).

For parallel currencies, you can set the translation type. You can choose whether the system
translates to the parallel currency from the underlying transaction currency or from the local
currency. You can also set the exchange rate type to be used and the determination of the
translation date.

4. Foreign currency

Asset Accounting defines foreign currency as a currency in which an area is managed, and,
which fulfills the following conditions:

-The currency used does not match the (first) local currency and
-the area, which is managed in this currency, is not set as a parallel currency area (technically:
T093A-CURTP is initial).

Foreign currency areas, in contrast to parallel currencies, are not usually translated from the
transaction currency directly.

An exception displays transaction FB01 and its partner transactions, in which it is possible,
thanks to deep integration with Asset Accounting, to supply the foreign currency areas with
values during document entry. If the transaction currency is identical to the currency of a foreign
currency area, the amount is transferred without later being translated using the local currency.
You can also enter the foreign currency amount manually when you enter the document.

There is no option to make settings for translation from the transaction currency in the same way
as for the parallel currency areas.

The system usually translates from the values in the reference area for value transfer.

5. Problem cases

In practice, using different currencies often results in problems with comprehension. This section
describes phenomena common in Asset Accounting, and explains the system response using
examples.

a) Rounding differences

You use a parallel currency area and a foreign currency amount in the same currency (for
example, both are in EUR). The local currency is managed in USD. The parallel currency is set
so that the value is translated directly from the transaction currency.

Example: You post a document (for example, an invoice receipt using transaction MIRO) in an
alternative transaction currency (Example: 79.84 GBP).

The exchange rates are as follows:

100 GBP = 135 USD

100 USD = 80 EUR
100 GBP = 108 EUR

You receive the following result:

Local currency amount (= 01 in USD): 107.78 USD (= 79.84 * 1.35)

Parallel currency area (in EUR): 86.23 EUR (= 79.84 * 1.08)

Foreign currency area (in EUR): 86.22 EUR (= 107.78 * 0.80)

The differing result between the parallel currency area and the foreign currency area can be
attributed to the differing currency translation type. The system translates the foreign currency
area from the local currency value. Rounding differences may occur.

b) Rounding differences when transaction currency and foreign currency are the same

A special case in the previous example would be to make the posting with EUR as the
transaction currency instead of GBP. The transaction currency would thus be the same as the
parallel currency and the foreign currency.

In this constellation, you would expect the values for the areas with the same currency to be
transferred identically from the transaction currency. However, this is the case for the parallel
areas only, which are translated from the transaction currency. In all other cases, the translation
is first to the local currency, then to the area currency. 100.00 USD in the transaction currency
may therefore become 100.01 USD in the foreign currency area.

For this special case, SAP offers a modification, which ensures the value is transferred
identically from the transaction currency for foreign currency areas, provided that these contain
the same currency. If you are interested in obtaining this modification, contact SAP Support with
reference to this note. SAP Development will then provide you with this modification.

c) Unexpected values in the foreign currency area

When you make a posting from Logistics, it may not be possible to explain the values in the
transaction currency and local currency that result from a currency translation. An extreme case
would be a posting with the transaction currency amount 0.00 but an alternative amount in the
local currency. Example: Transaction currency 0.00 EUR and local currency amount 1000.00
USD.

The system responds as described before, even with constellations of this type. This may lead to
differences between areas with the same currency but different currency translation types. For
the numerical example above, the following scenario arises:

Local currency area (in USD): 1000.00 USD

Parallel currency area (in EUR): 0.00 EUR (from transaction currency)

Foreign currency area (in EUR): 800.00 EUR (from local currency)

Primary secondary cost element automatic creation

Part of SAP Controlling module is Cost Element Accounting. It is under this area where you
maintain directly master data of cost elements. Just to refresh your mind about cost element.

There are two types of cost elements in Controlling, namely; primary and secondary cost
element. Primary cost elements are use to transfer P&L account postings in Financial (FI) to
Controlling (CO). It is a requirement that all P&L accounts should have a primary cost elements;
otherwise, transactions can not be posted involving P&L accounts in FI. On the other hand,
secondary cost elements are use only for allocation and assessment purposes as period-end
process.

Some might have created already a cost element. The question now is, how did you create the
cost element? You could have created manually for each P&L Account. My dear readers, its
really a tedious activity to create cost element manually.

Now here is the tip. You can create primary cost elements automatically for all P&L accounts.
You just follow this procedure:

1. First, set-up the settings in your Chart of Accounts. Follow this configuration path:

IMG ->Financial Accounting (New)->General Ledger Accounting (New) ->Master Data -> G/L
Accounts ->Preparations ->Edit Chart of Accounts List.

Transaction Code: OB13

The Change View List of All Chart of Accounts: Details screen appears

Set the Controlling Integration to 2 Automatic creation of cost elements (see highlighted item),
and save your work.

2. Second step, Specify the default cost elements that will be automatically created. Follow this
configuration path:

IMG -> Controlling -> Cost Element Accounting-> Master Data ->Cost Elements ->Automatic
Creation of Primary and Secondary Cost Elements ->Make Default Settings.

Transaction Code: OKB2

3. Third step, Create Batch Input Session for the automatic creation of cost elements. Follow
this configuration path:

IMG -> Controlling->Cost Element Accounting->Master Data ->Cost Elements ->Automatic

Creation of Primary and Secondary Cost Elements ->Create Batch Input Session.

Transaction Code: OKB3

4. Fourth step, Execute Batch Input Session.

Transaction Code: SM35

Result: The cost elements specified in step 2 will be automatically created

First of all, to post a document relating to a previous year, say 2006 when you are in 2007, the
relevant posting period should be open in the system. When such a posting is done, the system
makes some adjustments in the background:

One: the carry-forward balances of the current year, already done, are updated in case the posting
affects balance sheet items.

Two: if the posting is going to affect the Profit & Loss accounts, then the system adjusts the
carried forward profit or loss balances to the Retained Earnings account(s)

Invoice Verification-Brief Introduction

Logistics Invoice Verification is part of Materials Management. At the end of the logistics chain
comprising Purchasing, Inventory Management, and Invoice Verification, Logistics Invoice
Verification checks incoming invoices for accuracy with regards to content, price, and
accounting.

The main task of Logistics Invoice Verification is to complete the procedure of materials
procurement by posting the vendor invoice and to pass on information concerning the invoice to
Financial Accounting and subsequent applications.

Logistics Invoice Verification can also process invoices that do not originate in
materials procurement.
Logistics Invoice Verification is not an isolated component within SAP R/3. It operates in
conjunction with the Purchasing and Inventory Management components. Logistics Invoice
Verification accesses data located in preceding application areas.
For each incoming invoice, Logistics Invoice Verification creates an MM invoice document and
an FI invoice document.
The invoice documents update data in:

Materials Management
Financial Accounting

VARIANCE IN INVOICE VERIFICATION

The system needs to be configured properly with Tolerances so that you are not hampered with
variances when you try Invoice Verification. You need to define the lower and upper limits for
each combination of the Company Code and the tolerance key defined for the various variances.
The system then checks these tolerance limits and issues warnings or prevents you from
proceeding further when you process an invoice.

Variances arise because of mismatch or discrepancies between the invoice and the PO against
which the invoice has been issued. Normally you will encounter:

1. Price variances: If there is a discrepancy in invoice price and PO item prices.

2. Schedule variances: If the planned delivery date is later than the invoice postings.
3. Quantity variances: If the delivered quantity (or delivered quantity less the previously
invoiced quantity) is not the same as that of the invoiced quantity. When the invoiced
quantity is more than the GR, the system requires more GRs to square off the situation.