SAP an overview
SAP is an ERP package, which is used in many companies worldwide. Enterprise Resource
Planning- Resources are Man, Money , Materials, Machine & Information-MIS, Planning –
Integration of all resources for an Business organization.
The full form for SAP is System Application Products in Data Processing (SAP) R3 4.6 version.
The product is German in origin. The full form of ERP is Enterprise Resources Planning.
Previously companies used to do MRP i.e. Material Resource Planning. ERP is the up gradation
of the same. The need for ERP arose due to lack of proper / common database available for all the
functions in an organization.
For example, customer records as per sales department may be showing a different balance
/address in comparison to the records maintained by the accounts department. Stock balance and
value as per Stores department could vary vis-à-vis the values as recorded by the accounts
department. Also typically data / records of various departments were maintained on different
formats or on different platforms. Certain departments of a company could be working in a
computerized environment and that too on different packages / operating systems like Unix
/oracle. Some other departments could be maintaining their records manually.
The situation leads to improper data available to the Management to plan and run their business.
Therefore a need was felt to have a package that has a Common database and interconnects all
departments / functions and also enables Real time R ON LINE entry / access to data/ records.
This consequently led to the development of ERP packages worldwide like SAP (the biggest
player), BAAN, Peoplesoft and J.D.Edwards. R3 3 stand for 3 tiers appl server, Data server &
The features of SAP include various modules and sub-modules. The main modules are financial
accounting-FI, Production planning-PP, Sales and Distribution-SD, Controlling (costing)-CO,
Materials management (MM) and Human Resources (HR). There are various other modules like
Plant maintenance, Quality management etc.
The database is common for all modules and avoids duplication of maintaining master records.
For e.g. the customer records will be maintained in SD module like customer code, customer
type, Credit/payment terms, address etc. The same would be used by the FI module while
perusing the customer accounts or entering the receipt of payments. Similarly the sales manager
can view the customer balances in the FI module for follow up with the customer. Another
example would be Vendor Master maintained in MM module which can be accessed by the FI
module user to check the purchase order details, Delivery schedule, Payment terms etc. Also one
can access information on whether the material order has been received by the stores department,
whether the same is under inspection or if there is any shortage or rejection. Once the material
has been accepted and entered, the systems will automatically pick up the value of the material
from the purchase order. The accounts department on receipt of the invoice can verify the same
through' the MM module and say whether the Goods Inward Notice is available on the system
and give credit to the Vendor's account for the value of the material purchased.
A notable feature of SAP is, wherever a transaction of a financial nature takes place, whichever
module is in use, the system generates an accounting entry, this is contrary to the normal belief
that—transaction takes place only in the accounting department. For example, withdrawal of
material /item through an indent from the stores will not only result into the physical stock being
reduced but also an accounting entry being generated whereby the material consumed A/c (P/L
expense /Revenue A/c) will be debited and the stock account will be reduced (Balance sheet
item). This will lead to generation of an accounting document in MM module itself. The value of
the item drawn could depend on the policy of the company whether it adopts FIFO, LIFO, and
standard cost method s of valuation of stock.
A natural question can arise -- whether the non-financial personnel of a company can undertake
accounting transactions. Herein the initial mapping of the systems and the processes will be done
at the time of the SAP implementation and the accounting impacts will be studied and built into
the Masters for automatic accounting effects for various types of transactions. There is a Master
called Chart of Accounts, which is the backbone of SAP. It contains all accounts with their code,
nature linkages, Groupings etc. Of course this master has to be built very carefully and
The transaction-taking place in SAP will be recorded with the user identification, time and date.
No transaction can be erased. Any erroneous transaction can only be rectified or reversed. Each
transaction being recorded will lead to a specific document number being created based on the
transaction type and the number ranges as defined in the document masters. The user by now can
appreciate that it is a system, which envisages lot of diligence and security. Therefore only
authorized personnel can deal with the system in order to avoid malfunctioning and misuse of the
system. User identification is to be given only to key personnel who are well trained and well
aware of the impact of the transactions to be undertaken by them. Authorizations are given either
for module based and /or screen based transactions. For example, a user in MM module will not
be allowed to operate on FI module. However " view " authorizations for certain personnel can be
given on case-to-case basis. Authorization and monitoring of users have to be done by the System
Administrator. This is a key function and it is very important to avoid misuse/ malfunctioning of
the system. Large and fast servers should be made available for quick access of data. Proper
facilities of back up and UPS should be provided. Care should be taken to avoid loss of data.
SAP is a package with minimal customizations and the company implementing the same may
have to re-orient its business processes to fall in line with SAP requirements.
SAP was founded in 1972 in Walldorf, Germany. It stands for Systems, Applications and
Products in Data Processing. Over the years, it has grown and evolved to become the
world premier provider of client/server business solutions for which it is so well known
today. The SAP R/3 enterprise application suite for open client/server systems has
established a new standards for providing business information management solutions.
SAP product are consider excellent but not perfect. The main problems with software
product is that it can never be perfect.
The main advantage of using SAP as your company ERP system is that SAP have a very
high level of integration among its individual applications which guarantee consistency
of data throughout the system and the company itself.
In a standard SAP project system, it is divided into three environments, Development,
Quality Assurance and Production.
The development system is where most of the implementation work takes place. The
quality assurance system is where all the final testing is conducted before moving the
transports to the production environment. The production system is where all the daily
business activities occur. It is also the client that all the end users use to perform their
daily job functions.
To all company, the production system should only contains transport that have passed all
SAP is a table drive customization software. It allows businesses to make rapid changes
in their business requirements with a common set of programs. User-exits are provided
for business to add in additional source code. Tools such as screen variants are provided
to let you set fields attributes whether to hide, display and make them mandatory fields.
This is what makes ERP system and SAP in particular so flexible. The table driven
customization are driving the program functionality instead of those old fashioned hard-
coded programs. Therefore, new and changed business requirements can be quickly
implemented and tested in the system.
Many other business application software have seen this table driven customization
advantage and are now changing their application software based on this table
In order to minimized your upgrading costs, the standard programs and tables should
not be changed as far as possible. The main purpose of using a standard business
application software like SAP is to reduced the amount of time and money spend on
developing and testing all the programs. Therefore, most companies will try to utilized
the available tools provided by SAP.
The sole purpose of an R/3 system is to provide a suite of tightly integrated, large-scale
The standard set of applications delivered with each R/3 system are the following:
• PP (Production Planning)
• MM (Materials Management)
• SD (Sales and Distribution)
• FI (Financial Accounting)
• CO (Controlling)
• AM (Fixed Assets Management)
• PS (Project System)
• WF (Workflow)
• IS (Industry Solutions)
• HR (Human Resources)
• PM (Plant Maintenance)
• QM (Quality Management)
These applications are called the functional areas, or application areas, or at times the
functional modules of R/3. All of these terms are synonymous with each other.
Traditionally, businesses assemble a suite of data processing applications by evaluating
individual products and buying these separate products from multiple software vendors.
Interfaces are then needed between them. For example, the materials management system
will need links to the sales and distribution and to the financial systems, and the
workflow system will need a feed from the HR system. A significant amount of IS time
and money is spent in the implementation and maintenance of these interfaces.
R/3 comes prepackaged with the core business applications needed by most large
corporations. These applications coexist in one homogenous environment. They are
designed from the ground up to run using a single database and one (very large) set of
tables. Current production database sizes range from 12 gigabytes to near 3 terabytes.
Around 8,000 database tables are shipped with the standard delivery R/3 product.
At the start of any project one of the first and most important things to be done is
that your current best guess of your businesses organisation structure must be
configured in the SAP System. The sooner you do this and the more accurately
you do this, the quicker and better the project team can get on with prototyping or
configuring the rest of the system. Some functionality is quite dependent on
which SAP organisation elements you chose to represent various aspects of your
organisation. So to avoid wasting too much time, it is very important to get
appropriate skills working on this design ASAP in order to ensure that the initial
configuration is reasonably appropriate.
Each module of SAP tends to have its own organisation elements, although
some are shared across modules (plant, division etc). If an element is very
specific to that module with localised usage, then I have not explained it here.
Adequate explanation should be in the R/3 Library.
Key SAP Organisation Elements / Structures:
Following is a summary of the key elements for organisation structure and functionality
decisions. Follow the link on each for more detail and guidelines on how to configure.
The 'integration' section on this site will provide some further tips.
Elements Owning Description
Company FI Mandatory, used for lowest legal
Business FI Optional used for cross
Area company balance sheet
Profit Centre CO-PA Optional, used for profit and
return on investment reporting.
See also module decision on
CO-PCA vs CO-PA.
Cost Centre CO mandatory for responsibility level
overhead expense reporting
Sales Area SD mandatory, actually a
combination of the SD elements :
Sales Organisation, Distribution
Channel and Division
Purchasing MM mandatory - could be just one.
Organisation See R/3 library
Relatively "Uninteresting" SAP Organization Elements:
Several SAP organization elements are required purely as the top node of the
module providing an 'environment' under which a single set of data exists. Data
can usually not be shared across these 'top node' elements. These elements are
usually invisible to the users and can often be excluded from training or
explanatory diagrams. For that reason I do not see much point in discussing
them here - adequate information on their definition and relationship to other
elements is in the R/3 library. These elements are:
Controlling Area CO - Controlling
Operating Concern CO-PA - Profitability Analysis
Financial Management Area TR - Treasury
Credit Control Area FI-AR & SD (Credit Management)
SAP Master data which represents the Organisation Structure:
In controlling, the Cost Centre and Profit Centre Hierarchies are also used to
represent the organisation or enterprise structure. SAP considers these as
'master data' though not as organisation elements. Therefore maintenance of
these is not found in the Enterprise Structure area of the IMG. However they
are worth discussing here. Organisation Structure issues relating to these are
presented in two sections
What is the SAP FI Module?
- Introduction -
The SAP FI Module has the capability of meeting all the accounting and financial needs of an organization.
It is within this module that Financial Managers as well as other Managers within your business can
review the financial position of the company in real time as compared to legacy systems which often times
require overnight updates before financial statements can be generated and run for management review.
The real-time functionality of the SAP modules allows for better decision making and strategic planning.
The FI (Financial Accounting) Module integrates with other SAP Modules such as MM (Materials
Management), PP (Production Planning), SD(Sales and Distribution), PM (Plant Maintenance),and PS
The FI Module also integrates with HR (Human Resources) which includes PM (Personnel Management),
Time Management, Travel Management, Payroll. Document transactions occurring within the specific
modules generate account postings via account determination tables.
The FI (Financial Accounting) Module components.
The FI Module comprises several sub-modules as follows:
o Accounts Receivables
o Accounts Payable
o Asset Accounting
o Bank Accounting
o Funds Management
o General Ledger
o Special Purpose Ledger
o Travel Management
Accounts Receivables records all account postings generated as a result of Customer sales activity.
These postings are automatically updated in the General Ledger . It is within the Accounts
Receivables Module that you can monitor aging of the receivables and generate customer analysis. The
Accounts Receivable Module also integrates with the General ledger, Sales and Distribution, and Cash
Accounts Payable records account postings generated as a result of Vendor purchasing activity. Automatic
postings are generated in the General Ledger as well. Payment programs within SAP enable the payment of
payable documents by check, EDI, or transfers.
Asset Accounting is utilized for managing your company’s Fixed Assets. SAP allows you to categorize
assets and to set values for depreciation calculations in each asset class.
Bank Accounting allows for management of bank transactions in the system including cash management.
Consolidation enables the combining of financial statements for multiple entities within an organization.
These statements provide an overview of the financial position of the company as a whole.
Funds Management allows management to set budgets for revenues and expenses within your company as
well as track these to the area of responsibility.
General Ledger is fully integrated with the other SAP Modules. It is within the General Ledger that all
accounting postings are recorded. These postings are displayed in real-time providing up-to-date visibility
of the financial accounts.
Special Purpose Ledger is used to define ledgers for reporting purposes. Data can be gathered from internal
and external applications.
Travel Management provides management of all travel activities including booking trips and handling of
expenses associated with travel.
Primary configuration considerations:
Client, company and company code
Once a business has decided to use the SAP FI (Financial Accounting) Module, there are
several Configurations prerequisite steps that must be completed. Determining the organizational
structure is one of the first steps in setting up the business functions in SAP as well as your
The Organizational structure is created by defining the organizational units consisting of the following:
o Company Code
o Business Area
A Client (MANDT) is the highest unit within an SAP system and contains Master records and Tables. Data
entered at this level are valid for all company code data and organizational structures allowing for data
consistency. User access and authorizations are assigned to each client created. Users must specify which
client they are working in at the point of logon to the SAP system.
A Company (RCOMP) is the unit to which your financial statements are created and can have one to many
company codes assigned to it. A company is equivalent to your legal business organization. Consolidated
financial statements are based on the company’s financial statements. Companies are defined in
configuration and assigned to company codes. Each company code must use the same COA( Chart of
Accounts) and Fiscal Year. Also note that local currency for the company can be different. In General
Ledger Accounting you have the option of managing all company code values in parallel in the same
accounts in up to three currencies
Company Codes (BUKRS) are the smallest unit within your organizational structure and is used for internal
and external reporting purposes. Company Codes are not optional within SAP and are required to be
defined. Financial transactions are viewed at the company code level. Company Codes can be created for
any business organization whether national or international. It is recommended that once a Company Code
has been defined in Configuration with all the required settings then other company codes later created
should be copied from the existing company code. You can then make changes as needed. This reduces
repetitive input of information that does not change from company code to company code as well as
eliminate the possibility of missed data input.
When defining company codes, the following key areas must be updated:
o Company Code Key- identifies the company code and consists of four alpha-numeric characters.
Master data and business transactions are created by this key.
o Company Code Name- identifies the name of the business organization within your organizational
o Address- identifies the street address, city, state, zip code for the company code created. This
information is also used on correspondence and reports.
o Country- identifies the country to which your business is based. Country codes within SAP are based
on ISO Standards.
o Country currency- identifies the local currency for the company code that you have defined.
o Language- identifies the language to be used for you company code and is also used for text in your
documents. SAP unlike other applications, offers over thirty languages including EN( English) , ES
(Spanish), FR (French), DE (German), EL (Greek), IT(Italian), AR( Arabic), ZH (Chinese) , SV
(Swedish) , and JA (Japanese) to name a few.
More FI configuration considerations:
Business Area, COA, GL, Fiscal year and Currencies
Business Area is optional and is equivalent to a specific area of responsibility within your company or
business segment. BA (Business Area) also allows for internal and external reporting.
The SAP Business Area is an FI organisational element which is intended to provide Financial Statements
below or across company codes. The standard GL, financial statement functionality and reporting all
However it is important to understand how SAP implements this, because it is by no means the same as the
company code. The following points must be noted:
• SAP company code will always be in balance, all the time, document by document. The SAP
Business Area will not. i.e.: it is possible to post a DR to one Business Area and a CR to another,
or to leave one line item with a blank business area.
• Business Area is not a mandatory field. It is dangerous to attempt to force this. It is not always
possible for the system to determine the appropriate business area, it will then post a blank
business area (unless you have 'forced' a substitution, which often just has the effect of replacing
'blank' with some other default).
• SAP 'rectifies' this out of balance situation by providing period end programs which 'clean up' and
post adjusting journals or inter-business area journals depending on the situation. See the
documentation on these period end programs in the GL module. F.5d-Calc, F.5e-post.
• Reporting by Business Area is available during the month (albeit out of balance) and visible within
GL accounts. Compare with Profit Centre implementation below.
Another configuration requirement for set-up in SAP are the Basic settings consisting of the following:
o Chart of Accounts(COA)
o Fiscal Year Variants.
The COA(Chart of Accounts) lists all General Ledger accounts that are used by the organization. It is
assigned in configuration to each company code and allows for daily General Ledger postings.-OB13,OB62
The General Ledger accounts are made up of such data as account number, company code, a description of
the account , classification of whether the account is a P & L Statement Account or a Balance Sheet
• Control data of the GL Account is where currency is specified, Tax category (posting without tax
allowed), marking the account as a reconciliation account (e.g. Customer, Asset, Vendors,
Accounts Receivable) or not.
• Marking the G/L Account as a “reconciliation” account allows for postings to an Asset Account
( for example) as well as automatic update to the G/L Account.
• Configuration prevents direct postings to reconciliation accounts thereby assisting in maintaining
integrity of the data.
• This allows reconciliation between the sub-ledger and general ledger to always be guaranteed.
• Within the General Ledger control data, you can also designate whether line item display is
possible in the account. The system then stores an entry per line in an index table which links back
to the account. (Display of line item details are then available for reporting purposes, etc.)
• Open Item Indicators can be set on the G/L Account allowing for better management of open
items. Examples include: Bank Clearing Accounts, GR/IR Clearing Accounts, Payroll, etc.
Fiscal Year configuration is a must and can be defined to meet your company’s reporting periods whether
Fiscal (any period combination that is not calendar) or Calendar( Jan-Dec). OB29,OB37
• Posting Periods are defined and assigned to the Fiscal Year.
• Within the periods you specify start dates and finished dates.
• SAP allows for 12 posting periods along with specially defined periods that can be used
for year-end financial closing.
Currencies are another basic configuration setting requirement which defines your company’s legal means
of payment by country.
• It is recommended that all Currency set-ups in SAP follow the ISO Standards.
• The ISO Standards ensure Global conformity across businesses worldwide utilizing SAP.
What are some of the integration points of the FI module?
SAP is marketed as a fully integrated system, therefore knowing some of the integration points
enables the Users to better understand the Modules.
· Organization units are not only defined in FI(Financial Accounting) but also in other SAP
Modules. The SD( Sales & Distribution) Module requires the set-up of Sales Organizations,
Distribution Channels and Divisions ; Purchasing requires purchasing organizations, plants, and
storage locations; and CO (Controlling) requires a Controlling area to be defined.
· To transfer data between FI(Financial Accounting) and CO (controlling) as well as other
modules, a Company Code must be assigned to each of the Modules.
· Business Areas must be entered when generating business transactions if you would like
visibility of those transactions impacting a certain BA(Business Area). You can also update your
Master Records to include BA(Business Area) for example Cost Center.
· Document postings are automatically posted in the year and periods that you created in the
Fiscal Year variant set-ups based on the month, start and end dates to which postings are
allowed within a given period as defined.
· There are several integration points in SAP, the above lists a few
SAP FI GL
• Company code configuration which includes creating chart of accounts, EC01,OBY6, OB13
• Creating posting period variant, defining retained earnings account,-OB52, OB53, F yr var OB29,
OB37-FY var to co code,
• Creating document types OBA7-types. Define tolerance groups for employees, imgGL->post->
open item clear-> cl. diff –tolerance gr. OBA0- tolerance G/l, OBA4-Emp,OBA3-Vend/Cust
• Configuration for Maximum exchange rate differences OB08- rate, OBBS give ratio
• Configuring parallel currencies OY03,OY04-decimal place
• Configuration for automatic clearing OBXH-keys, OBXM- cl. Acc, OB74-add rules, OBC7-
Witholdin tax,OBXZ-cl .diff, OBYA- Cross co code
• Configuration for foreign currency valuation OB59- val Methods,OBA1-Posting Auto Valuation
• Configuration for regrouping of GR/IR clearing OBYP
• Creating financial statement version OB58 i.e. defin.balance sheet and profit &loss account FSE2
• Integration - FI- MM automatic account assignment, FI- SD automatic acc. assignment OBYC,
SAP AR & AP & Bank accounting
• Configuring account groups for Customers and Vendors, defining screen layout per activity for
customers and vendors O7F4,O7F5,O7z5
• Deleting customer data OBr2
• Configuring payment terms
• Automatic account assignment for various AR & AP transactions like bank charges-OBXK,
overpayments/underpayments OBXL, exchange rate differenceOB09, rounding differences
OB00,Cash Disc OBXU. spro AP/AR ->B trans.->Outgoing pay->Globl.Sett.
• Configuring payment block reasons OB27
• Configuring automatic payment program IMG FA -> Acc Rec & Acc Pay -> Business
Transactions -> Outgoing Pay -> Auto Outgoing Payments -> Payment Method/Bank Selection
for Pay Program, setting for display payments* line item(line lay,search fld,sort fld), Auto Posting
• Includes House bank configuration FBZP (OBVU,OBVCU,FI12),FCHI
• Configuring the manual bank reconciliation and the electronic bank reconciliation
• Configuration for dunning
• Configuration for special G/L transactions like down payment made, down payment received
• Configuration for regrouping according to maturity
SAP Asset Accounting
• Creating/Copying Depreciation Areas EC08,OADB- Assignment to company Code OAOB,
• Input Tax Indicator Configuration OBCL , Screen Layout Rules IMG Org Str.->Ass Cl ->cr SL
• Specify Account Determination Rules - Define Asset Classes, Number Ranges OAOA, AS08
• Critical Check Boxes Notification
• Integration of Asset Accounting with General Ledger AO90, Defining Posting Rules to Cost
Center OAYR, Specify Financial Statement Versions for Asset Accounting OAYN
• Complex Depreciation Calculation Procedures- Setting up of Depreciation Areas, depreciation
key, Define Cut off Value key OADB, AFAMA,OAYZ
• Defining the crucial Base Methods, Declining Balance Methods, Multilevel Methods, Maintaining
Period Controls AFAMS,AFAMD, AFAMP,OAVH-assign calendar
• Pre Production Go Live Activities and Their Configuration
SAP Cost Center Accounting
• Maintaining controlling area settings, which includes defining modules which are active i.e. profit
center, profitability analysis, internal orders. Assigning company code to controlling area.
• Multiple valuation approaches/transfer prices - maintaining currency and valuation profile
assigning it to controlling area, creating actual versions for parallel valuations
• Cost element accounting - creation of various types of cost elements
• Settings for Reconciliation Ledger which includes defining adjustments accounts for
• Creating cost center hierarchy, cost center, cost center groups, activity types, statistical key figures
• Creating planning layouts for cost center planning
• Configuring various allocation cycles - Distribution, assessment, indirect activity allocation.
Configuring the splitting structure
• Configuring automatic account assignment table.OKB9
SAP Product Costing & Material Ledger Configuration
• Product Cost Planning- Detailed configuration of overhead keys, costing sheets, overhead groups
and Complete Cost Component Structure
• Material Cost Estimates - In depth configuration and analysis of the Costing Variants including
Valuation variant, Transfer Strategy and Costing Types
• Special Features of Cross Company Costing
• Complete Cost Object Controlling Configuration across various industries including Repetitive
• Complete Integration with Production Planning on Default Order types, parameter checks
• Work in Progress Configuration- Calculation of Results Analysis keys, Valuation Method and
• Detailed Variance Calculation configuration and setting up of Variance keys
• Setting up the Settlement Profile, Allocation and Source Structure including the complex PA
• Detailed configuration for Sales Order Costing - Make To Order (An absolute steal)
• Detailed configuration for Make to Stock ( An absolute steal)
• Detailed configuration of Material Ledger ( A real value add)
SAP Profit Center
• Maintaining profit center settings, creating dummy profit center, making settings for actual flow of
• Maintaining profit center hierarchy, creating profit center
• Maintaining settings for transfer prices
• Maintaining planning layout for profit center planning
• Configuring allocation cycles - Distribution, assessment
• Maintaining automatic account assignment of revenue elements
• Maintaining the additional balance sheet and profit and loss accounts (3KEH)
Enough FI/CO configuration to get going...
FI the Financials module can be thought as the 'core' of any integrated SAP System because
everything that has a monetary impact in the other modules (where the 'real' business operates)
flows through to FI - usually in real time and automatically through the configuration. Usually
there is pressure to get going with the prototyping asap. When the other modules start
prototyping their transactions, the SAP system is going to want to post the financial impact to FI.
Thus the sooner that you (the FI/CO configurer) can get some core FI/CO configuration going the
better for all.
Remember all SAP configuration is essentially maintaining entries in a variety of linked tables.
Usually you need to maintain each little link or entry step by step. Some new SAP configurers
expect the transactions to be as 'complete' as a user transaction - configuration is different. In
R/2 days we had to just know what tables to maintain - count yourself lucky that you have the
Following are some guidelines (in increasing levels of functionality) to the FI minimum
configuration or master data setup for a new company code. Follow the logical path in the IMG.
1. Minimum configuration to post a journal in FI
2. Minimum configuration to see expenses by cost centre / post through to the CO Module
3. Minimum configuration to post to subledgers (AR, AP)
4. Minimum configuration to post from logistics modules to FI/CO (similar concept for other
Minimum configuration to post a journal in FI:
(The assumption is that you do not want to copy either the standard SAP company or an existing
company code because it will copy across too much that is not similar or not required and
therefore too much cleanup will be required).
Initial Business Decisions Required:
Item to be decided Comment
Code of company code (4 Digit You could setup new one later, copying the configuration
Code of Chart of Accounts Not very visible, but the maintainers of the chart may want to
decide this name
Length of the GL A/c number and SAP allows 10 digits, however 5-7 appears to be the normal
the account number range range. Typically the number of accounts should be in the low
guidelines, possibly also the hundreds. Decide on the ranges of numbers for each type of
numbers of some key accounts account as much as you can so that the team can start getting
required for automatic postings used to them. EG: standard SAP usually has 4xxxxx as
(see below) expense accounts, 11xxxx as Bank Related accounts etc.
Define the company code IMG
Define the name for a chart of IMG
Maintain the global parameters IMG - Use standard SAP variants for the parameters to start
with & update later
Define the default amount IMG - Define for a blank group - so any new test user can post
tolerances during prototyping
Define document number ranges IMG - Copy from the standard ranges
Create some of the minimum GL Master data:
accounts needed to start off with. A/R and A/P control a/cs, a petty cash or suspense a/c to hold
sundry offset postings while debugging, a revenue account,
some expense accounts. This list will expand as you go - see
the section on account determination.
Suggest you create with reference from the standard chart and
company code and use those specifications (account groups,
fields status groups etc) for now, so that these accounts will be
reasonably appropriately setup.
EC01 click on copy code copy wrt earlier co code.from exiting co code to new
Thus new co code s010 copied wrt s001
Run check & delete if not reqd.
You can set up several company codes per company to manage the accounts of
independent organizations simultaneously. At least one company code must be set up in
OB13- edit chart of accounts
OB62- assign COA to Co Code
OB37- assign fiscal yr variant to Co Code, OB29 maintain Fisc. yr var.
OB52- Open and Close Posting Periods
In this activity you specify for each variant which posting periods are open for posting. Two intervals are
available for doing this (period 1 and period 2). For every interval, enter a lower period limit, an upper
period limit and the fiscal year.
You close periods by selecting the period specifications so that the periods to be closed are no longer
You can also assign authorization groups for permitted posting periods. This means that, for example, some
posting periods can only be opened for particular users within monthly or annual closing. You can only
assign the authorization group at document header level and it only affects period 1. The authorization
object is called F_BKPF_BUP (Accounting document: Authorizations for posting periods).
Posting Period Variant Ob52
This describes the specifications for a posting period (for example, beginning and end).
Each company code refers to exactly one variant. Therefore, as many company codes as you require can
use the same variant.
Number range copy to Co Code.-OBH1 copy wrt P300
OBH2 – Number range copy to Fiscal year- part of year end activities
In this activity you create number ranges for documents. For each number range you specify
(among other things):
a number interval from which document numbers are selected
the type of number assignment (internal or external)
You assign one or more document types to each number range. The number range becomes
effective via the document type specified in document entry and posting.
You can use one number range for several document types. This means you can differentiate
documents by document type but combine them again for filing the original documents, provided
you store your original documents under the EDP document number.
Number ranges for documents are company code-dependent. You must therefore create your
number ranges for each company code in which the document type (OBA7) is used, namely with
the same number range key.
1. Determine how document filing is to be carried out in your company codes.
2. Define your number ranges accordingly.
3. Make sure that the number ranges are assigned to the corresponding document types.
Attributes that control the entry of the document or which are themselves stored in the document
are stipulated for each document type. In particular, the number range assigned to the relevant
documents is determined on the basis of the document type.
Acc Types-Asset,Vendor,Customer,Material,G/l Acc
Number range is assigned to Doc Type in OBA7 as seen in Properties tab
Click on Number range Info –button we get
OMR4- Number assignments for acc doc in Inv. Verification -MM
GGB0 – maintain validation –General for all modules
Now you should at least be able to post a GL journal. To test I suggest you use balance sheet
accounts only, since you will not have setup the cost elements for the expense accounts. All
projects would at least be using the Cost centre and Cost Element functionality of CO as a
minimum. So - on to the next step.
Add new business area to Co Code set by GS02- co code set ZBAP110(for P110),ZBAP120(for
co code P120)
OX18- Assign Plant to Co code
OMJ7- Assign BA to Plant valuation area
2. Minimum configuration to see expenses by cost centre / post through to the CO Module
Initial Business Decisions Required:
Item to be decided Comment
Structure of standard cost centre The structure should follow the organisations intended
hierarchy responsibility reporting hierarchy (the budgetary responsibility).
Allow the appropriate number of levels.
Hierarchy node name coding The coding of the nodes is quite important because they can be
used to report on the levels in the standard reports, and so will
be very visible to the users
Cost Centre Naming Standards Useful to begin following the intended standards ASAP so that
test data looks as real as possible.
Define the controlling area IMG, not very visible to users, if you are only going to have one,
you could default it later- EC16, Ox06
Assign the company code to the IMG- OX19
Create the beginnings of the CO - Cost Centre Master data-OKEON
standard cost centre hierarchy
Create a representative set of CO - Cost Centre Master data,KS01 KSH1
cost centres, assigning them to
the appropriate node in the cost
Create all the expense accounts Either in the IMG - for all GL accounts in a specific range, or
as primary cost elements individually in the CO - Cost Centre Master data-KA01
Now you should be able to post a GL document (journal) to an expense account and code it to
the cost centre. The posting should then be viewable via Cost Centre reporting and GL Account
line Item Display.
3. Minimum configuration to post to subledgers (AR, AP)
Initial Business Decisions Required:
Item to be decided Comment
GL Account Number of Control see account number range comments above
Create the AP and AR Control see account creation comments above
accounts in the GL
Create a couple of customer and If using SD and MM too, inform the SD and MM analysts so that
vendor accounts they can complete the account creation on the SD/MM side for
the customer and vendor respectively.
Now you should be able to post a FI-AR customer invoice and an FI-AP vendor invoice.
4. Minimum configuration to post from logistics modules to FI/CO (similar concept for other
So far it was relatively easy going, now it starts getting a little more difficult. Following are the
very broad steps - for more detail see the sections on Organisation structure and Integration.
Initial Business Decisions Required:
Item to be decided Comment
SD and MM organisation Not a trivial decision, and may require rework, so at this stage,
structure and relationship to the decide on a simple best guess with the SD/MM team to get you
FI/CO elements going
Assign the SD and MM IMG; to get prototyping going you need at least 1 set of working
organisation elements to the FI/CO relationships that the whole team can work with (EG: 1 Sales
elements Area, 1 Purchasing Organisation, 1 Plant etc)
Maintain the basic automatic IMG; For example : Revenue Account Determination for SD. As
account determination for each the modules test or prototype expanded functionality, the SAP
module will look for the accounts to which it should post. You could
maintain on an as needed basis. The SAP documentation and
configuration does not always explain clearly which piece of
account determination is used for which type of functionality, so
it is sometimes difficult to be pro-active. being reactive has the
benefit that hopefully each side (eg: MM and FI) can develop an
understanding of what the business transaction is and therefore
where it should be posting. Otherwise the MM person may not
even be aware that he has generated a certain type of posting !
(You'd be amazed at some of the lack of ownership from a
logistics consultant for the financial postings that they generate).
Now the other modules will be able to process a thin 'path' using agreed organisation elements
and base functionality, all the way through to FI.
Congratulations - you now have enough absolutely mandatory FI configured for the start of
In this chapter I point out the periodic process that run across modules and the organisation
structure relationships that can be defined by the setup of the periodic process. This is taking an
'integration' perspective and therefore does not include periodic processes within all modules (that
is addressed on a module by module basis).HR Master PA20
Module to Module Process Comment
Posts payroll (salary, wages, expenses, bonus etc)
HR-Payroll to FI &
Payroll Run related costs to the appropriate GL accounts and cost
collectors (cost centres, projects etc).
MM to FI & CO Any changes to Stock Valuations
PP to FI Work in Process
PP to FI & CO-PA Production Posts variances from the production (product cost)
Variances estimates or standards to the GL accounts and to
Profitability Analysis if real costs are required (vs
standard costs). Standard cost figures would have been
used to update Stock and Cost of Goods sold figures
when finished stock was issued from the production runs.
Allocates costs from cost centres to profitability
CO to CO-PA Assessments
Posts asset depreciation values to the GL accounts and
AA to FI & CO Depreciation
to the owning cost centres.OAYR
Profit Centre Required if profit centres could not always be determined
adjustment (as with taxes etc); same as business area adjustment
FI to PCA Transfer of
Posts periodic 'point in time' balances to profit centres for
'return on investment' type reporting (optional)
Profitability Required if cash discount and exchange rate differences
FI to PCA or CO-PA Segment posted after revenue had already gone to CO-PA, is
adjustment required to be in CO-PA too.
Only required if
1. You have allowed the use of cost transfer or repost
CO to FI transactions, periodic reposting or distributions in CO
2. you wish to reconcile CO to FI
Periodic Processes can also define some relationships between organisation elements. These
are largely in the CO area Possible Organisation structure relationships in periodic processes that
are not already covered in master data.
Module Sender Receiver Periodic Process
CO production order
orders Settlement of costs
order See settlement
project and/or revenues
network header configuration
asset periodically or at end
CO network activity documentation in IMG
network activity of order specified by
cost object for details and notes
profitability segment sender to one or
production order on restrictions
sales order many receivers.
one or many of : Distribution or
Cost centers, Configurable - Periodic reposting. See allocations
orders, basically single This can be done for configuration
CO WBS elements, and values or groups of Processes (In activity documentation in IMG
cost objects CO objects (cost based costing) too. for details and notes
per allocation centres etc) This is not the same on restrictions
segment. as activity allocation
Activity Allocation -
Cost Centres and/or passes costs on See IMG - this is a
CO Cost Centre
Orders using activity large area.
Automatic Account Determination
This is perhaps the part that causes the most heartache for the FI Configurers. For some
reason, although it is an integration area, the FI team always ends up with responsibility for it. To
do a good job you need a reasonable understanding of :
1. the business processes in the source modules
2. the FI account postings that they should be generating (what sort of account should be
debited or credited etc)
3. the organisation structure and its relationships between the source modules
4. the reporting requirements that are expected from the General Ledger or Profit Centre
5. your chart of accounts
Sounds daunting doesn't it ? Here is a suggested approach ...
The IMG section under GL / business transactions / integration will take you through all the
necessary account determination for the automatic postings that the system may need to post.
You may not need all of these. You could maintain on an as needed basis. As the project teams
test or prototype their expanding functionality, the SAP system will look for the accounts to which
it should post. The error message and the SAP documentation and configuration does not
always explain clearly which piece of account determination is used for which type of
functionality, so it is sometimes difficult to be pro-active.
Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an
understanding of what the business transaction is and therefore where it should be posting.
Otherwise the MM person may not even be aware that he has generated a certain type of posting
! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial
postings that they generate).
I will be explaining each account determination area simply and clearly with posting examples
• SD to FI Account Determination (aka revenue account determination). This and MM
seem to confuse people the most.
• More later - This may take a while to complete........
In the meantime, some general warnings:
• Whenever you change the field status settings for an account, ensure that you have
verified that any automatic postings will be able to meet the requirements. eg: do not
make business area mandatory if your system may make a posting which cannot
determine and post the business area.
• Consider specifying that accounts that are posted to automatically can only be posted to
automatically. This will simplify reconciliation between the source module and the GL
account should you need to do this.
SD-FI Account Determination and Postings
This is known in the IMG as "revenue account determination", but it covers a lot more than that
(discounts, taxes etc). This is what determines how the financial impact of your SD Billing
document is posted into the FI General Ledger.
The integration is controlled both in SD and in FI.
In SD there is a awesome area of configuration called the pricing procedures. The pricing
procedure determines the final price quoted to the customer for a particular product. This could
be a complicated calculation taking into account the base price, any special prices or discounts
that may apply to that scenario, taxes, freight charges etc. These prices or charges are called
'condition types'. This condition technique is used in a number of areas of SAP.
For now all we need to know is that each condition type is assigned to an account key (or in the
case of rebates two account keys). You can assign multiple condition types to the same account
key. There are a number of account keys that are pre-defined in the system. For example:
• ERF freight revenues
• ERL revenues
• ERS sales deductions
• EVV cash settlement
• MWS sales tax
Now we start getting to the integration by mapping the account keys to GL accounts. But it is not
as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple
approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one
does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of
detail that you need in GL should be determined by your financial statement reporting
requirements - you may end up with only one Revenue account - it is a good bet!
So, taking the simple approach we would ignore most of the configuration possibilities :
procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in
again. Once you have worked through it once in one area and encounter it in another then
hopefully you will be comfortable in knowing that most of the standard configuration can be left as
We have to decide which access sequences we want to use (Five access sequences are defined
in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example:
the access sequence "chart of accounts/sales org./account keys".
The chart of accounts part is standard in all account determinations, so let us look at the rest.
This access sequence allows us to specify different GL accounts for different Sales
So if we had a billing document line item where the customer had some special deductions for
one of the products he purchased, we could map accounts by Sales Organisation. To make it
even simpler a document is within one Sales Organisation so we have an overall mapping as
SD Line Account Sales
Condition type SD Amount GL Account
Item Key Organisation
Sales deduction for being 800010 - Sales
such a nice guy deductions for 1000
Sales deduction for
special promotion on $15 ERS 800000 - Revenue
particular product for Sales Org 1000
Base Revenue $200 ERL
Total for item 1 $175
800000 - Revenue
2 Base Revenue $100 ERL 1000
for Sales Org 1000
Total for item 2 $ 100
Document Total $ 275
So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoice
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275
The GL document posting that the system will make to FI will look something like this though:
FI Line Item Debit / Credit Account Amount
1 Debit (PK=01) Customer (AR Account) $ 275
2 Revenue (GL Account) -$ 300
Sales Deduction (GL
3 Debit (PK=40) $25
Balancing to 0 as all GL documents must.... $0
Note : There is no direct relation between an SD Line item and an FI Line Item - they are
• Remember that if you are using business areas, then depending on your configuration
there, the system may create additional FI line items if it needs to post to different
business areas. This may be even more of a reason why you do not need additional GL
accounts. If your Sales Organisations already map to different business areas, you could
use the GL accounts for all Sales Organisations.
• Different access sequences will allow a broader variety of GL accounts (for example: by
customer account) group. I strongly suggest having a good understanding of the
reporting requirements expected to be supported from the General Ledger vs the SIS
(Sales Information System) or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre
modules before you create too many GL accounts. At the risk of repeating myself, the
SD to FI account determination should only be as detailed as your statutory reporting
requirements. The reporting from other tools like Profitability Analysis are so much more
flexible and powerful, you may never look at the General Ledger for internal profit
reporting again except to do a reconciliation check.
The SAP Condition technique
Conditions have many uses in SAP. The easiest to understand or to relate to is usually in
Pricing, where conditions are used to specify the many components of a price (base price,
surcharges, discounts, freight, taxes etc). These components may differ for different customers,
materials, regions - in fact they may differ in a lot of ways depending on the particular businesses
requirements. We may give a customer in West Australia a better price or discount for a product
than a customer in NSW for example.
We start with a procedure which I think of as a "spreadsheet". This "spreadsheet" tells the
system the calculations to do and the order in which to do them to calculate the final price or cost
of an order item. Each type of calculation is specified by a condition type. In other words the
condition type is simply telling the system what kind of calculation to do (a flat amount or a
percentage for example). It does not in itself say what numbers to use.
Line Number Based On Line
20 Discount 20
When an order is entered into the system, the system knows a whole lot of information
(everything it can get from the customer master, the material master and whatever was entered
on the order itself).
It first works out which procedure to use (using procedure determination configuration). Then for
that procedure, it needs to look up what numbers to use for the calculations in the "spreadsheet".
ie: what prices apply here, what discounts, what taxes for this customer, material etc.
For each condition type (or calculation type), there can be lots of records in the system with
numbers (e.g.: lots of different prices). The system needs to know which is the right record (or
price) and in which order should it look for the right record. The configuration lets us specify an
"access sequence" for each condition type. The access sequence tells the system in what order
to should "access" or look for records.
For example for the 'PRICE' condition type it may have the following order:
'Price' Access (Look Up) Sequence
Region / material 100
Customer Group / material 120
So the system will first look in table 100 which is keyed by region and material, and will look last
in table 200, which is keyed just by material. Each condition table will have some condition
records (master data). For example table 100 may have:
Region Material Price
WA X 10
NT X 12
A X 11
For a condition record
For a condition record to be the 'right' record, the information in the order, customer master or
material master must match the key of the record. If not then the system will go on to check the
Worked Examples using data from the example tables above
Customer Region Material Price
1234 A NSW X 11
1224 A WA X 10
2346 C QLD X 15
1224 A WA Y 200
A similar lookup is then done for each condition type. E.g.: the discount condition could specify
various percentage discounts.
For the tax condition type, it is most likely that the tax classification fields on the customer and
material master would be used as keys for the tax condition records
This section addresses the requirement to provide profit reporting. The main decision which typically has
to be made is which module to use.
If your company is using the SD module, then the question is often between the CO-PA Profitability
module and EC-PCA the Profit Centre module.
If your company is a financial or government organisation and/or you are not using SD, then you are
probably considering the EC-PCA Profit centre module. You should consider the CO-CCA vs EC-PCA
discussion to determine whether perhaps you could get away with just using the CO-CCA Cost Centre
Limited Profit Reporting by Legal Entity and Business Area is available via the standard FI Financial
You should also review the Period based vs Cost of Sales Based Accounting section.
Profit Reporting via Profitability Analysis or Profit Centre Accounting
Which module to use is a question that I often get asked by people unfamiliar with the operation of one or
Some rule of thumb guidelines to help you get a feel for which way you should be going are as follows:
Profit Centre Module Profitability Analysis
is aimed at Profit reporting by internal responsibility is aimed at external market segment reporting for
example by customer and customer groupings
lines or SBU's
(industries ?), geographical areas.
can slice & dice your information by a variety of
is limited to reporting by the profit centre hierarchies
dynamic hierarchies (a 'rubic's' cube is often used to
that you can setup.
symbolise this idea.
has 2 'styles'
Account based which will reconcile to the GL
can be reconciled easily back to the GL Costing Based which Allows approximations,
estimations or standards to be posted, which may
make reconciliation difficult to explainm to the user
Profit Centre Accounting (EC-PCA module) vs Cost Centre Accounting (CO-CCA)
This section addresses the question: "Do you really need to use Profit Centres ? OR How can I have
revenue in my Cost centres?"
If you are not using SD and MM (perhaps you do not have logistic operations but are in a government or
finance type industry) or are not using CO-PA for some reason (SD and CO-PA usually go together), you
will probably have been looking at using Profit Centre accounting. If you are only doing this for Profit
Reporting and are not using the Balance Sheet related functionality, then you should consider possible only
using Cost Centres. This will simplify data setup and maintenance and reduce the data volume.
How ? Well there are a couple of options:
1. Revenue as 'negative' expenses
Create your revenue accounts as primary cost elements (same as your expense accounts). Basically ignore
the revenue element option.
Create appropriate cost element groups to report appropriate subtotals etc.
Standard Cost centre reporting will then provide profit/loss reporting by cost centre and cost centre group.
2. Allow 'revenue' posting to Cost Centres:
Set the appropriate indicators in each cost centre master record for which you wish to see revenue postings.
Note however the system regards revenue element postings to Cost Centres as "statistical postings" and
therefore this revenue information will not be as visible in the standard reports as with option 1.
Statistical versus "Real" CO account assignments
Why does SAP talk about statistical assignments in CO - why are these different from real Cost Accounting
The reason is to facilitate reconciliation between FI and CO. The sum of all 'real' assignments in CO should
add up to the sum of all expense and revenue postings (where cost/revenue elements have been created for
the GL account of course) in FI. A normal expense invoice posting to expense accounts / cost elements
will be a 'real' posting. If the system is displaying an error message insisting on a 'cost accounting
assignment' and you think you have entered one, then possibly you have specified a statistical assignment.
A common error is in thinking that the business area will do - Business areas are FI elements not CO
Note that the word 'statistical' occurs in a number of different contexts which can be confusing. We are not
talking about key figures here.
So how do 'statistical' postings come about? Strictly speaking the whole document is not 'statistical' but
one or several of the cost accounting assignments on a line item may be statistical. SAP have defined a
number of 'rules' which determine what is statistical and what is not. Briefly these are as follows:
All Profit Centre assignments are EC-PCA is defined as statistical, therefore if posting to a revenue
statistical element, the system will insist on a real cost accounting assignment even
if profit centre is specified. A cost centre will not do, since revenue
elements are statistical in cost centres. The system will accept the
following as 'real' : CO-PA profitability segment, sales order, customer
project or a revenue bearing order.
An assignment to a statistical The system will continue to demand a cost accounting assignment until a
internal order will be 'statistical' - non-statistical assignment is made. For example a cost centre as well as
sounds obvious doesn't it! the statistical order.
Revenue elements assigned to cost 'Revenue' when defined to the system by setting up a revenue element is
centres will always be statistical always statistical in a cost centre. If however you have setup your
revenue accounts as primary cost elements then the assignment will be
Specifying multiple 'real' cost If you assign to more than one 'real' account assignment objects (usually
accounting assignments only allowed where one is a cost centre), then one of them will be made
statistical - the cost centre
The CO cost and revenue element module is where you find the reconciliation ledger. There are some
standard reports that will list by 'object type' (cost centre, order etc) the CO postings (real assignments)
against the FI postings for a cost element.
Any differences should be due to the use of CO reposts, or distributions, or late setup of cost elements once
postings have been made to a GL expense account
Period Based Accounting versus Cost of Sales Accounting
These terms come up in the SAP documentation fairly often and I frequently get asked what the difference
is. There are a number of ways of explaining the differences.
For the accountants it is usually enough to say the 'Period Based Accounting' is Accrual Accounting and
'Cost of Sales' is 'Cost of Goods Sold' Accounting. In CO-PA one has the option to choose or use either
Account based or Costing Based CO-PA. This choice impacts the level of detail and the frequency
(monthly, weekly or realtime) of reporting.
What does this mean effectively to us non-accountants and practically in the SAP system?
Period based Accounting
"Period based" means that during the month or period, all and only actual events / transactions are posted in
the appropriate period. At the end of the period estimated accruals and deferrals are made and posted to
that posting period to give a more accurate view of profit. ie. any expected revenues and expenditures that
should relate to the current period are accrued for and equally any prepaid expenses or revenues are
deferred to the next period. (Accruals and Deferrals are posted temporarily, usually to special accounts,
and reversed prior to the next period end.)
These accruals and deferrals are usually done at a fairly high level of summarisation (eg: at company or
business area). The FI Ledgers and financial statements etc are always period based.
Cost of Sales Accounting
Cost of Sales in SAP means that we attempt to record or rather report the "costs of sales" against the actual
sale at as low a level as possible and during the period. (In CO-PA this is down to a transaction level.)
This enables the company to get a reasonably accurate view of profitability on a real time basis.
This is done by using either standards or estimates for many of the components that make up the "cost of
goods sold". Any variations from the standards are usually posted through to the cost of sales system either
at month end or when they occur.
For example: A product cost estimate might be used to calculate and post a manufactured cost through to
CO-PA when every sale goes through. The actual production orders variances from the product cost
estimate can then be settled to a separate line in CO-PA. This has the benefits that
a reasonably accurate gross profit could be reported in real time at a transaction level and of course
therefore at all the characteristic levels in CO-PA.
the impact of any abnormal variances in production can quite clearly be seen and analysed separately from
the normal profitability of a product.
GL (Period Based) CO-PA (Cost of Sales)
During the Month At Month End During the Month
Production Estimatecan be
/ unit or Stock posted as
goods issued from stock to plus any stock
valuation / unit they occur
Manufactured Cost "cost of goods sold" at stock valuation
applied to the preferably to
number of units a separate
sold line for
Freight etc estimate
actual freight invoices etc in for
plus any accruals or charge applied to
Delivery Costs posted to the period comparison
or deferrals each sales invoice
whenever they come in or different
Gross Profit not useful for
plus any in to a
actual invoices Estimate used.
accruals separate line
Overhead Costs received & Actuals recorded in
or item for
posted CO, not available
yet in CO-PA
Net Profit definitely not Accurate useful for profitability May have an
useful yet Financial analysis during the additional report for
Statement for month m/end that shows
company or actuals / variances
FI and CO Did you know? s :
Following are some random items that were 'news' to some of my clients and occasionally even to me!
Sometimes due to the setup of the system you are working on, fields or possibilities have been hidden to
simplify screens or are enterable due to a combination of configuration. Thus you may not be aware that
there is additional or alternative functionality there. It pays to explore if you have the access and the time,
especially if it makes sense to you that such functionality should be available - often it is.
Module Item Description
FI Line item display Sort keys often place redundant data (ie data that is already on the
performance using sort keys line item) in the allocation field, and so appear unnecessary at times.
to populate the allocation field However the account line item display uses index tables to provide
on GL, AR and AP accounts fast display of line items where all the data required by the line
layout is in the index table. Index tables are BSIS, BSID, BSIK
(Open items for GL, AR, AP respectively), and BSAS, BSAD,
BSAK (cleared items). The line items in the index tables are sorted
by, amongst other fields, the allocation field. So judicious use of the
sort key to define the most popular sorting of the line items should
improve display speed. This should be taken into account when
creating custom line layouts.
FI A 'Duplicate record' check can See the "change message control" configuration under AR/AP
be switched on for customer master record creation in the IMG. Insert a new entry, click the
and vendor masters in AR & dropdown on the message number field and choose the appropriate
AP message. This will enable a duplicate check by address. The address
has to be exactly the same.
FI Descriptive text on master See "Define Text ID's..." under AR/AP master record creation in the
records IMG. Here you can define classifications or types of comments that
will be allowed for the various sections of the master records.
To edit / view the texts from the master record (both in general or
company code (accounting) section, follow menu "Extras/texts".
First line of each will be displayed. Double click to get into
wordprocessing mode to enter more text.
FI Standard line item texts or Define under IMG / FI Global settings / Document / Line Item /
formats for the line item text Define Text for line items (transaction OB56). The 4 digit
field can be defined abbreviation (abbr) can then be used when entering a journal line
item either by typing "=abbr" or clicking on the dropdown arrow in
the text field.
FI Long text for FI documents Useful for detailed explanations of reasons for documents or
can also be used adjustment postings etc. Define under IMG / FI Global settings /
Document / Document Header / Define Text ID's for documents.
See also for master records above.
FI Remove document entry Your document entry screens can be simplified for you personally,
fields for functionality that by eliminating fields used for functionality you do not use (special
you do not need GL, inter company, foreign currency etc).
FI 'Automatic' Worklists If your users would like to use worklists but maintenance when new
customers or vendors are added, is a pain or forgotten, you could
setup automatic worklists. These are updated automatically when a
new master record with the appropriate criteria is added.
Unfortunately this only works on the 'group key' or 'alternate payer'
fields, but could nonetheless be useful.
Follow menu: GL/Environment/Current Settings. Instead of clicking
on 'create' follow menu: edit/auto worklist. Specify the prefix,offset
& length of the part of the field you want to use to include a record
in the worklist. EG: XYZ, 0,3 will include all customers with XYZ
in the first 3 digits of the group field. Note that you will not see the
worklist listed until you have some master records with the
FI Treasury functionality you Even if you are not 'officially' implementing Treasury, you may want
might expect in the FI module to consider implementing some of the basic functions :
Cheque deposit (records cheques received, prints deposit slips and
makes appropriate postings to the Gl and AR accounts)
Cheques cashed (manual entry or automatic entry upload) - updates
the payment documents with cashed information and makes
appropriate GL postings for cash flow forecasting
Bank Statement Load - reconciles bank with incomings and
Cash Position and Forecast. This is actually really easy to
implement (surprise your client - or at least the treasurer - deliver
more than expected!). The design and configuration is best done
when you first setup your customer, vendor and GL accounts anyway
so that the appropriate settings are made - no rework.
CO Cost Centre Currencies can be When one sets the controlling area currency to the company code
individually specified currency (10) in CO maintenance, the currency field in the cost
centre master can be entered (normally defaults from company
code), and so you could run cost centres on their own currencies.
CO Standard Cost element groups Specify the cost element groups that the standard reports should use
for standard reports via transaction "ORKS - Determine Valid Cost Element Groups".