Financials ERP for beginners

TFIN 50

BASIC SETTINGS

ORGANIZATIONAL UNITS

Organizational units are used to structure business functions and for reporting. The

organizational units of Financial Accounting are used for external reporting

purposes, that is, they fulfil requirements that your business is subject to from

external parties, for example, legal regulations. The financial statements for

example, are created based on the organizational units of Financial Accounting.

Use

You create your company-specific organizational structure in the SAP System by

defining the organizational units and making the basic settings. Defining

organizational units for Financial Accounting is obligatory, that is, you have to

define these units in order to be able to implement the Financial Accounting

component.

Integration

In the SAP System, you define the relevant organizational units for each

component that you are implementing. For example, for Sales and Distribution, you

define sales organizations, distribution channels, and divisions (product groups).

Similarly, for Purchasing, you define purchasing organizations, evaluation levels,

plants, and storage locations. The organizational units are independent of one

another at this stage.

To transfer data between the individual components, you have to assign the

organizational units to each other. You only need to make these assignments once

in the system. Whenever you enter data subsequently, it is automatically

transferred.

The client is the highest level in the SAP ERP system hierarchy. Each client is a

technically independent unit with separate master records and a complete set of

tables and data.

The most important organization unit of financial accounting is the company code.

A company code represents an independent balancing/legal accounting entity.

And is the minimum structure necessary in SAP ERP Financials.

Every organization for which a financial statement and profit and loss statement

(P&L) is to be created must be stored as a company code in the SAP system.

Client

Definition

A commercially, organizationally, and technically self-contained unit within an SAP

System. Clients have their own master records and set of tables.

The definition of the client organizational unit is obligatory.

Use

You only need to make these specifications, or enter this data once. This ensures

that the data is consistent.

Users must enter a client key when they log on to the SAP System. This defines

the client in which they wish to work. All the entries you make are saved per client.

Data processing and analysis is also carried out per client.

Company

Definition

The smallest organizational unit for which individual financial statements are

created according to the relevant legal requirements. A company can include one

or more company codes.

The definition of the company organizational unit is optional.

Client

Company

Code

Business area

Profit Center

Segment

Highest Level

Specifications or data valid for all organizational units

Each Client is an independent unit

Corporate group or group of affiliated companies

Independent balancing/legal accounting entity

Minimum structure necessary

Usually created per country

Alphanumeric ID

Business area: 4 digit ID

Segment: 10 characters ID

Company

Controlling

area

Use

A companys financial statements also form the basis of consolidated financial

statements.

All of the company codes within a company must use the same chart of accounts

and fiscal year. However, each company code can have a different local currency.

Company Code

Definition

Smallest organizational unit of external accounting for which a complete, self-

contained set of accounts can be created. This includes the entry of all

transactions that must be posted and the creation of all items for legal individual

financial statements, such as the balance sheet and the profit and loss statement.

The definition of the company code organizational unit is obligatory.

Use

The company code is the central organizational unit of external accounting within

the SAP System. You must define at least one company code before implementing

the Financial Accounting component. The business transactions relevant for

Financial Accounting are entered, saved, and evaluated at company code level.

You usually create a legally independent company in the SAP System with one

company code. However, you can also define a company code according to other

criteria. A company code could also be a separate, but not independent,

commercial place of work. This is necessary for example, if the place of work is

actually situated in a different country and evaluations therefore have to be carried

out in the appropriate national currency and in accordance with other tax and legal

specifications.

If you want to manage the accounting for several independent companies

simultaneously, you can set up several company codes in one client. You must set

up at least one company code in each client.

Integration

If you use other components of the SAP System, you have to make assignments

between the company code as the central organizational unit of Financial

Accounting, and the organizational units of the other components. This is

necessary to ensure that data can be transferred between the components.

Copy an existing company code.

Address data is required for correspondence and is recorded on evaluation

reports.

Currency Accounts are managed in the company code currency. Other

currencies are interpreted as foreign. The system translates the amounts

posted in a foreign currency into the company code currency (local

currency).

Language key

Country key This is important for business or payment transactions, since

different forms are required for foreign payment transactions.

In addition to the company code there are further important organizational units in

Financial Accounting. These are optional:

Separate reporting

Separate financial statement

Other important organizational units in Financial Accounting:

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

self-contained organizational structure for which costs and revenues can be

managed and allocated. More than one company code can be assigned to one or

more controlling areas. Assigning more than one company code to the same

controlling area is possible only if all the assigned company codes use the same

operating chart of accounts and have the same fiscal year variant.

Other important org. units

Business area Represent separate areas of operation, can be used

cross-company codes

Profit Center

Evaluates the success of indipendent areas within a company. Internal analysis

of profits

Segment Business segments (IFRS)

Company

For consolidation functions. It can contain one or more company

codes

Functional area

In cost-of-sales accounting, operating

costs are sorted according to function

Controlling

Company Code 1 Company Code 2 Company Code 3

Chart of accounts

(+ Fiscal Year variant)

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

structure, here cost and revenue can be managed and allocated. Represents a separate unit of

cost accounting.

More than one company code can be assigned to one or more controlling areas. This enables a

cross-company code cost accounting between the assigned company codes. It is possible if all the

assigned company codes use the same operating chart of accounts and have the same fiscal year

variant. However, as there are important relationships between financial and management

accounting we will also regard this area as a whole. (Reporting purposes).

BASIC SETTINGS IN GENERAL LEDGER ACCOUNTING

Define which elements separates reports are necessary

G/L accounting (new) enables to use of parallel valuations approaches/parallel accounting

through the use of different ledgers

Each client has exactly one leading ledger, while additional non-leading ledgers are used for other

requirements. The main ledger reflects the accounting principle used to draw up consolidated

financial statements. It is integrated with all subledgers and is updated in all company codes.

Leading ledger 0L, non-leading ledgers (parallel accounting). This is known as the

ledger approach in the new General Ledger, is not necessary to define an

additional ledger per company code, a non-leading ledger is sufficient for the

purpose.

You have the option of defining a different fiscal year in non-leading ledgers. Only

the values from the leading ledger are posted to CO in the standard system. The

accounts approach, different valuation approaches and valuations are posted to

different accounts.

Accounts approach Vs. Ledger approach

You cannot define your own scenarios. The scenarios provided are assigned to

the ledgers in Customizing. A ledger (always the leading ledger) can be assigned

one or more scenarios, or even all six at once. You do not need a ledger for each

scenario!

Account Approach

Leading Approach

-No specific account area -No change to chart of accounts

-Minimum one retained earnings acc. for ALL GAAP

-Standard Financial Statement definition

-Relevance of posting for Local or Int. GAAP specified at the acc. level

-ONLY the leading valuation can be posted to CO

-Specific accounts groups -Complex chart accounts

structure

-Minimum one retained earnings acc. for EACH GAAP -Complex financial statement

definition

-Relevance of posting for Local or Int. GAAP specified

at the acc. level

-ALL valuation approaches can be posted to CO

VARIANT PRINCIPLE

Three step method used in SAP system to assign particular properties to one or more objects . The

main advantage is that it is easier to maintain properties which are common among several

business objects.

The variant principle is used for:

Field status

Posting periods

Fiscal year

()

The main advantage for using variants is that it is easier to maintain properties

which are common among several business objects. You define the fiscal year as

a variant that is assigned to the company code. The fiscal year variant contains the

Scenarios

Cost Center Update

-Update os sender cost and receiver cost center fields

Preparation for Consolidation

-Update for consolidation tx type & trading partner fields

Business Area

-Update of trading partner business area and reciever

business area fields

Profit Center Update

-Update of profit center and partner profit center fields

Segment Reporting

-Update of segment, partner

segment and profit center fields

Cost of Sales Accounting

-Update of partner business area and receiver functional

area field

Define

Determinine Values

Assign to the objects

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

periods.

FISCAL YEAR

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

year with posting periods. Define as a variant assigned to a company code.

Fiscal year variant contains the definition of POSTING PERIODS and SPECIAL

PERIODS, this ones (special periods) are used for postings that NOT assigned to

time periods but to the business process of YEAR-END-CLOSING. (In total you

can define until 16 periods).

The system derives the posting period from the posting date. If the posting date

falls within the last normal posting period, you can post the transaction in one of

the special periods.

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

CURRENCIES

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

(USD, JPY,GBP, MXN etc.) Each currency key can have a validity date.

For every combination of two currencies, can be maintain different exchange rates

which are distinguished by an exchange rate type. Then, use different exchanges

rates for different purposes, such a validation, conversion, translation and planning.

Exchange rate types:

Fiscal Year

Year Indipendent

The number starts and end dates for the periods are the

same for every year

Calendar Year: Posting periods are equal to the months of the year (12

posting periods)

Non-Calendar Year: posting periods by assigning end

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

indicator

Year Specific/Dependent

Periods can be vary from year to year

Conditions: a)Start/end of posting periods are different dates between one year and

other. b) Some FY use a different number of posting

periods.

Shortended FY: One fiscal year of a fiscal year variant has less

periods than the others. Is assigned a lower number of

posting periods. It need to be defined and number of

postinmg periods beofre be defined period dates.

Historical rate

Bank selling rate

Bank buying rate

Average rate

The rate on certain key dates

The relationship between currencies must be maintained per exchange rate type

and currency pair using translation ratios (usually has to be performed only

once). Since inflation can deeply influence the relationships between currencies,

translations ratios are maintained on a time period basis.

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

rates by using one of the following TOOLS:

Base currency

Exchange rates spreads

Inversion

Exchange rate spreads between the bank buying/selling rate and average rate

usually remain constant. If the exchange rate spread of an exchange rate type is

entered in the system, only is necessary maintain the average rate since buying

and the selling rate can be derived by adding/subtracting the exchange rate spread

to/from the average rate.

(Combination of base currency and exchange rate spreads). Efficient combination

of the exchange rate tools is:

Using base currency for the average rate

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

The exchange rate is defined or communicated using the direct or indirect method

of quotation depends of the market standard or the individual business transaction.

The use of indirect quotation is neither application nor country-specific(it affects all

the components in which exchange rates are used).

Worklists for Maintaining Exchange rates

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

occur:

Maintain incorrect exchange rates (unknowingly or unintentionally)

Maintain the exchanges rates with the incorrect quotation (indirect instead

direct or vice versa)

The table is very large, maintaining is very time-consuming (scrolling is

necessary)

Table TCURR cannot be maintained by more than one user simultaneously

Advantages using Tx TCURMNT to define workilsts and maintain the exchanges

rates>

Only relevant exchanges can be maintained. (Option to assign

authorizations for worklists)

Only the relevant quotation can be maintained

Direct: One unit of foreign currency is

quoted for the local currency

1USD = 1.2663 EUR

Indirect: One unit of the local currency is

quoted for the foreign currency

1EUR = 0.7897 USD

Local: EUR Foreign: USD

The worklists is smaller and therefore clearer

Parallel processing of different worklists is possible

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

differentiate between direct and indirect quotation exchange rates during input and

display. If you do not enter the standard setting is valid:

(blank, without prefix) Direct quotation exchange rates

/ Indirect quotation exchange rates

MASTER DATA

GENERAL LEDGER ACCOUNTS

The chart of accounts is a variant that contains the structure and the basic

information about General Ledger accounts. It is defined with a four character-

ID, also is defined the individual components of the chart of account (language,

length of G/L account number, group chart of accounts, status). The chart of

Scenarios

Standard Setting:Works mainly with direct quotation

and rarely use indirect.

" " Direct

"/" Indirect

Alternative prefix for both: increasingly use

direct quotation as well direct quotation

"*" Direct

"/" Indirect

Indirect quotation is the most widely used

notation

"*" Direct

" " Indirect

accounts must be assigned to every company code for which accounts are to be

set up based on the structure concerned.

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

the variant creation

Definition

Maintenance languages is in which account descriptions are maintained.

The length of the G/L account numbers can be between 1 to 10 numbers.

Via integration G/L accounts and cost types, it is possible control to what extent the

cost master record is maintained when do this in G/L account master records of

P/L statement accounts. It could be manually or automatically . You can maintain

cost types manually, however, you also have the option of maintaining them

automatically. When you save a new G/L account, the corresponding cost type is

created automatically. The prerequisite however, is that a default value for the cost

element category is defined for this cost element, since if no default value exists,

the system assumes that no cost element is to be created.

Once is assigned a group account number for each G/L account, it supports to

use for cross-company code reporting if the company uses a different chart of

Define Chart of accounts (+ Define

properties)

Contains: -Chart of accounts Key -Description

General Inf.: -Maintenance Language -Length of the G/L acc. number

CO integration: -Manual or automatic creation of cost elements

Consolidation: -Group chart of acc.

Status: -"Blocked" Indicator

Assign to company codes

Which company code with which chart of accounts.

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

field in the G/L account definition (required field entry) and checks whether the

group account number entered exists in the group chart of account. When chart of

accounts is not completed can be blocked so that no company code can use it

until it is ready. You can get a directory of the G/L accounts in your chart of

accounts for information or for documentation purposes

Assigning

Every company code must have a chart off accounts assigned to it. One chart of

accounts can be assigned to several company codes (variant principle).

Controlling component uses the same Financial Account component, in case to

cross-company code controlling, use the same chart of accounts.

Chart of accounts segment

The chart of accounts contains basic information about the accounts, it is

summarized in a chart of accounts segment. Contains:

Account number

Name of the account (short/long text)

Control fields

Consolidation fields

If the chart of accounts has not been translated into the appropriate logon

language, the account name appears in the maintenance language.

Information entered in the chart of account segment for G/L account applies to all

company codes. (information entered once). Texts entered for the chart of

accounts segment is managed by text ID and language. Use key words to search

account numbers.

Is possible define and change the layout of the tab tables for individual processing

of the G/L account master data, define:

Number of tab pages

Title of tab pages

The field groups that you require and their position on the tab pages

Select layouts for central processing, and processing in the chart of

accounts and company code-specific area. (You can copy these

layouts, adjust them to meet your requirements, and then assign them to

your chart of accounts or your account groups.)


(Groups of Fields)

Type/Description -Control in Chart of

accounts -Description

-Consolidation data in chart of accounts

Key word/Transaltion

-Keywords in chart of accounts

-Translation

Information -Information in chart of

accounts -G/L texts in chart of

accounts

Company code segment

To use one of the accounts from the assigned chart of accounts in your company

code, you must create a company code segment for the account. This company

code segment is added to the chart of accounts segment, and together they form

the account. Contains information to refers exclusively to company code

concerned.

The company code segment for the same G/L account can be different depending

on the requirements of the company code. To define the information that is

relevant to each company code:

Currency

Taxes

Reconciliation account

Line item display

Sort key

Field status group

House bank

Interest calculation information

Company Code segment (Several

groups of fields)

Control Data: -Account Control

-Account Management -Joint Venture

Bank/Interest: -Documentation

Creation -Bank/Financial

Details -Interest Calculation

Information: -Information

-G/L Account texts

Texts are managed by text ID and language.

One Chart of Accounts, Several Company Codes

Every company code that wants to use an account from the assigned chart of

accounts has to create it is own company code segment. Because the number

and name of the account is maintained in the chart of accounts, the account has

the same name and number in all assigned company codes.

Balance sheet and P&L Statements Accounts

In the chart of accounts segment, is necessary to specify whether the account is a

balance sheet or a P/L statement account.

Two types of accounts that are treated differently in the closing procedure

1. For balance sheet accounts, the balance is carry out forward to the same

account

2. For P/L statement accounts, the balance is carried forward to a retained

earnings account and the P/L statement account is set to zero. A key is

assigned to the account to which balance is carried forward. (Enter the key

in the field P&L statement type in the chart of accounts segment)

In customizing, users define the retained earnings account that is assigned to

expense accounts during G/L account master record creation. If there is only one

retained earnings account, the system automatically uses the one defined in

customizing. If there is more than one retained earnings account, when you create

a master record, you can select the retained earnings account for each P&L

statement account.

Account groups for G/L accounts

Since a chart of accounts contains many different types of accounts, they can be

grouped into different account groups. Usually, one account group groups

accounts with the same tasks within the G/L. By assigning a number of range to

an account group, it can ensure that accounts of the same type are within the

same number range. Number intervals go G/L account master records can overlap.

At the moment to enter the account group in the chart of accounts segment, it

controls the appearance of the company code segment of a G/L account. In

customizing, for your Cash Accounts account group, change the field status to

make line item display a required entry. (SAP ERP delivers predefined account

groups).

Field Status

It enables to you to control the display and maintenance of an accounts master

data:

Certain fields are grouped together and their field status is valid for the entire

group. The fields Account currency and Field status group are ALWAYS

required entry fields, this status cannot be changed. For fields which are supressed

may contain values, and these values still take effect.

Field Status for Master Data

Hide

Fields that are not used

Display Fields whose values must

not be changed

Required

Fields where must be enter value

Optional Fields that can contain an

entry, but are not required

The field displayed in the general ledger account master record are not only

controlled by the account group, but also by the transaction that you are using to

edit the master data (transaction-specific control). If have not the certain fields to

be modifiable after the creation of master record, specify that a particular field is

not modifiable in the Change Master Data transaction in customizing assigning

the status Display to the relevant field.

For each field, the field status definitions from account group and the transaction

are taken into consideration and the one with higher priority is used.

Fields that are accessed with the transaction Display Master Data are always

either displayed or hidden since you cannot make an entry in a display

transaction. If is not wished to use the transaction-specific control, set the field

status for all fields to optional. Since this field status has the lowest priority, the

account group specific control is always used.

Reconciliation Accounts

Are general ledger accounts assigned to the business partner master records to

record all transactions in the subledger. All posting to the subledger accounts are

automatically posted to the assigned reconciliation accounts. The general ledger is

always up to date.

To define a G/L account as reconciliation account by entering one of the following

account types in the field Reconciliation account for account type:

Accounts Receivable (D)

Accounts Payable (K)

The reconciliation account is then ONLY valid for the account type specified.

Typical reconciliation accounts are the accounts receivables and payables.

Amounts cannot be posted directly to reconciliation accounts

Line Item Display

Is a control field in the company code segment of an account.

Transaction figures are the totals of line item postings on the debit or credit side.

The balance is the difference between the debit and the credit transaction figure.

Since the line item display takes up additional system resources, you should only

use it if there is no other way of looking at the line items. Not activate Line Item

Display for:

Reconciliation accounts: line items are managed in the subledgers

Revenue accounts: line items are managed by the Sales Order

Management application

Material stock accounts: line items are managed by purchasing

management application

Tax accounts: tax items are only useful in connection with the document;

the tax amounts were already checked when the document was posted

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

statement regarding the control of line item management in the account refers only

to the entry view of documents. The active new general ledger accounting has an

Entry view and a General ledger view for a document. In general ledger view,

the line items on all accounts are always visible.

Open Item Management

Items in accounts with open item management are specified as OPEN or

CLEARED. Accounts with open item management must have line item display

activated.

Open item management is a prerequisite if is necessary check whether there is an

offsetting posting for a given transaction. It is possible display open and cleared

items separately, and therefore it is easy to see which business transactions still

need to be cleared.

Open Item management should be used for the following accounts:

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

Accounts without:

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

Bank clearing account

Clearing accounts for goods receipt/invoice receipt

Salary clearing accounts

Is possible to activate or deactivate open item management if the account has zero

balance.

Account in Local currency

As standard, the local currency is proposed as the account currency when is

created a G/L account. For account currency there are two options:

1. Local currency

2. Foreign currency

If the account currency is the local currency, the account can be posted to in any

currency. The other currencies are converted into the local currency for each line

item.

Only balances in local currency

If the indicator Only balances in local currency is selected in the master data

record, transaction figures are only managed for amounts converted into local

currency.

The indicator must be set in cash discount and GR/IR clearing accounts. The

indicator is usually set in balance sheet accounts that are not managed in foreign

currencies and not managed on an open item basis.

Account in foreign currency

Accounts with a foreign currency as account currency can only be posted to in this

foreign currency.

Create Manually

With the two step method, creation of chart of accounts segment separately

from the company code segment. This allows to create the G/L account only in

the chart of accounts segment or in multiple company code segments.

Use the one-step method to create the G/L account in specified company code.

Repeat step 2 of the two-step method, that is, creation in the company code

segment, to create the G/L account in additional company code as needed.

Create G/L accounts by copying

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

that is, another cash account, create the new account with reference to the

existing account and change the account name accordingly.

If all of the G/L accounts in an existing company code are required in

another company code, you can copy the entire company code segment to

the new company code.

You can also copy the entire chart of accounts to a new chart of accounts,

including the account determination. Is possible, also copy the financial

statement version

Data Transfer

To reduce data entry, programs (RFBISA00, Batch input interfaces for G/L

acc. Master data) can be modified to transfer new chart of accounts.

Collective Processing

Collective processing functions for G/L account master records. The system

allows to change at the same time master data in:

Manually

One Step: Create both segments simultaneously (centrally)

Two Step: -Chart of accounts Segment

-Company Code Segment

Copying

Copying an individual G/L acc. w/reference to other G/L acc.

Copy the entire Company Code Segment

Copy the entire chart of accounts segment

Data Transfer

Transfer a new chart of accounts from an external system



Description (such names of several G/L accounts)

For internal purposes, cross company code reporting may be useful. It is not

problem if all company codes use the same chart of accounts. If some company

codes may have to use special chart of accounts because of legal requirements, is

necessary apply the following procedure for internal reporting:

Can use a group chart of accounts, it must contain all of the group of

accounts

The group chart of accounts must be assigned to each operational chart of

accounts. If this is done, the field Group account number in the chart of

accounts segment s of operational charts of accounts is a required entry

field

Must enter the group account number in the chart of accounts segment of

the operational account. Different accounts of one operational chart of

accounts can refer to the same group account.

Must use a financial statement version for the group chart of accounts

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

accounts, no inter-company code controlling can be performed)

Country Chart of Accounts

An alternative to using a group of chart of accounts is to use a country chart of

accounts, all company codes uses the same operational chart of accounts.

Company codes that nevertheless required a special chart of accounts for external

reporting have the following option:

A chart of accounts is assigned

The country chart of accounts number (alternative account number) is

entered in every company code segment. Every country chart of accounts

number can only be used once

Since all company codes post into the same operational chart of accounts, cross-

company code controlling is possible.

(Disadvantage: Accounting clerks who may be familiar with the country charts of

accounts first have to get used to using the operational chart of accounts)

PROFIT CENTER AND SEGMENT

Every company can define for itself which elements/objects can be used to create

the reporting (balance sheet/ P&L). The segment is often chosen as the element

here.

The segment field/characteristic is a new standard account assignment object in

order to create evaluations for objects/entities below the company code level.

The objective is to give a detailed look at the various business activities at (broad-

base) enterprise. segment reporting. Alternative account assignments already

used which are still available:

Profit Center

Business area

Profitability segment of CO-PA

User defined field

Segments can be used to meet the requirements of international principles

regarding segment reporting.

The business area or profit center objects can be used as alternatives. The

segment is provided in addition because the business area and/or profit center

were frequently used for other purposes in the past and thereby to meet other

requirements.

Derivation of a Segment

System enables save a segment in the master data of a profit center. The segment

is posted automatically when the profit center is posted to.

If the profit center does not have a segment, there is no segment account

assignment either. The standard method is to derive the segment from the profit

center. (Customers can also program solutions/derivations themselves.)

The segment is derived from the characteristic profit center because this already

exists in various SAP objects, and the characteristic segment is automatically

derived from this. Segments can only be derived automatically using profit centers.

If it is not possible to derive the characteristic Segment from a profit center master

record, other ways must be found of assigning a segment. Document splitting

provides the following options:

Manual entry

BAdI implementation (FAGL_DERIVE_SEGMENT)

Defining substitution rules

Standard account assignment.

CUSTOMER/VENDOR ACCOUNTS

These accounts have two segments as G/L accounts:

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

the whole organization.

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

Any company code that wishes to do business with specific customer or

vendor has to create a company code segment for this customer or vendor.

This also creates a customer or vendor account.

Because the sales and distribution department also stay in contact with a customer

and has to know specific data about this customer, a sales area segment can be

created for each customer. Any sales area that wants to do business with a

customer has to create a sales area segment first. The sales area segment

contains sales area-specific data.

The Materials Management point of view of the vendor account, just as there is a

sales area segment for customers, and purchasing organization segment for

vendors. Any purchasing organization that wants to do business with a vendor has

to create a purchasing organization segment first, it contains purchasing

organization-specific data.

Usually the sales area segment must at least be created for the sales area

assigned to the company code. The account number is assigned to the

customer/vendor at client level. This ensure that the account number for a

customer/vendor is the same for all company codes and sales area.

Usually at least the purchasing organization segment for purchasing organization

assigned to the company code must be created.

Centralized Vs. Decentralized Maintenance

The system offers two separate functions for maintaining customer/vendor master

records depending on the requirements of the organization. These data records

can be maintained centrally for all areas or separately for financial accounting

and Materials Management., sales and distribution (customer case).

Complete Customer Account

General data in a client level


Sales area segment

Complete Vendor Account

General data in a client level


Purchasing organization segment

Compare Master Data

It is easier to create customer/vendor master records centrally to ensure that they

are set up correctly. In some cases Purchasing Management/Sales Order

Management create their own segments of the master record and accounting

creates its own segments of master record, in this case there is the risk of creating

incomplete or duplicate master records. To prevent the creation of duplicate

accounts as follows:

Use the match code before create a new account

Activate the automatic duplication check

Pages of the customer/vendor account

Important fields

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

fields. The format is defined by company guidelines and practices

Group: Customer or vendors who belong to the same corporate group can

be bundled together under a user-defined group key. This group key can be

used for running reports, transaction processing, or for matchcodes.

Clerk/accounting: the name of the accounting clerk must be saved under

an ID. You can also use this ID for sorting dunning and payment proposal

lists.

Explanatory texts can be entered in every segment. Line item display and open

item management are configured as standard for every customer/vendor account.

As a recommendation, you create a reference account for every account group.

Account groups

When is created a customer/vendor master records, enter de account group on the

initial screen. In Financial Accounting, once the customer/vendor account has been

created, you can no longer change the account group. The account groups

controls:

Each account segment consists of several pages with different groups of fields

General Data -Adress

-Control data

-Payment transactions + texts

Company Data -Acc. information

-Payment transactions

-Correspondence

-insurance

-withholding tax + texts

In Status of the fields in the Master Record the account group is used to control the

fields displayed in the master record.

Controlling the field status

The layout of customer/vendor master data screens can be affected by several

factors:

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

the account group. All accounts of one account group have the same screen

layout.

Transaction-dependent control: field status can be dependent on the

master data transaction (create, change or display). The transaction-

dependent field status should be set to display for the change transaction

if the field is not to be changed after it has been created.

Company code-dependent control: control the field status for fields in the

company code segment of customer/vendor master records via the

company code-specific screen layout. Hide fields that are not used in

specific company code, but enter values in these fields in other company

codes.

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

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

is used.

Divided into smaller number ranges (it must not overlap)

Internal: assigned by the system

External: entered by the user who creates the record (alphanumeric)

Each number ranges can be assigned to one or more account groups

Number ranges

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

Status of the fields in master records

Created for rarely business with customer/vendor

Contains receivables and payables for one-time

It doesnot contain any specific information

It should be hidden fields

Entered in the document during posting

One time customer/vendor account (Normal

Account)

Dual control principle

It define that one person makes changes to customer/vendor master data while

another person is responsible for confirming the changes, usually for critical

changes. If it is define a field in the customer/vendor master record as sensitive,

the corresponding customer/vendor is blocked for payment if the entry is changed.

The block is removed when a second person with authorization check the change

and confirms or rejects it.

The confirmation for the changes can be made for a single customer/vendor or

using a list. It can be restricted by:

Customer/vendor

Company code

Accounts not yet confirmed

Accounts rejected

Accounts to be confirmed by me

Display the changes to the customer or vendor master record for all

accounts (reports RFDABL00 or RFKABL00)

Customer/Vendor Clearing

If a customer is also a vendor or vice versa, the payment and the dunning program

can clear open items against each other. The open items of the assigned

account can also be displayed in the line item display and the open item selection

screens. To clear open items, follow the steps:

Enter de vendor account number in the customer account and vice versa

Each company code can decide separately whether it wants to clear open

items between customers and vendors. If clearing is to be used, select

Clearing with vendor field in customer account or corresponding field in

vendor account.

Alternative Payer/Payee

At the client and company code level, you can enter an alternative payer/payee.

The entry in the company code segment has higher priority than the entry at client

level. If you set the Individual Entries indicator when creating an invoice, you can

enter information about an individual payer/payee for a customer/vendor that has

not been created in mySAP ERP. If the alternative payer/payee is an existing

customer or vendor, you can enter the customer/vendor account number as

permitted payee/payer in the master record.

Head Office/Branch

Customer in some industries place orders locally, but pay invoices centrally, there

is a difference between the goods flow and cash flow. All items posted to a branch

account automatically transferred to the head office account. Usually dunning

notices go to the head office and it is the head office that make and receives

payments. If the Decentralized processing field is selected in the head office

master record, the dunning and payment programs use the branch accounts

instead.

DOCUMENT CONTROL

DOCUMENT STRUCTURE

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

remains as a complete unit in the system until it is archived. Every document is

uniquely identified by the following fields:

Document number

Company code

Fiscal year

Each document contain the following:

Document header, information that applies to entire document

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

item). When you post documents via the AC interface (for example, from

Sales Order Management, Purchasing Management, or other applications),

it creates items in the accounting document that are identical in almost all of

the fields.

Is possible display detailed data for the document header and line items. Two

important control keys:

Document type for the document header

Posting Key for the line items

The SAP system generates at least one document for every business transaction.

The system can assign the document numbers or the user can assign the number

when entering the document.

Related documents are linked in the system so that you have an overview of every

business transaction in the system.

Document type

Controls the document header and is used to differentiate the business

transactions to be posted. Documents types are defined at client level and are

therefore valid for all company codes. The standard system is delivered with

document types that can be changed or copied.

Document types define the following:

Number ranges for document numbers

Account types permitted for postings

Document types also define the following:

The field status of the document header text and reference number

fields in the document header

Whether invoices are posted with the net procedure

If the original document has an external number:

Enter the external number of the original document in the Reference Number

field in the header of the system document

Note the number of the system document in the original document

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

documents from the SAP ERP billing system, you need one of the following

document types:

RV, the default document type for Sales Order Management billing documents

(customer invoices).

RE, the default document type for Materials Management billing documents

(vendor invoices).

When internal number assignment is used, the system assigns a new number to

each document in the Financial Accounting component. In external number

assignment, the system transfers the billing document number to the accounting

document, providing this number has not already been assigned.

Document number ranges

Defines the range of numbers that must be assigned as document numbers. It

must not overlap.

General Documents

(AB)

Customer Invoices (DR)

Customer Credit Memos

(DG)

Customer Payments (DZ)

GL Acc. Postings (SA)

Vendor Invoices (KR)

Vendor Credit Memos (KG)

Vendor Payments (KZ)

Vendor net invoices and

credit memos (KN)

Internal numbering: The system saves the last document number that was

taken from the number range in the current number field and assigns the

number following the current number as the text document number.

External numbering: The user enters the number of the original document,

or the number is transferred automatically from another system. The number

is usually not assigned in sequence, which is why the system cannot store a

current number. It can be alphanumeric.

The document number range must be defined for the year in which it is used.

There are two options:

1. Fiscal Year in the Future: at the beginning of a new fiscal year, the system

continues to use the number after the current number as the next number. It

does not restart at the first number of number range.

2. To Every Fiscal Year: at the beginning of a new fiscal year, the system

starts again with the first number of the number range. This helps to ensure

that the number range is sufficient.

In new General Ledger Accounting, different ledgers can use different fiscal year

variants. This is a very rare case. It is then necessary to make special settings for

these ledgers in Customizing:

Document number ranges are stored for the general ledger view.

The number ranges are assigned to the document types for the general ledger

view.

Internal number assignment must be set for these number ranges. One number

range can be assigned to several document types.

Functions of Posting Key

The posting key has control functions within the line items. It controls:

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

If the item is posted as a debit or credit

The field status of additional details

Like document types, posting keys are also defined at client level. In addition to

control functions, posting key also specifies:

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

information is required for analysing the payment history and creating

payment notices

Whether the posting is sales-relevant and the sales figure of the account is

to be updated by the transaction

In the standard transactions, posting keys are labeled debit and credit. The

following default values:

For GL account posting: Debit is posting key 40, credit is posting key

50.

For customer invoices: Debit is posting key 01, credit is posting key 50.

For customer invoices: Debit is posting key 31, credit is posting key 40.

Document Field status

At the moment to enter documents, different fields are displayed depending on the

transaction and the accounts used. What information is displayed when a

document is processed is controlled by the field status.

As general rule, define the account-dependent field status for general ledger

accounts in customizing. For customer and vendor data, define the posting key-

dependent field status in customizing according the requirements.

Exceptions

If business areas are used, the business are field must be ready for input.

You can activate it by enabling business area financial statements for the

company code. You can only use the field status to define whether the field

is a required or an optional entry field.

Entries in tax fields are only possible if the general ledger account is

relevant for tax.

The hide field status cannot be combined with the required entry field status.

This combination causes an error.

Field Status Group

For each group of general ledger accounts, is necessary define the status of every

document entry. When documents are entered for these G/L accounts, should the

text field be required, optional or hidden??

This information is divided into field status groups for each group G/L accounts.

Is assigned field status groups to the respective general ledger accounts in the G/L

account master records. The field status group are summarized in one field status

variant. The field status variant is assigned to your company code(s). No posting

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

the field status group of the reconciliation account is used.

Standard Posting Keys

By changing the field status definition posting keys and the field status group, you

can make the field status transaction-dependent or account-dependent.

Since the subledger accounts do not have a field status group, postings are

differentiated mainly by means to different posting keys. For this reason, there are

numerous posting keys for subledger accounts.

Mandatory fields are also controlled centrally for document splitting objects (such

as the segment or profit center) when document splitting is used.

Postings to G/L accounts are mainly differentiated by means of different field status

groups. Therefore, only two posting keys are required for G/L account postings.

POSTING PERIODS

Posting periods are defined in the fiscal year variant. To prevent documents from

being posted to an incorrect posting period, as advise close certain posting

periods. Usually the current posting period is open and all other periods are closed.

At the end of a period this period is usually closed and the next period is opened.

Open a posting period by entering a range in the posting period variant that

compasses this period.

During period closing, open special periods for closing postings. During closing,

two periods intervals must be open at the same time. Therefore, two periods

intervals can be entered in the posting period table.

Posting Period Variant

Several company codes can use the same posting period variant. For all company

codes assigned, the posting periods are opened and closed simultaneously. This

simplifies the period maintenance.

Periods check by account type

In the document header, the periods assigned to the account type+ are checked.

This is the first check. Therefore the account type + must be open for all periods

that are supposed to be open for any other account type. The posting period

variant must contain at least the account type +. If the posting periods for

different account types are all to be handled in the same way, the control by means

of the + entry is sufficient.

Posting periods can be handled differently for different account types; that is, for a

certain posting period, postings to customer accounts may be permitted while

postings to vendor accounts may not.

At the line item level, the system check the account type of the posting key to

ensure that the period is open for the assigned account type.

The account interval always contains G/L accounts. By entering certain

reconciliation accounts behind subledger account types, these subledger accounts

can be treated differently to accounts that have different reconciliation account.

During closing, two periods intervals must be open at the same time. An

authorization group may be assigned to the first period interval. Then, only users

belonging to this authorization group have the permission to post in the first period

interval. It makes sense to use the first range for the special periods and authorize

only the accountants involved in closing to post in the special periods.

A third period interval is possible. In this interval, open periods are stored for real-

time integration CO FI really should be able to be posted in the periods. If the

third period is not filled, the entries in intervals 1 and 2 are also valid for these

postings.

With the new General Ledger Accounting, there is also the option to control more

precisely which values for which individual account assignment objects can be

posted, and when.

Determination of posting periods during posting

When entering a document, among other items, enter the posting date, the system

automatically determines the posting period and fiscal year based on the posting

date entered.

In the document overview the posting date, posting period and fiscal year are

displayed. The posting period determine is entered in the document and the

transaction figures for this posting period is updated. If display the balance of an

account, the transactions figures for the posting periods are displayed.

POSTING AUTHORIZATIONS

The upper limits for posting transactions within tolerance groups.

The maximum amounts are defined per company code in tolerance groups. This

is also where the processing of payment differences is controlled.

Maximum amounts

Upper limits for posting transactions within tolerance groups. Is possible enter the

following:

Total amount per document

Amount per customer/vendor item

Cash discount a user with this tolerance group is able to grant

(Local currency of the company code).

Assigning posting authorizations

Is possible to create many tolerance groups, every user can be explicitly assigned

to a tolerance group. For any employees who have especially high or low limits, a

special tolerance group be created and assigned to their user logon IDs.

SIMPLE DOCUMENTS IN FINANCIAL ACCOUNTING

The SAP Financials Accounting component uses one posting transactions for

several different postings. Header and Item data, also the entry screen contains an

information area where is displayed the balance.

Enjoy Posting Screen

The easy to use ENJOY transactions. You can define a document type for each

transaction, which then appears as a general default value. You can overwrite this

proposed document type at any time as long as the document type field is ready

for input during document entry. Via the button Tree, you can access screen

variants, account assignment templates, and held document that you can select as

templates.

G/L acc. postings

Customer invoices

and credit memos posting

SIMPLE POSTINGS

Vendor invoices

and credit memos posting

You can select from Park, Post, or Hold, to complete the document entry

transaction once the balance is zero. For complex postings you can access the

complex posting transaction via the menu. You cannot return to the initial screen

from this complex posting transaction. You can enter an explanatory text for the

line item. This item text can be used internally and externally.

POSTING CONTROL

DOCUMENT SPLITTING

Is only for customers who have to or want to enter further characteristic (such as

segment) on the balance sheet, in addition to company code.

A financial accounting document ALWAYS has two views:

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

creator and therefore how it is shown in the subledgers

General ledger view: view of how a document appears only in the

general ledger

Besides the leading ledger, may also see the document in other, non-leading

ledgers in the general ledger view.

Displaying a document in the entry view and general ledger view is defined in the

new G/L accounting an cannot be switched on or off using customizing. New G/L

accounting offers the following aspects for balance sheet analysis below the

company code level.

Displaying P&L statement by profit center, business area or segment is never

problematic, since the positions which have an effect are always provided with

unique corresponding objects by the original controlling object. If a balance sheet is

created for one of these objects, the problem is that line items cannot be split in the

entry view. This only happens in the general ledger view, using document splitting.

The entities defined as splitting characteristics (balancing characteristics) are

inherited in non-account-assigned posting lines. Document splitting (also called

online split) ensures that companies can create complete balance sheets for

desired objects. If document splitting is not activated, there is usually no difference

between the entry view and G/L view.

Document splitting is activated in customizing. Since document splitting can be

activated for each client and deactivated for each company code, the decision of

whether to split the document or not is made at company code level. All company

codes of a client can only use one document splitting procedure, that is, different

procedures cannot be assigned to different company codes.

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

inherited online in all missing positions.

Default acc. asisgnment

It is possible to work with default acc. assignment, that is, if the position is not provided with necessary object for any reason then a default value can be set automatically

Document splitting process

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

document splitting settings generally cannot be changed after this.

Standard splitting characteristics

Always set the Zero balance indicator if you want to create a financial statement for

the characteristic.

Business area

Profit Center

Segment

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

Document splitting characteristics determine which objects document splitting is

used for (where to divide/balance)

The mandatory field indicator has two meanings:

1. It is an extension of the field status for accounts in which characteristics

cannot be entered during document entry, and/or for accounts that cannot

be controlled using the field status.

2. It is a check as to whether a business process-equivalent business

transaction variant was selected (which determines whether a splitting rule

can be found)

The mandatory field indicator works in addition to field status control in the account

or in the posting key.

Pas

sive

Sp

lit

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

Act

ive

Split

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

reat

ing

clea

rin

g lin

es/

zero

b

alan

ce f

orm

atio

n

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

A splitting procedure, defined in brief, is the total of all splitting rules of all business

transactions. As such, the splitting procedure defines how and under which

circumstances document splits will be performed. In detail, it means each splitting

procedure defines how each item category will be handled in the individual

business transactions.

DEFAULT VALUES

Parameter IDs allow users to set default values for fields whose values does not

change very often, when is executed the transaction, these values appear in the

corresponding fields automatically. Therefore, is not necessary enter values

manually and can prevent input errors. Using the editing options, configure the

screens for the followings areas:

Receipt entry: users can hide fields that may not be relevant for their jobs,

such as foreign currency or cross company code transactions. Can also use

special editing options for the single screen transactiosn

Document display: using the List Viewer, the user can select different

display options for displaying documents

Open items: users can choose line layout displays and postings options for

processing open items, in other words, they can enter the amount of a

partial payment or the balance of the new open item.

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

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

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

Is a general breakdown of the actual business porcesses that sap provides and is assigned a wide variety of item categories

BUSINESS TRANSACTION

BUSINESS TRANSACTION

VARIANT

INDIVIDUAL SPLITTING RULE

ITEM CATEGORY

When users log on to the SAP ERP system, their user ID has specific properties

that apply to it throughout the system: logon language, date format, and decimal

notation. Users can also set a default printer for themselves.

System and Accounting Defaults

The system provides you with basic default values for document entry. The system

proposes the company code that you entered in the last document. The system

works on the basis of the Document Principle: All documents must balance

before they can be posted to.

At company code level, enter the maximum difference permitted between the

exchange rate in the document header of a business transaction and the exchange

rate in the exchange rate table.

CHANGE CONTROL

Changing documents

Users can change documents that have already posted, based on different rules,

only certain fields can be changed. These rules can either be predefined by the

system or be user-specific.

Certain fields in both the document header and the line items can be changed.

Document header: Only the reference number and document header text

can be changed

Line items: the system does not allow changes to the amount, the posting

key, the account, or any others fields that would affect the reconciliation of a

posting

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

The field that was changed

The new and old values

The user who made the change

The time and date of the change

Differentiation between document change rules according to the following criteria:

Acc. Type: allows users to define rules for customer, vendor and G/L

accounts

Transaction class: are only used for the special G/L transactions bill of

exchange and down payment

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

code

The CONDITIONS for changing a field predefined:

The posting period is still open

The line item is not yet cleared

The line item is either a debit in a customer account or a credit in vendor

account

The document is not a credit memo for an invoice

The document is not a credit memo from a down payment

DOCUMENT REVERSAL

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

and re-entered correctly. Users can make errors when they enter documents. As a

result, the document created contains incorrect information. In order to log the

adjustments, the incorrect document must first be reversed. The document can

then be re-entered correctly.

The system provides a function to reverse G/L, customer, and vendor documents,

both individually or in a mass reversal. A document can be reversed by:

a) Normal reversal posting: causes the system to post the incorrect debit as

a credit or vice versa. It causes an additional increase in the transaction

figures.

b) Negative posting: also post the incorrect debit as a credit and vice versa.

This time the posted amount is not added to the transaction figures, but is

subtracted from the transaction figures of the other side of the account. This

sets the transaction figures back to as they were before incorrect posting

took place.

When you reverse a document, you have to enter a reversal reason that explains

the reversal. The reversal reason also controls whether the reversal date is allowed

to be different to the original posting date. Documents with cleared items cannot be

reversed. The document must first be reset.

The normal reversal posting causes the system to post the incorrect debit as a

credit and the incorrect credit as a debit. The negative posting also posts the

incorrect debit as a credit and the incorrect credit as a debit. Is subtracted from the

transaction figures of the other side of the account.

Normally the system uses the normal reversal posting to reverse documents. The

following prerequisites must be fulfilled to enable negative postings:

The company code permits negative postings

The reversal reason must be defined for negative reversal

Negative posting can also be used to perform transfer postings of incorrect line

items. The item is removed from the wrong account by a negative posting

(resetting the transaction figures) and posted to the correct account by a normal

posting. This can only be done with a document type that explicitly allows negative

postings.

When is applied a reverse a document, enter a reversal reason that explains the

reversal. The reversal reason also controls whether the reversal date is allowed to

be different to the original posting date.

Documents with cleared items cannot be reversed, the document must first be

reset.

PAYMENT TERMS AND CASH DISCOUNTS

Terms of payment are conditions agreed between business parameters for the

payment of invoices. The conditions define the due date and the cash discount

offered for payment of the invoice within a certain period.

Some terms of payment are predefined in the system; is possible add news if it is

necessary.

Terms of payment enable the system to calculate a cash discount and invoice

due date. In order to this, the system needs the following data:

Baseline date: the date from which the due date is derived

Cash discount terms: the terms which the cash discount can be taken

Cash discount percentage rate: the percentage rate used to calculate

cash discount

When a document is process, enter the terms of payment so that the system can

calculate the required conditions of payment. If you have entered terms of payment

in the master record, these are proposed. You can also enter or change them

during processing.

Is possible enter terms of payment in the company code segment, sales area

segment, purchasing organization segment of a customer/vendor master record.

Invoice related credit memos

Credit memos can be linked to the original invoice by entering the invoice number

in the invoice reference field during invoice entry. In this case, the terms of

payment are copied from the invoice so that the invoice and the credit memo are

due on the same date

Other credit memos

Terms of payment in other credit memos are invalid. These credit memos are

due on the base line date. To activate the payment terms on these non-

invoice related credit memos.

Payment Control

A block key and payment method, defined in terms of payment are defaulted in the

line item when the terms of payment are used.

Using block keys, which can be entered in line items or accounts, can block

line items or accounts for payment or collection. These block keys can also

be entered in payment terms

A payment method (for each country, the system has payment methods

defined that you can use in that country) is entered in the line items or the

accounts. Like payment blocks, payment methods can be entered in the

terms of payment.

Baseline Date

Is the starting date the system uses to calculate the invoice due date. The following

rules apply for the calculation of the baseline date:

Gen

eral

The DAY LIMIT is the calendar day to which the terms of payment are valid. It allows store single or multi-part termsof payment in a terms of payment key The DESCRIPTION for terms of payment includes the following elements: an

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

printing on invoices

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

The default values from which the baseline date can be determined are as

follows: no default, document date, posting date or entry date

Specifications for calculating the baseline date: fixed day used to overwrite

the calendar day of the baseline date.

The number of month(s) to be added to the calendar month of the baseline month.

Cash discount

To calculate the cash discount, enter a percentage rate in the terms of payment,

also enter the number of days that the percentage is valid for in the same line. You

can also add fixed days and months. Also, system allows enter up three cash

discount periods.

Discount percentage rates

Discount periods

The days and months specified in the terms of payment are used in conjunction

with the baseline date to calculate the correct cash discount amount for the

payment date. Enter up to three cash discount periods.

Day limits

It enables date-specific terms of payment in one terms of payment key. Is possible

define several versions of terms of payment, with each version having a different

day limit.

The day limit is the baseline date up to which the payment term version applies.

For terms of payment that are dependent, allows to enter two-part terms of

payment under the same terms of payment key. The entry for specified day limit is

added to the terms of payment key. This results in two entries where different

terms of payment can be defined. The following terms of payment REQUIRE the

specification of a day limit:

Documents with invoice date up to the 15th of the month are payable on the

last day of following month

Documents with later invoice date are payable on the 15th of the month after

Instalment Payment

An invoice can be paid over several months using an instalment plant, or a portion

of the invoice amount may be retained for payment at later date. The total invoice

amount is divided into partial amounts due on different dates.

The system carries out this split automatically if instalment payment is defined in

the terms of payment. Consider:

Instalment number

Percentage

Payment terms for instalments

The percentage rates specified must total 100%. The system creates a line item for

each installment specified.

The line item amounts correspond to the percentages of the total amount. The total

of the line item amounts corresponds to the total amount. The terms of payment for

the line items are the terms of payment defined for the individual instalments.

Cash discount base amount

Depending on the international regulations of each country, the cash discount base

amount is the net value or gross value. For each company code or tax jurisdiction

code, specify which value the system is to use as cash discount base- this setting

belongs to the global parameters of a company code.

Posting cash discount

Gross procedure

The cash discount amount is entered either manually or automatically by the

system using the rates in the terms of payment. You can still change the cash

discount after you post the invoice. When an open item on a customer or vendor

account is cleared, the possible cash discount is posted automatically to an

account for cash discount expense or cash discount received. Define the

accounts for cash discount expense or cash discount revenue in the configuration.

Net Procedure

The amount posted to expense or balance sheet account is reduced by the cash

discount amount. The same amount is also posted to a cash discount clearing

account to clear the posting. When is used the net procedure, the cash discount

amount is automatically posted when the invoice is posted.

When you use the net procedure, the cash discount amount is automatically

posted when the invoice is posted. When the invoice is paid, the system carries

out a clearing posting to the cash discount clearing account. If the invoice is paid

after the cash discount deadline, the cash discount loss is posted to a separate

account. The cash discount clearing account must be managed on an open item

basis.

TAXES

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

as:

Tax on sales/purchase

US sales tax

Additional taxes (country-specific)

Withholding tax

Two taxation types are possible:

1. Federal/country level, with uniformly defined rates

2. State/jurisdictional level, with rates defined by the state or jurisdiction

In some countries taxes are even levied in both levels

The expense or revenue mount is the base amount is the base amount, which can

include a cash discount (tax base is gross) or exclude a cash discount (tax base is

net). Tax code is used for the calculation procedure required to perform taxation

functions on the SAP system.

National regulations determine whether the tax base amount must be:

Net amount: taxable expense or revenue items minus cash discount

Tax Support

Provides support for

Calculate tax amounts

Posting to defined tax

accounts

Performing tax

adjustments Tax reporting

Calculates tax amounts from

Base amounts with or

without a cash discount

Tax codes to check or

calculate the tax amount

Gross amount: taxable expense or revenue items including cash discount

User can define which amount is to be used for each company ode or for

the highest level of the jurisdiction code.

Tax on Sales and Purchases

The output tax is levied on the net value of the goods and is billed to the

customer. It is a liability of the company to the tax authorities.

Input tax is levied on the net invoice amount and is billed by the vendor. The input

tax is a receivable which the company claims from the tax authority. The tax liability

minus deductible input tax is the tax payable. Tax authorities can define that part of

the input tax is not deductible. This tax amount can be posted to a separate

expense account

Tax calculation procedure

For carrying out tax calculations is assigned to every country.

Condition types are tax calculations that are valid for the country. The base amount

is an expense or revenue item.

Jurisdiction key/code

A jurisdiction code is a combination of codes of tax authorities that tax movements

of goods and use their own tax rates. There are four possible levels below national

level:

1. State

2. County

3. City

4. District

Tax calculation procedures contain:

THE ORDER OF STEPS: which have taken in the tax calculation procedure (the "from step" indicates where the system calls the base of value for "step")

TAX TYPES (CONDITION TYPE): apply for the country. The system is delivered w/consition types necessary for ech type of taxcalculation

ACCOUNT KEY / TRANSACTION KEY: covers additional specification and is used for the automatic auccount determination for the taxes concerned

The tax jurisdiction codes must be defined on every level. You can enter the taxes

per jurisdiction code or per tax level.

Using tax jurisdiction codes involves two steps:

a) Define the length of the individual elements of the code for the format of the

jurisdiction code. This activity also automatically switches over tax

processing for this tax jurisdiction code method

b) The tax jurisdiction codes must be defined on every level

When are post taxes with jurisdiction code, it allows enter the taxes per jurisdiction

code or per tax level.

Tax code

Verify the amount of tax

Calculate the amount of tax

Calculate additional tax portion

Verify the tax type

Determine de G/L account

Show tax correctly on tax forms

Enter a the tax code when post the document and this is the main connection to

the tax calculation. This connection is different depending on whether the country

uses tax calculation procedure with tax jurisdiction codes or not . Tax code is linked

with either of the following

Country key

Combination of country key and tax jurisdiction code

The tax codes with a jurisdictional taxation method are date-specific. In the

configuration, choose whether the document date or the posting date is valid

for the tax calculation.

Tax rates

It are assigned to the tax types used in the tax calculation procedure. A tax code

may have several tax rates entered for different tax types (if a line item is to be

taxed with several tax types), but usually one tax rate is entered.

Some posting to tax-relevant G/L accounts must have a tax rate of zero. This

applies to:

Items that are tax-exempt but have to be reported to tax authorities. For

these items a special tax code with a tax rate of zero is created.

Items that are created by tax exempt transactions such as goods issue,

goods movement, and so on. A special tax code must be assigned to these

transactions in configuration.

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

percentage separate.

If the system detects a deviation between the tax calculated and the tax amount

entered, it either issues an error message (check indicator set) or a warning

message (check indicator not set).

Tax Postings

The taxes calculated by the system are usually posted via a separate line item to

a special tax account. This is the standard scenario.

Taxes with certain transaction/account keys (for example, NVV) are distributed to

the relevant expense/revenue item. This is the case for sales tax payables or other

non-deductible input taxes.

Tax account determination

To enable to automatic tax account determination, it has assigned the following

data to the account/transaction keys that generate the tax item during posting:

Posting keys

Rules that determine which fields the account determination is based on

(tax code or account key)

Tax accounts

When exchange rate differences occur because of tax adjustments in foreign

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

TAX POSTINGS

Standard Scenario: The taxes calculated by the system are usually posted via a

separate line item to a special tax account.

Taxes with certain transaction/account keys are distributed to the relevant expense/revenue item. (Sales tax

payables or other non-deductible input taxes)

account for exchange rate differences. The resulting differences are posted to a

special account.

Tax accounts

Means accounts to which tax items are posted, in the field tax category by

entering one of the following signs:

< for input tax

> for output tax

The properties of the tax code define whether or not the tax posted is an

input or output tax

Post automatically only option must be selected if it does not want to post tax

manually.

Other G/L Accounts

If the Postings Without Tax Allowed field is selected, you can post to this G/L

account without specifying a tax code. This is especially necessary for tax postings

within a jurisdiction code tax calculation procedure to foreign customers who do not

have a jurisdiction code.

Accounts for cash discounts need an entry in the Tax category field if the system is

supposed to post tax adjustments

Special Tax Codes

The acquisition tax code generates two posting items: it posts the acquisition tax

to credit side of the acquisition output tax account and the same amount to

Financials ERP for beginners

Documents

Transcript of Financials ERP for beginners