0% found this document useful (0 votes)
16 views

FI Session 01 - SAP applications

Uploaded by

hallarmemon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views

FI Session 01 - SAP applications

Uploaded by

hallarmemon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 14

 ASAP METHODOLOGY:

1. Project preparation

2. Business Blue prints

3. Realization

4. Final preparation

5. Go live and support.

 SAP ARCHITECTURE:
An enterprise structure is mapped to SAP applications using organizational units. Organizational units handle
specific business functions.

Organizational units may be assigned to a single application (such as a sales organization assigned to Sales and
Distribution, or to several applications (such as a plant assigned to Materials Management and Production Planning).
The highest-level element of all organizational units is the client. The client can be an enterprise group with
several subsidiaries. All of the enterprise data in an R/3 System implementation is split into at least the client area,
and usually into lower level organizational structures as well.

Flexible organizational units in the R/3 System enable more complex enterprise structures to be represented. If
there are many organizational units, the legal and organizational structure of an enterprise can be presented in
different views.

By linking the organizational units, the separate enterprise areas can be integrated and the structure of the whole
enterprise represented in the R/3 System.
An enterprise is structured in the SAP R/3 System according to business functions that must correspond to the
functionality assigned to the organizational units.

Examples:
A Company Code is a unit included in the balance sheet of a legally-independent enterprise. It is the central
organizational element of Financial Accounting.
The Controlling Area is the business unit where Cost Accounting is carried out. Usually there is a1:1 relationship
between the controlling area and the company code. For the purpose of company wide cost accounting, one
controlling area can handle cost accounting for several company codes in one enterprise.
In the context of Sales and Distribution, the Sales Organization is central organizational element that controls the
terms of sale to the customer. Distribution Channel is the element that describes through what channel goods and/or
services will be distributed to the customer.
In the context of Production Planning and Control, the Plant is the central organizational unit. A plant is the place
of production or simply a collection of several locations of material stocks in
close physical proximity.
A Storage Location is a storage area comprising warehouses in close proximity. Material stocks can be
differentiated within one plant according to storage location (inventory management).
Clients are used to divide data in a SAP System into various data areas for various purposes. If a company, for
example, wants to use its SAP System for both test and training purposes, a client is created for each purpose.

A client is identified via a three character code. Data can be moved via transports and corrections from one client
to another.

When logging on to the system, the user has to select a client in which he/she wants to work. The user can then
only access data in this client.
Various financial applications offer different views of the financial position and performance of a company and
allow various control levels.
FI Financial Accounting
CO Controlling (Managerial accounting)
TR Treasury
IM Investment Management
EC Enterprise Controlling
RE Real Estate
PS Project System
The client is the highest level in the R/3 system hierarchy. Specifications or data which shall be valid for all
organizational units in all R/3 applications are entered at the client level, eliminating the need to enter this
information more than once (e.g. exchange rates). Each client is a self-contained unit which has separate master
records and a complete set of tables and data. Users must enter a client key and have a user master record in the
client in order to log on to the system.

Main FI-units:
Company code (external purposes)
A Company Code represents an independent balancing/legal accounting entity. An example would be a company
within a corporate group. Balance sheets and profit/loss statements required by law, can be created at the company
code level. Therefore, a company code is the minimum structure necessary in R/3 FI. In an international business,
operations are often scattered across numerous countries. Since most government and tax authorities require the
registration of a legal entity for every company, a separate company code is usually established per country.
Business area (internal purposes)
Business areas represent separate areas of operation within an organization and can be used across company codes.
They are balancing entities which are able to create their own set of financial statements for internal purposes. The
use of business areas is optional.

A company code is an independent accounting entity (the smallest organizational element for which a complete
self-contained set of accounts can be drawn up). An example is a company within a corporate group. It has a unique,
four character key.
The general ledger is kept at the company code level and is used to create the legally required balance sheets and
profit and loss statements.
A company code designation is required for every financially based transaction entered into R/3. This is done
either manually or automatically by deriving the company code from other data elements.
The editing of the company code data includes:
The address data is required for correspondence and is recorded on evaluation reports.
For each company code a currency must be specified. Accounts are managed in the company code currency. All
other currencies are indicated as foreign. The system converts the amounts posted in a foreign currency into this
currency. The currency defined in the company code is known as the local currency within R/3.
The country key specifies which country is to be regarded as the home country. The system interprets all other
countries as foreign. This is important with business or payment transactions, since different forms are needed for
foreign payment transactions, and the system supports different formats for addresses for foreign correspondence.
A language key must be entered so that the system can create texts automatically in the correct language; for
example, when issuing checks.

When defining a business area, only a 4 digit alpha-numeric key and a short description are needed.

The business segments or branches in which a group operates can be set up in the R/3 System as business areas.
They provide an additional evaluation level for the purpose of segment reporting, for example.
Each general ledger is set up according to a chart of accounts. The chart of accounts contains the definitions of all
G/L accounts in an ordered form. The definitions consist mainly of the account number, account name, and the type
of G/L account, that is, whether the account is a P&L type account or a balance sheet type account.

You can define an unlimited number of charts of accounts in the R/3 System. Many country-specific charts of
accounts are included in the standard system.

For each company code, you have to specify one chart of accounts for the general ledger. This chart of accounts is
assigned to the company code. A chart of accounts can be used by multiple company codes (see diagram). This
means that the general ledgers of these company codes have the identical structure.
The variant principle is a widely used method in R/3 to assign special properties to one or more R/3-objects.

For example using creating a company code as an example;


Define the variant: K4 is our fiscal year variant
Populate the variant with values: we define the properties of K4 to be “calendar year”
Assign the variant to R/3 objects: we assign K4 to multiple company codes that use that calendar
The main advantage for using variants is that it is easier to maintain properties which are common among several
business objects.
To separate business transactions into different periods, a fiscal year with posting periods has to be defined. The
fiscal year is defined as a variant which is assigned to the company code.

The fiscal year variant contains the definition of posting periods and special periods . Special periods are used
for postings which are not assigned to time periods, but to the process of year-end closing. In total,16 periods can be
used.

The system derives the posting period from the posting date. When the posting date falls within the last normal
posting period, the transaction may be posted into one of the special periods.

Example: Above you see a fiscal year with 12 posting periods and 4 special periods. If the posting date falls in the
12th period, the transaction can instead be posted in one of the four special periods.

Standard fiscal year variants are already defined in the system and can be used as templates.
If each fiscal year of a fiscal year variant uses the same number of periods, and the posting periods always start
and end at the same day of the year, the variant is called year-independent. A year independent fiscal year variant
can be defined as
the calendar year
a non-calendar year

Ifthe fiscal year is defined as the calendar year, the posting periods are equal to the months of the year.
Therefore a calendar year variant must have 12 posting periods.

If the fiscal year is defined as a non-calendar year, the posting periods need to be defined by assigning ending
dates to each period. A non-calendar year can have between 1 and 16 posting periods. If the non-calendar year does
not start at January 1st the periods of the year which belong to the former or the coming fiscal year must get an
annual displacement indicator (-1, +1).

The example above on the right shows a non-calendar year with 6 posting periods which goes from April to
March. The months January to March therefore still belong to the old fiscal year and need to have the annual
displacement indicator ”-1”.

If the fiscal year differs from the calendar year, but the posting periods correspond to calendar months, the day
limit for February should be 29 to be prepared for leap years.

Fiscal years are normally year-independent.


A fiscal year variant has to be defined as ”year-dependent” if the start and the end date of the posting periods of
some fiscal years will be different from the dates of other fiscal years, and/or if some fiscal years shall use a different
number of posting periods.

If all of the years of a year-dependent fiscal year variant have the same number of periods, only the different
period dates for the different years have to be defined (see example to the left).

If one year of a fiscal year variant has less posting periods than the others, it is called a ” shortened fiscal year”
(see example on the right). This could be required if closing has to be made before the end of the normal fiscal year;
(e. g. if the beginning of the fiscal year should be changed or if the company was sold). The shortened fiscal year and
its number of posting periods has to be specified before definition of the period dates. For this year only a lesser
number of posting periods can be assigned.

You might also like