Wednesday, February 27, 2013 8:43 PM

Change default SAP Logo on front screen by following those steps;

1. Identify a picture to replace the existing SAP logo. This picture can be in any valid picture format – gif,
bmp, jpg. But convert it to jpg since that is the smallest available picture type. Store the picture
somewhere on your workstation.

2. Go to transaction SMW0.

3. On the SAP Web Repository: Initial Screen, click “on” the radio button for Binary data for WebRFC
applications, and click the Find icon or press F8. On the SAP Web Repository: Objection selection screen,
click the Execute icon or press F8.

4. On the SAP Web Repository: Object display screen, first make sure that the mime extension exists for
your picture type. Click Settings -> Maintain MIME types. Look to the far right of the Data Browser: Table
MIMETYPES Select Entries screen, and if you don’t see your file type – gif, jpg, bmp – then you need to
add it. Once you at done, back out to SAP Web Repository: Object display screen.

5. Now you can upload your picture. Click the Create icon or press F5. Fill in the name of your picture
and a brief description and click the Import icon. Then provide the location of your picture and load it in.

6. Go to transaction SM30. Fill in the table name SSM_CUST and click Maintain.

7. On the Change View “Set Values for the Session Manager / Profile Generator” screen, click New
Entries and add an entry called START_IMAGE and set the value to the name of your picture created in
step #5. Then press the Save icon.

You have replaced the SAP splash screen picture. Log off and back on to view your work!
or press F8. On the SAP Web Repository: Objection selection screen, click the Execute icon or press F8.

From <[Link]

Change default SAP Logo Page 1

Wednesday, February 27, 2013 8:44 PM

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 control…double 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 document…double
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 document…double
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 entry…you 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 [Link] 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 PK…and
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

the difference among Account group, Posting key an Page 2

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.

the difference among Account group, Posting key an Page 3

Wednesday, February 27, 2013 8:57 PM

What are posting Keys and How are they used while making postings?

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 Keys Page 4

Wednesday, February 27, 2013 8:58 PM

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.

Statistical Key Figure Page 5

Wednesday, February 27, 2013 9:00 PM

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 organization’s 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
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.
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

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.
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

Controlling basics Page 6

• 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

Controlling basics Page 7

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

Controlling basics Page 8

Wednesday, February 27, 2013 9:01 PM

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

Difference Between Parking and Holding of Document Page 9

Wednesday, February 27, 2013 9:02 PM

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 document’s disposition, detailing a reason if the document could not be
[Link] a parked document reject upon posting, the list can be used to facilitate correction. A
batch input (SAP’s 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.

preliminary postings Page 10

Wednesday, February 27, 2013 9:05 PM

The International Demonstration and Education System (IDES) contains a fully-fledged model company
that has been set up in an R/3 System. The IDES corporate group comprises a number of companies,
each with predefined business tasks. All of these companies can be used individually, or in interaction
with each other, to demonstrate how the R/3 System is integrated, and the range of functions that are
available.

IDES is used principally in internal and external training courses, self-learning programs, and for
presentations. It aims to prepare project team members and endusers for using the R/3 System in
practice. The IDES system provides an ideal learning environment: users get to work in a system that has
been fully custom-ized, and contains real-life master data and transaction data. The system further
facilitates the transfer of knowledge by providing extensive data descriptions and process descriptions
for cross-application business processes. The realistic business processes of the company group have
been set up as self-learning units in IDES.

The online documentation in IDES plays a central role in this self-learning process. Since integrated
process flows are already defined in the system, users can use the IDES online documentation to
familiarize themselves gradually with the core functions in any of the R/3 components. Detailed process
descriptions and realistic business data mean that even beginners and users with-out detailed R/3
knowledge can familiarize themselves quickly with the R/3 Sys-tem. This online help can also be used as
a basis for developing internal training courses and holding R/3 presentations.

IDES Page 11
Wednesday, February 27, 2013 10:53 PM

Depreciation’ is the reduction in the book value of an asset due to its use over time (‘decline in
economic usefulness’) or due to legal framework for taxation reporting. The depreciation is usually
calculated taking into account the economic life of the asset, expected value of the asset at the end of
its economic life (junk/ scrap value), method of depreciation calculation (straight line method, declining
balance, sum of year digits, double declining, etc.), and the defined percentage decline in the value of
the asset every year (20%, or 15%, and so on).

The depreciation can either be planned or unplanned.

Planned depreciation is one which brings down the value of the asset after every planned period; say
every month, until the asset value is fully depreciated over its life period. With this method, you will
know what the value of the asset at any point of time in its active life.

On the contrary, unplanned depreciation is a sudden happening of an event or occurrence not foreseen
(there could be a sudden break out of a fire damaging an asset, which forces you to depreciate fully as it
is no longer useful economically) resulting in a permanent reduction of the value of the asset.

In SAP, you will come across three types of depreciation:

Ordinary depreciation, which is nothing but ‘planned depreciation.’

Special depreciation, which is over and above ‘ordinary depreciation,’ used normally for taxation
purposes.
Unplanned depreciation, which is the result of reducing the asset value due to the sudden occurrence
of certain events.

Dep. Page 12
Wednesday, February 27, 2013 11:00 PM

A Client is the top-most organizational structure, which has its own set of master records. A Client is
denoted by a 3-character alphanumeric code in SAP, and is a mandatory element. The settings made at
the Client level, data maintained, etc., are available across all the Company Codes. A Client should have
at least one Company Code defined.

SAP comes delivered with Clients 001 and 002, which contain all the default settings. Usually, copying
from the default Clients creates additional and new Clients.

Typically, in SAP, you will have different ‘types’ of Clients; namely:

1. Development Client
2. Test Client
3. Production Client

In any implementation, you must have at least three types of Clients as mentioned above. There are
some companies where you will have more than three. These include:

Development Client

Test Client

Quality Assurance Client

Training Client

Production Client

A Development Client is also called a ‘sand box’ Client and is sometimes known as a ‘play’ Client. This is
the logical place in the SAP system where you try out new configurations, write new programs, etc. This
is the place, as the name suggests, where you can ‘play’ around before
finalizing a scenario for customization.

Once you are okay with the configuration or a new program, you will then move it manually (transport)
to the ‘Test Client’ where you will carry out all the tests (both modular and integration). The end-users
are provided with the training using the ‘training’ Client. Sometimes both the ‘test’ and ‘training’ Client
are in a single ‘instance.’ The ‘quality assurance’ Client helps with necessary quality checks before
something is ready to be passed on to the ‘production’ Client.

After satisfactory results, it will be transported (automatically) to the ‘Production Client’ (also called the
‘Golden Client’). You will not be able to make any modifications, manually, to the ‘production’ Client and
the authorization is very limited because this Client is responsible for day-to-day business transactions
and any issues here will jeopardize all business operations, which is why this is also called the ‘live’
Client.

client concept Page 13

Wednesday, February 27, 2013 11:02 PM

Overview

Asset History Sheet report is one of the most powerful report provided by SAP Fixed Asset module. It
provides complete details of the changes to the Asset Portfolio during the fiscal year and again in the
format (Layout) that can be configured in SAP IMG.

Report Scenario

In order to view all of the different types of asset activity for an asset, or a large number of assets (by
company code or class), the asset history sheet allows you to uniquely map any particular transaction
type to a specific field in the report. The main benefit of this is that it provides great visibility into the
types of transactions that are being performed on the asset. Without this, differt types of transactions
might be posted to the asset but aggregated into a single figure.

As an example, consider an asset that has many asset transfers occurring where the asset is both the
sender and a receiver. The asset received $500 in transfers from another asset and also transfers $300
to a series of other assets. In the delivered history sheet versions, the values for the transfers field
would be a summation of these values to show a net $200 positive transfer. But with a properly
configured asset history sheet, you can great structures that highlight the Transfers-In and Transfers-Out
values. The same is true if you want to provide more visibility to unique asset transactions such as
Write-Ups and Unplanned Depreciation versus regular depreciation.

Report Execution

Menu Path: Accounting > Financial Accounting > Fixed Assets > Information System > Reports on Asset
Accounting > Notes to Financial Statements > International > Asset History Sheet

Transaction: AR02

Program: RAGITT_ALV01

Selection Values:

Usual report criteria such as…

Company Code
Asset Number
Asset Class
Depreciation Area
Sort version
Report List Level – This will determine whether the report output will be in a detailed fashion (i.e., list
individual asset records) or summarized based on the sort version.

History Sheet Version – see below for more information

Configuration

The configuration for this report requires three items:

Asset History Sheet Page 14

1. Appropriate asset history sheet groups
2. Proper mapping of all transaction types to the asset history sheet group
3. A properly configured and “complete” asset history sheet version

The Asset History Version is the core of the Asset History Sheet report and determines how the asset
accounting transaction data is displayed. Most importantly, it defines the column-and-row structure of
the report output and how each type of asset activity (acquisitions, transfers in, transfers out, AUC
settlement, etc.) is mapped to the appropriate field in the report. The History Sheet Version is
completely customizable for each customer’s purposes.

IMG menu path: Financial Accounting > Asset Accounting > Information System > Asset History Sheet >
Define Asset History Versions

1. SAP has supplied standard asset history versions. For the custom asset history version creation, we
can copy the existing version & make required changes or create it from scratch.
2. Define 4 character asset history version identification code.
3. Asset History version can be defined in rows and columns. We can define maximum 8 rows and 10
columns. Row and Column ID is made up of two digit integers. There is a minimum of 1 row and 2
columns (00 and 99) required.
4. Typical Column Definition:

00 – Values at the start of FY

01 to 80 – Transactions during FY
99 – Values at the end of FY

5. Within each cell of the report you can map the asset history sheet groups to appear. Drilldown in
order to maintain this.

Asset History Sheet Page 15

Thursday, February 28, 2013 12:11 AM

If you want to see what transactions are executed by a user in a specific time period do the following
steps;
Go to ST03. Select choose for analysis. Choose only one application server at a time in case you have
multiple application servers. Choose time period of your choice.
In the next screen from menu choose GO TO–>PROFILES->-USER PROFILES. Here you will get the list on
users who have worked on that application server.
Double click on the required user and you will get all the transactions he/she has executed.
In case you select TOTAL in step 1 and then follow the steps 2 and 3 you will only get the list of
application server on which the user has worked and not the transaction details.

Transaction History Executed Page 16

Thursday, February 28, 2013 9:26 PM

Take a look at these basic procedures for new fiscal year in a SAP system. Familiarity of these procedures
is more advantageous. These procedures should be done inorder to post transactions in the new fiscal
year; thus, avoiding any error during transaction entry.

1. Open and Close Posting Period – In this procedure, you close and open period/fiscal year. There are
two (2) intervals available, from period 1 to period 2. For each interval, set a lower limit, an upper period
limit, and the fiscal year.

Path: IMG ? Financial Accounting (New) ? Financial Accounting Global Settings (New) ? Ledgers ? Fiscal
Year and Posting Period ? Posting Periods ? Open and Close Posting Periods.

Transaction Code: OB52

2. Maintain Versions (CO) – In the SAP standard system, each Controlling Area has a version for actual
and planned costs which is Version 0. The SAP system creates this version automatically during the set-
up or definition of the controlling area. This version for planning data is fiscaly-year-dependent. So, it
should be define for each fiscal year.

Path: IMG ? Controlling ? General Controlling ? Organization ? Maintain Versions.

Transaction Code: OKEV

3. Asset Fiscal Year Change – From system point of view, a fiscal year change is the opening of a new
fiscal year for a company code. Once a fiscal year change takes place, the asset values from the previous
fiscal year are carried forward automatically and cumulatively into the new fiscal year. Do remember
that no business transactions for assets can be posted in a new fiscal year before the fiscal year change
takes place. Moreover, even the fiscal year change has already done, asset can still be posted in the old
fiscal year. What happen is, the system automatically corrects any values that are affected by postings
from the past fiscal year.

4. Close and Open Period for Material Master Records – Execute this transaction to close the previous
period (Month) and open the current period for postings of MM transactions.

Path: SAP Menu ? Logistics ? Material Management ? Material Master ? Other ? Close Period.

Transaction Code: MMPV

New Fiscal Year Page 17

Thursday, February 28, 2013 9:29 PM

A change in the asset management fiscal year is required to open asset postings for the new year.
Therefore, this transaction is an integral part of the Year-end Close procedure in asset management. The
program prepares the database to accept records for the new year.

From the point of view of the system, a fiscal year change is the opening of a new fiscal year for a
company code. At the fiscal year change, the asset values from the previous fiscal year are carried
forward cumulatively into the new fiscal year. Once the fiscal year change takes place, you can post to
assets using value dates in the new fiscal year. At the same time, you can continue to post in the
previous fiscal year.

Process Flow
The fiscal year change can only be carried out (even in test mode) for the new fiscal year. The earliest
that you can carry out a fiscal year change is in the last month of the old fiscal year. You can choose any
point in the new fiscal year for carrying out the fiscal year change. Before you can change to fiscal year
YYYY, you must have already closed fiscal year YYYY – 2 (refer to Year-End Closing). You can have a
maximum of two fiscal years open for posting at one time.

No business transactions can be posted in a new fiscal year before the fiscal year change. You can
continue to post in the old fiscal year, even after the fiscal year change. The system automatically
corrects any values that are affected by postings in the past.

Background Processing

The fiscal year change has to be carried out as background processing for performance reasons.
Therefore, start the report as a background job (in the selection screen of the report: Program Exec. in
background). You can carry out test runs with fewer than 1000 assets in the foreground.

Error Log

The system carries out the fiscal year change for all assets, even if the assets have errors. The system
provides statistics per company code for the assets that have been changed.

The system writes assets with errors to an error log and to a worklist (refer toTools). You can access a
long text explanation for the error messages that appear (Long text).

In the case of program termination, you can repeat the fiscal year change as often as required.

asset management fiscal year Page 18

Copying Number Ranges for New Fiscal Year OBH2
Thursday, February 28, 2013 9:31 PM

Number Ranges for New Fiscal Year Page 19

Thursday, February 28, 2013 10:52 PM

Currencies in Fixed Asset Accounting is a recurring topic of [Link] 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

Currencies in Fixed Asset Accounting Page 20

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

Currencies in Fixed Asset Accounting Page 21

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)

Currencies in Fixed Asset Accounting Page 22

Thursday, February 28, 2013 10:59 PM

There are 5 types of currency in SAP r/3 system.

1. Group Currency: You define Group Currency when you define Client (SCC4)
2. Global Company Currency: You define Global Company Currency when you define Company that is
assigned to your company code.

3. Hard Currency: YOU define Hard Currency when YOU define the Country that your Company code
assigned to. A hard currency is used in countries with high inflation.

4. Index-Based Currency: You define IB Currency when You define Country that your company code
assigned to. An index-based currency is stipulated for external reporting (for example, tax returns), in
some countries with high inflation.

5. company code Currency: You define the company code Currency when you define Company Code.

Now with this 5 types of Currency, you can maintain a Parallel Currency in your system under the SPRO –
Multiple Currency. SAP give you to maintain 3 Parallel Currencies, it means when you post a transaction
using Trans Currency, system will convert to the others curr that you set in this setting.

By DEFAULT 1st LC SAP will take the company code Currency as your 1st LC.
2nd LC: you can choose 1 of 5 from the Currency. Type. Ex: Hard Currency
3rd LC: you can choose 1 of 5 from the Currency Type. Ex: Group Currency

Cases:
Your company in Singapore, so your company code Currency is Sing$.
Your company wants to have Double Book Keeping, delevered FS in Sing$ and also in HK$, so you
maintain HK$ in Hard Currency.
Your company have a Consolidation with the HQ in US, so you maintain US$ in Group Currency.

Then after you define your all the Currency types, you fill this / setting this in the 2nd and 3rd LC on your
Parallel Currency.

SAP only give 3 Currency to maintain in Parallel Currency, let say your company need to generate FS in
10 different Currency for Go Public in many different country, then you have to maintain all the other
Currency in the Special Purpose Ledger, to capture your requirement.

Please note that when you use 2nd and 3rd LC as your Parallel Currency, its means you will have 3 set
Books of FS, so at THE END of the MONTH you have to revaluate all your Currency Type: 10 LC, 20 HC
and 30 GC. Because its looks like you have 3 different FS in multiple currencies.

Currency Types in SAP Page 23

Thursday, February 28, 2013 11:00 PM

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 .

Internal Order Page 24

Thursday, February 28, 2013 11:02 PM

The differences between LSMW and BDC are as follows:

LSMW is generally for normal SAP applications, while BDC is mainly for any customized applications.

LSMW is a Non-SAP to SAP communication TOOL, whereas BDC is a SAP to SAP communication UTILITY.

LSMW(Legacy System Migration Workbench) is a more user-friendly tool, through which one can do the
same work as the BDC. One just has to follow the 14 steps. LSMW offers four ways to import data into
SAP, and they are:

BDC, Direct Input, BAPI(BO) and IDOC.

BDC(Batch Data Communication) is basically a program which is either generated by SAP after a
recording or programmed by a abaper. It’s like running the transaction manually but all the data is
populated in the screens automatically. It is a bit complex when the screen contains Table Controls.

LSMW provides various methods for migration of data, namely those of Direct Input, Batch Input
recording and IDOC. BDC however simply makes use of recording. There are two ways of implementing
BDC, the Call transaction metod and the Session method.

In LSMW, mapping is taken care of with the help of SAP, whereas in BDC one has to provide explicit
mapping directions.

In BDC, we can schedule the job, so the uploading can be done at the same time or later periodically
while in LSMW it has to be done at once only. So through LSMW, one cannot upload huge amount of
data. Hence we use LSMW for updating or inserting below 5000 records and we use BDC to upload
records more than 5000.

Coding is not very flexible in LSMW, whereas in BDC coding is very flexible and applications can be easily
customized. this is mainly because LSMW is devised specially for functional consultants who do not
perform coding, while BDC is mainly used by technical consultants, who perform coding.

differences between LSMW and BDC Page 25

Thursday, February 28, 2013 11:02 PM

Most SAP people might be asking, what is a reconciliation account and special general ledger indicator in
SAP Financial Accounting? Well, my dear readers surely you will be enlightened by this article.

First, you must understand the definition of general ledger. General ledger is the main accounting
record of a business which uses double-entry bookkeeping. In SAP, the central task of G/L accounting is
to provide a comprehensive picture for external accounting and accounts. Transactions that have a
financial impact are captured by the general ledger. The transactions could be orinated from other
modules. Example, posting of goods receipt (MIGO) performed by purchaing personnel (MM module)
have already a financial impact. It increases the inventory balance and increases the GR/IR clearing
account. The accounting journal entry the transactions MIGO create is debit (dr) Inventory account (G/L)
and credit GR/IR clearing accounts (G/L).
The general ledgers summarize all financial transactions of a Company. It is the the basis of the
preparation of the Company’s Financial Statements.

Now, let’s dig it further. Reconciliation Accounts are G/L accounts that receive postings from a
subsidiary ledgers. Meaning, transactions data are not posted directly to recon accounts. Example of
recon accounts are Accounts Receivable, Accounts Payable and Fixed Assets G/L. For accounts
receivable G/L the subsidiary ledger is the customer account. All transactions with the customers are
posted directly to the customer account and the recon account is automatically updated. How this thing
happen? Well, when you create a customer account you specify under the Company Code data the
reconciliation account.

So, all normal transactions to the customer e.g. sale of goods are posted to the recon account defined in
the customer master data. Next question would be, what G/Laccount should be updated for postings of
customer down payment (advance collection)? For proper accounting, downpayment should not be
posted to Accounts Receivable – trade. It should be posted to different G/L account e.g. Advances from
customer. Well, how would the said transaction be posted to Advances accounts.

This is one of the cases where the idea of special G/L indicator comes in. With the use of special G/L
indicator you can specify in the set-up what G/L account advances transactions be posted. Standard
posting key of customer transaction with special G/L indicator are 09 (dr) and 19 (cr). The system will
always require you to indicate the special G/L indicator when you use the said posting keys.

Reconciliation Accounts and Special GL Indicator Page 26

Saturday, March 02, 2013 10:27 PM

Pre-Check LSMW: To-Do-List Before Using the Tool

The LSM Workbench is a tool that supports the transfer of data from non-SAP systems to R/3. Basic
functionality of the LSM Workbench:

1. Import old data from spreadsheet tables or sequential files.

2. Convert the data from source format into target format.

3. Import the data into R/3.

Before using the LSM Workbench, you need a concept for data migration. In particular, note the
following items:

· Make sure that R/3 customizing is complete.

· Analyze the data existing in the legacy system to determine which data will be needed in the future
(also from a business-operational point of view).

· Consider whether usage of the tool makes sense with regard to the data volumes to be transferred.
In case of very small data quantities, it may be easier to carry out the transfer manually. With very large
data volumes, however, batch input technology may lead to excessively long runtimes. Rough estimate
for the required time: 10000 records per hour; this value, however, may vary strongly depending on the
hardware.

· Identify the transaction(s) in R/3 you want to use for bringing the data into the SAP System. Here, it
may also be relevant whether the data is required for statistical (evaluation) purposes or for further
processing in the system.

· Test the relevant transaction in R/3 manually with test data from the old system and make sure that
all required fields are filled. There may be required fields that do not correspond to any data window in
the legacy system. In such a case, assigning a fixed value or defining the field as optional for data
transfer may be appropriate.

· Check the interfaces provided by the application. Is there a batch input program and an IDoc (for
example)? Which method should be used in your project?

· Develop a mapping plan in written form: Assign the legacy system fields to the R/3 fields.

· Determine the form (e.g. via „MOVE“ or assigned according to a rule) in which the legacy system
data shall be transferred to the SAP System.

· If applicable, define the allocation rules (LSM-internal name: „translation rules“).

· Define the way for extracting the data from the legacy system. (Note: LSMW does not extract data.)

· Describe the form in which the old data are available: Will the host or the spreadsheet interface of
the LSMW have to be used?

Pre-Check LSMW Page 27

· If only a part of your legacy system will be replaced by R/3, define the functionalities to be provided
by the SAP System and those to be provided by the legacy system. If required, create a concept of the
data flows and interface architecture.

These questions can only be answered individually for every customer; as a matter of course, this should
be done before the tool is used!

Pre-Check LSMW Page 28

Saturday, March 02, 2013 10:28 PM

What is the LSM Workbench?

The LSM Workbench is an R/3-based tool that supports single or periodic data transfer from your non-
SAP system to R/3

What are the core functions of the LSM Workbench?

Importing legacy data from PC spreadsheet tables or sequential files

Converting data from its original (legacy system) format to the target (R/3) format
Importing the data using the standard interfaces of R/3 (IDoc inbound processing, batch input, direct
input)

Which data can be migrated using the LSM Workbench?

By means of standard transfer programs: a wide range of master data (e.g. G/L accounts, customer
master, vendor master, material master, bills of material) and transaction data (e.g. financial
documents, sales orders)
By means of recording of transactions: further data objects (if the transaction can be run in batch input
mode)

Can I be certain that the imported data is consistent?

Yes. The data is loaded via the standard interfaces of the applications. This will include all checks that
are run for online transactions. Invalid data will be rejected.

Can I be certain that conversions are carried out identically across the applications?

Yes. The LSM Workbench works on the principle of central (reusable) rules. This approach guarantees
that, for example, the material number is converted in the same way wherever the reusable rule is used
for conversion.

Do I need an extensive knowledge of ABAP to use the LSM Workbench?

No. The LSM workbench provides the main conversion techniques at the push of a button. For complex
conversions, individual ABAP coding can be added.

Do I have to migrate table by table?

No. Business objects such as material master, customer master or FI document are migrated

Can I transfer data that is on my PC?

Yes. The LSM workbench can read the data directly from your PC. Only when using the periodic
interface, the data has to be on a server accessible by R/3

Is the LSM Workbench part of the standard R/3 system?

No. The LSM Workbench can be downloaded for free from SAPNET: [Link]

FAQ about LSMW Page 29

Is there an extra charge for the LSM Workbench?

No. The LSM Workbench is available free of charge to SAP’s customers and partners

Is there an LSM training course?

There is no specific training course for LSMW

LSMW is part of the 5-day standard training BC420
Workshops at customer site are done at customers charge
Examples in the media center can be used for self-study

Can I migrate from R/3 to R/3 via LSMW?

Yes, but:

Export has to be programmed

Source structures have to be defined
Fields of the source structures can be loaded from the dictionary
Mapping has to be done manually è a lot of fields!! Automatic fieldmapping might be used
Import of large data amounts can take a lot of time (most of the time data amount is higher than for
Migration from legacy systems)
History data can not be build up most of the time

Can I build periodic interfaces using LSMW?

Yes. It is possible to build periodic interfaces using the frame program /SAPDMC/SAP_LSMW_INTERFACE

You can download these faq as presentation too

FAQ about LSMW Page 30