Global SAP Implementation Program
Global SAP Implementation Program
Conceptual Design Document
Finance & Controlling
Version 1.1
(12.12.2003)
Document Change History
Document Approval:
We have reviewed the contents of the Finance & Controlling
Global Conceptual Design Document and agree that it represents the
conceptual design of the financial processes that will be
implemented in Phase One of the Global SAP Implementation
Program.
This is with the understanding that the Program team has
maintained, in good faith, a high level of integrity across all
conceptual design documents (Supply Chain &
Finance/Controlling). As a general rule, the Program team will
proceed with the subsequent Program tasks and resolve design issues
based on the design that is described in more detail across all
conceptual design documents. The Finance & Controlling Program
team will be responsible for working with the Business
Representatives and Supply Chain Program team to resolve all open
items/issues identified and recorded in this Finance &
Controlling design document.
Signed:
Table of Contents
21.Introduction
21.1.AAAs Financial Processes in SAP
22.Finance Enterprise Organizational Structures in SAP
22.1.Company Code Structure
22.2.SAP Enterprise Consolidation (ECCS) Organization
Structure
22.3.Chart of Accounts Structure
22.4.Asset Accounting Structure
22.5.Controlling Organizational Structure
22.6.Cost Center Structure
23.Finance & Controlling Process Design Concepts
23.1.Financial Accounting Global Settings
23.1.1.FI Document Type/ Number Range
23.1.2.Currency
23.1.3.Exchange Rates
23.1.4.Fiscal Year Variant
23.1.5.Opening and Closing Posting Periods
23.2.General Ledger
23.2.1.GL Master Data
23.2.2.Operating Chart of Accounts
23.2.3.Country-Specific Chart of Accounts
23.2.4.Special Purpose Ledger for CCSZ
23.2.5.GL Master Data Maintenance
23.2.6.Multiple Reporting Views for AAA
23.3.Accounts Receivables
23.3.1.Customer Master Maintenance
23.3.2.Document Type
23.3.3.Trade Customer Master Data Maintenance
23.3.4.Non-Trade/ Sundry Customer Master Data Maintenance
23.3.5.Payment Term
23.3.6.Accounts Receivable Transaction Posting
23.3.7.Accounts Receivable Periodic Processing
23.4.Accounts Payable
23.4.1.Vendor Master Maintenance
23.4.2.Document Type
23.4.3.Trade Vendor Master Data Maintenance
23.4.4.Non-Trade/ Sundry Vendor Master Data Maintenance
23.4.5.Payment Terms
23.4.6.Accounts Payable Transaction Posting
23.4.7.Blocked Invoices
23.4.8.Accounts Payable Period Processing
23.5.Intercompany AP / AR
23.5.1.Authorisation
23.6.Asset Accounting
23.6.1.Chart of Depreciation:
23.6.2.Depreciation Area:
23.6.3.Asset Class:
23.6.4.Asset Number Range:
23.6.5.Asset Depreciation Methods:
23.6.6.Asset Master Maintenance:
23.6.7.Asset Transactions
23.7.Cost Center Accounting
23.7.1.Cost Center Structure
23.7.2.Statistical Key Figures
23.7.3.Overhead Allocation
23.7.4.Re-posting of cost
23.7.5.Period End-Closing
23.8.Internal Order
23.8.1.Order Master Data Creation
23.8.2.Order Actual Transaction Posting
23.8.3.Month End Process
23.9.Product Costing
23.9.1.Logistics Master Data
23.9.2.CO Master Data
23.9.3.Summary of Product Cost Approaches
23.9.4.Activity type prices planning
23.9.5.Percentage Overhead Rates Maintenance
23.9.6.Quantity Overhead Rates Maintenance
23.9.7.Cost Estimate Calculation
23.9.8.Standard Price Update from Standard Cost Estimate Mark
& Release
23.9.9.Standard Cost Estimates for Single Use Bbb (SUC)
23.9.10.Production Order Processing for Semi-finished Goods
23.9.11.Production Order Processing for Finished Goods
23.10.Profitability Analysis
23.10.1.Organisation Unit in COPA
23.10.2.COPA Method Deployment
23.10.3.COPA Structure - Characteristics
23.10.4.COPA Structure Value Fields
23.10.5.Actual Value Flow into COPA
23.11.Budgeting/Planning
23.11.1.SAP R/3 modules deployed for Annual Budgeting
23.11.2.Plan Version
23.11.3.Planning Layout
23.12.Cash Management
23.12.1.Common information and differences between Cash Position
and Liquidity Forecast
23.12.2.Memo Records
23.12.3.Cash Position
23.12.4.Liquidity Forecast
23.12.5.Integration with Special GL transactions (FI-GL)
23.12.6.Electronic Bank Reconciliation
23.12.7.Cash Concentration
23.13.Consolidation Procedures
23.13.1.Consolidation Units
23.13.2.Consolidation Groups
23.13.3.Consolidation Chart of Accounts and Financial Statement
Items
23.13.4.Design Highlights
23.13.5.Data Collection Process
23.13.6.Consolidation Process
24.Reporting
24.1.List of To-Be Reports
25.List of Customisations
26.List of Interfaces
27.Outstanding Items/ Decisions
28.Annexes
28.1.Annex 1: Cost Center Hierarchical Structure
28.2.Finance Requirements
1. Introduction
This document describes the major design concepts for the
Finance and Controlling Organizational Structure and all financial
transactions/configuration related to the General Ledger, Accounts
Payable, Accounts Receivable, Asset Accounting, Product Costing,
Cash Management, and Consolidating Financial Statements business
processes. The design concepts are also described for internal
managerial processes such as Cost Reporting & Allocations,
Budgeting and Planning, and Profitability Analysis Reporting. This
document does not describe all SAP configuration tables to support
the design. This level of detail will be done during the
Implementation stage of Global SAP Implementation Project.
1.1. AAAs Financial Processes in SAP All of AAAs financial
processes are in multiple Financial modules of SAP that are highly
integrated with each other and with the Logistics modules. As
depicted in Figure 1.1 the Financial modules being implemented
are:
Financial Accounting:
General Ledger,
Accounts Receivable
Accounts Payable
Asset Accounting
Controlling:
Overhead Cost Controlling
Product Costing
Profitability Analysis
Treasury Cash Management
Enterprise Consolidation
Note:Business Warehouse will have a separate Design Document.
Planned time for gathering all BW requirements is 31 Dec.,
2003.
Figure 1.1
2. Finance Enterprise Organizational Structures in SAP
All financial enterprises must identify organizational
structures in SAP that will be the foundation for how all financial
transactions will be reported. These organizational structures
reflect the legal and managerial organizations that support
external and internal financial reporting. The organizational
structures described in this section are global and will affect all
Reporting Units in AAA. They are the:1) Company Code Structure2)
Consolidated Company Structure3) Chart of Accounts Structure4)
Asset Accounting Structure5) Controlling Structure6) Cost Center
Structure
2.1. Company Code Structure
Company Codes generally represent legal entities within the
Corporation that provide external financial statements such as
Balance Sheet and Operating Income Statement reports. Each Company
Code must have a complete set of accounting records for reporting
purposes.
AAA has identified sixteen Company Codes, ten of which are
active and six dormant.
Note: Not every AAA company code represents a legal entity. AAA
Latin America and AAA Keystone Graphics are divisions that belong
to the legal entity AAA Keystone Sales Corp. AAA Henggang
represents the factory that belongs to AAA Shenzhen.
A change request has been submitted to make Latin America an
active company code. This change will be addressed in separate
documentation and is outside the scope of this design document.
The proposed German acquisition will be handled as part of a
change request.See Figure 2.1.
Figure 2.1
2.2. Enterprise Consolidation (ECCS) Organization Structure
The Enterprise Consolidation structure facilitates the
procedures that create Consolidated Financial Statement reports for
all AAA Reporting Units. The Consolidation structure is arranged to
allow consolidated financial reports for Global AAA Bbb Corp., all
European Reporting Units, and subsidiary group reports for CC UK,
CC Germany and CC Hong Kong. See Figure 2.2.
AAA Australia will be shown as wholly owned by CCHK and its name
will be changed to reflect the correct legal name, AAA Bbb Aust.
(Regional) Pty. Ltd.Consideration is being given to configure a
dummy Consolidation Unit for the Legacy Elim company. This
Consolidation Unit will house the historical balance sheet Elim
data and avoid the need to manually re-enter these data every
month. The dummy Consolidation Unit will be dormant once AAA goes
live on SAP. Future elimination postings will occur in the active
Consolidation Units using the consolidation procedures.
Investigations are in progress to determine the best way to
generate consolidated financial reports for all of Europe.
Figure 2.2AAA Keystone Graphics and AAA Latin America will be
moved to under AAA Keystone Sales. A US consolidation subgroup will
be formed over the three US consolidation units.
2.3. Chart of Accounts Structure
To meet AAAs accounting requirements for statutory (US GAAP) and
local GAAP requirements, three different levels of Chart of
Accounts will be configured in SAP. All Reporting Units will post
all financial transactions to a Global Operating Chart of Accounts
(COA). This COA will be created according to the US GAAP
specifications. Each account in the Operating COA will be mapped to
one or many accounts in the Group Chart of Accounts to capture
financial postings for AAAs Consolidated Financial Statements. The
accounts in the Operating COA will also be mapped in a one to one
relationship with accounts in two Country-Specific Chart of
Accounts for France and China. France and China have specific
statutory requirements that mandate that Financial Statements must
include specific accounts. Postings to the Operating COA will
automatically populate corresponding accounts in the Group COA and
Country-Specific COAs.
Chinas statutory law further stipulates that Financial
Statements must fall within the calendar year of January to
December, in contrast to AAAs fiscal year of July to June. Creating
calendar year Financial Statement reports will be supported by
special configuration in the Special Purpose Ledger.
Although the French and German governments allow fiscal year
reporting from July to June, they have a stipulation that the end
of the fiscal year must be on June 30th, in contrast to AAAs fiscal
year end on the last Saturday of June or first Saturday in July. In
SAP, CC France and CC Germany will continue the current process of
updating transactions between AAAs year-end and June 30th, to the
earlier of the fiscal year end or June 30th. To avoid entries in
this interim period, validation rules will be set up to ensure that
the postings fall into the right date range. If the fiscal year
ends before June 30th, then every posting in June will not post
beyond AAAs fiscal year end. If the fiscal year ends in early July,
then the postings in July will be backdated to June 30th.
A certain range of accounts in the Global Operating Chart of
Accounts will be reserved to capture postings for statutory reports
to meet local and US GAAP requirements, and global transfer tax
pricing requirements. For more details see Section 3.2.5,
sub-section Account Group.
Figure 2.3 below illustrates the relationships among the three
types of Chart of Accounts. More details on the Account structures
are in Section 3.1 on General Ledger.
AAA Chart of Account Relationships:
Figure 2.3
Note: Peter Bauser is an additional company code that is to be
included for the above Chart of Accounts
2.4. Asset Accounting Structure
Asset Accounting is used for managing and supervising all
existing fixed assets. Like A/R and A/P, it is also a subsidiary
ledger to the General Ledger, and provides detailed fixed asset
transaction information. Asset Accounting integrates with the
Operating Chart of Accounts and other SAP modules such as
Production Planning, Materials Management, Plant Maintenance and
Investment Management. Each country will have a defined Chart of
Depreciation with three Depreciation Areas a) Book Depreciation, b)
Tax Depreciation and c) Group Depreciation.
(Group depreciation is required by the system to store asset
values in USD, the group currency, for company codes with local
currencies that are not USD. In these companies, parallel ledger
currency has been activated so that transactions are recorded in
their local currency and in USD. Particularly in AAA, these
companies will be in HK, China and Europe.)
All fixed asset financial transactions will post to the Book
Depreciation Area. Tax depreciation methods have been defined in
the Tax Depreciation Area for all Reporting Units with specific tax
depreciation requirements. The Group Depreciation Area is system
defined and necessary for completing all fixed asset transactions
in SAP. Each Reporting Unit has specific Asset Classes associated
with them. See Figure 2.4 for the Asset Accounting Structure.
Figure 2.4 Asset Accounting Structure
2.5. Controlling Organizational Structure
The Controlling Area represents the cost accounting environment
where costs and revenues are managed, and internal managerial
reports are generated. AAA will have one Controlling area, AAA
Group, CCG. In addition to the Controlling Area an Operating
Concern, AAA Group, CCG has also been defined. The Operating
Concern is the main organizational unit for Profitability Analysis.
It contains the tools for analyzing contribution margins of
business units and market segments.
In the Controlling Structure hierarchy, the Controlling Area is
under the Operating Concern and all Company Codes are linked to the
Controlling Area. The Operating Concern and Controlling Area
currencies have been identified as USD. See Figure 2.5.
Figure 2.32.6. Cost Center Structure
The standard cost center hierarchy represents the organizational
structure of AAAs departments (active managerial units). Over 200
departments have been identified. Their organizational
relationships are shown in five hierarchical levels:
Level 1: AAA Group the highest Cost Center Group that represents
Global AAA Bbb Corp.
Level 2: Cost Center Groups that represent AAAs legal entities,
for example, Keystone Sales (CC US), CC UK, CCGermany and CC
HK.
Level 3: Cost Center Groups that represent AAAs major department
categories, for example, Sales, Administration and Production.
Level 4: Cost Centers and Cost Center Groups. The Cost Centers
represent departments within major department categories (Level 3
Cost Center Groups). The Cost Center Groups are other department
categories that are further sub-divided into more specific
departments. Examples of Level 4 Cost Centers are Marketing,
Finance and Production Line under Sales, Administrative and
Production Cost Center Groups respectively. Examples of Level 4
Cost Center Groups are Design Engineering and Quality
Engineering.
Level 5: Cost Centers (departments) for Level 4 Cost Center
Groups. An example is Industrial Engineering department under
Design Engineering Cost Center Group.
In addition to the standard cost center hierarchy described
above, alternate hierarchies can be defined specifically for
reporting or allocation purposes. The European head office will be
set up as an alternate hierarchy where European head office cost
centers from each European company code will be grouped together as
an alternate hierarchy cost center group.
Below is a summary of the Cost Center Groups on the Standard
Cost Center Hierarchy. The detailed cost center information is
documented in Appendix 8.1 The naming convention for Cost Center
Groups and Cost Centers will be described in more detail in Section
3.7 on Cost Center Accounting.
AAA BBB COST CENTER GROUPS:
Level 1
Description
Level 2
Description
Level 3
Description
Level 4
Description
CCG
AAA Bbb Grp
1000
CCC
1000-3
Supply Chain
1000-5
Sales
1000-6
Engineering
1000-611
US Design
1000-7
Administration
1000-791
Executives
1000-795
Information Technology
1000-796
Finance
3100
CCUK
3100-3
Supply Chain
3100-5
Sales
3100-7
Administration
3300
CCGMBH
3300-3
Supply Chain
3300-5
Sales
3300-7
Administration
3400
CCFR
3400-3
Supply Chain
3400-5
Sales
3400-7
Administration
4100
CCUS
4100-3
Supply Chain
4100-333
Warehouse/Storage
4100-5
Sales
4100-7
Administration
4200
CCCA
4200-3
Supply Chain
4200-5
Sales
4200-7
Administration
5100
CCHK
5100-3
Supply Chain
5100-4
Production
5100-449
Supporting Service
5100-44X
Production Line
5100-5
Sales
5100-6
Engineering
5100-610
Design Engineering
5100-612
US Production Design
5100-620
Project Management
5100-630
Production Engineering
5100-640
Quality Engineering
5100-7
Administration
5100-791
Executives
5100-796
Finance
5200
CCWK
5200-3
Supply Chain
5200-4
Production
5200-449
Supporting Service
5200-44X
Production Line
5200-6
Engineering
5200-610
Design Engineering
5200-620
Project Management
5200-630
Production Engineering
5200-640
Quality Engineering
5200-7
Administration
5300
CCSZ
5300-3
Supply Chain
5300-4
Production
5300-449
Supporting Service
5300-44X
Production Line
5300-5
Sales
5300-6
Engineering
5300-610
Design Engineering
5300-630
Production Engineering
5300-640
Quality Engineering
5300-7
Administration
3. Finance & Controlling Process Design Concepts
The following sections will describe the design concepts for
each business financial process identified for AAA Bbb Corp.s
Global SAP Implementation for Phase 1. Each section will show the
business process flow, its design concept and an overview of the
master data and configuration variables that meet the design. The
global system settings will also be highlighted.
The business financial processes and system settings of the
Finance and Controlling modules are described in the following
sections of this document: 3.1
Financial Global Settings
3.2 General Ledger
3.3 Accounts Receivable
3.4 Accounts Payable
3.5 Intercompany Financial Transactions
3.6 Asset Accounting
3.7 Cost Center Accounting
3.8 Internal Order
3.9 Product Costing
3.10 Profitability Analysis3.11 Budgeting / Planning
3.12 Cash Management
3.13 Consolidation Procedures
3.1. Financial Accounting Global Settings
This section describes the high level settings in Financial
Accounting that affects every FICO modules.
3.1.1. FI Document Type/ Number Range
SAP moduleFI Document TypesNo. Range assignmentFI Document Type
DescriptionAccount TypeReverse Document Type
AMAA01Asset postingADKMSAA
AMAF03Dep. postingsASAF
APKA17Other Vendor documentAKMSKA
APKG17Vendor credit memoAKMSKG
APKR19Vendor invoiceAKMSKR
APKZ15Vendor paymentKSKZ
APZP20AutoPayment PostingADKMSZP
APZV20Auto Payment clearingADKMSZV
ARDA16Other Customer documentDSDA
ARDG03Customer credit memoDSDG
ARDR18Customer InvoiceADMSDR
ARDZ14Customer paymentDSDZ
GLSA01G/L account documentADKMSSA
MMPR48Price changeMS
MMRE51Invoice receiptAKMSRE
MMRI52Invoice receipt-Interco.AKMSRI
MMWA49Goods issueAMSWA
MMWE50Goods receiptAMSWE
MMWI49Inventory documentAMSWI
MMWL49Goods issue/deliveryAMSWL
SDRC82SD Credit MemoDSRC
SDRD83SD Debit MemoDSRD
SDRR85SD Credit for ReturnDSRR
SDRS86SD Rebate Credit MemoDSRS
SDRV88SD InvoiceADSRV
SDRW81SD Invoice-Interco.DSRW
CMZR20Bank reconciliationDKSZR
The above table acts as a baseline for further discussion.
(New doc types requested are: a) FI customer debit memo and b)
lower of cost or market document)
Explanation Notes for Items in Table 3.1.1:
SAP Modules stated on table above:
AM - Asset Management (Financial Accounting)
AP - Accounts Payable (Financial Accounting)
AR - Accounts Receivable (Financial Accounting)
GL General Ledger (Financial Accounting)
MM- Material Management (Logistics)
SD Sales and Distribution (Logistics)
CM Cash Management (Treasury)
MM related Document Types:
* Note that Purchase Order does not have accounting impact and
hence no FI document type needs to be mapped to PO document
types.
PR Price Change
Postings on Inventory Revaluation from MM (transaction MR21).
Price Change refers to the change in Standard Price of the
material, not the price difference between PO and Invoice that is
booked at the time of invoicing. Note this type of transaction does
not have Reversal FI Document Type. If the price changed need to be
adjusted, a new transaction is posted, rather than reverse the
original posting.
RE Invoice Receipt
Postings on Invoice Receipt transactions from MM (transactions
MIRO/ MRRL)
RI Invoice Receipt-Interco.
Postings on Invoice Receipt transactions for Invoice
Verification triggered from Intercompany Sales. The Invoice
Verification step for intercompany sales are triggered by SAP in
form of a batch generated automatically. For details, please refer
to MM Conceptual Design Document.
WA Goods Issue
Postings on Goods Issues or MM Transfer Postings. For detail
definitions on Goods Issues/ Transfer Postings, please refer to MM
Conceptual Design Document.
WE Goods Receipts
Postings on Goods Receipts with reference to Purchase Order or
Production Orders. For detail definitions, please refer to MM
Conceptual Design Document.
WI Inventory Document
Postings on Physical Inventory Differences. For detail
definitions, please refer to MM Conceptual Design Document.
WL Goods Issue/ Delivery
Postings on Goods Issues with reference to SD Delivery. For
detail definitions, please refer to MM Conceptual Design
Document.
SD related Document Types:* Different types of Sample Sales are
differentiated by Sales Order types; hence it is irrelevant to FI
document type mapping.
RV SD Invoice
Postings of Sales Invoice from SD transactions. A Sales Order
and delivery need to be completed before Sales Invoice is created
in SD.
RW SD Invoice-Interco.
Postings of Intercompany Invoice from SD transactions. A Stock
Transport Order (STO) and delivery need to be completed before
Sales Invoice is created in SD.
RC SD Credit Memo
Postings of Credit Memo from SD transactions. A Credit Memo
Request (a special Sales Order Type) need to be raised before
Credit Memo is created in SD.
RD SD Debit Memo
Postings of Debit Memo from SD transactions. A Debit Memo
Request (a special Sales Order Type) need to be raised before Debit
Memo is created in SD.
RR SD Credit for Return
Postings of Credit Memo from SD transactions as arose from
Return. A Return Order (a special Sales Order Type) and return
delivery need to be completed before Credit Memo for Return is
created in SD.
RS SD Rebate Credit Memo
Postings of Rebate Credit Memo from SD transactions. A Credit
Memo Request (a special Sales Order Type) need to be raised before
Rebate Credit Memo is created in SD.
Number range assignment:
It links to the number range table below. FI document numbers
are Fiscal Year Dependent. Meaning in interpreting a FI document,
system always require users to quote the Fiscal Year involved, e.g.
FY2004, Doc no. 2000000
Account Type:
This is the SAP code in defining which type of account can be
posted to particular type of document. This is preset by SAP system
in the FI Document Type definitions. Here are the SAP Account
Types:
A-Asset
D-Customer
K-Vendor
M-Material
S-General Ledger
Reverse Document Type:
Upon reversal of a particular FI document, the system will use
this Document Type for the reversal transaction. This way, certain
reversal documents can be separately analysed, if needed. In
standard SAP setting, all the reversal document types are the same
as original document type.
Data Conversion Document Types:
They depend on the detail flow and procedures of data conversion
in AAA, thus are unique to the company and not suggested at the
moment.
Document Number Ranges:
The number range in the table below is defaulted from SAP and is
suggested here as a reference. The exact settings depend on
individual company policies.
Number Range
Document no. fromDocument no. to
01 0000100001 0000199999
03 0000300001 0000399999
14 1400000000 1499999999
15 1500000000 1599999999
16 1600000000 1699999999
171700000000 1799999999
18 1800000000 1899999999
19 1900000000 1999999999
20 2000000000 2099999999
47 4700000000 4799999999
48 4800000000 4899999999
49 4900000000 4999999999
50 5000000000 5099999999
51 5100000000 5199999999
52 5200000000 5299999999
81 8100000000 8199999999
82 8200000000 8299999999
83 8300000000 8399999999
85 8500000000 8509999999
8686000000008699999999
8888000000008899999999
3.1.2. Currency
Currencies in SAP standard system are set as the ISO
(International Organization for Standardization) standards, for
example, USD for US dollar.
In Financial Accounting, the national currency of the company
code is considered the local currency (or company code currency).
From a company code view, all other currencies are then foreign
currencies.
Parallel currency is maintained for AAA in addition to the local
currency. Group currency, USD, will be set as AAAs Parallel
currency.
A group currency is used in the consolidated financial
statements. Before the consolidation process can be completed, all
values in the individual financial statements must be translated
from the local or transaction currency into group currency.
When managing the ledgers in parallel currencies, the following
effects result:
During posting, the amounts are also saved in the parallel
currencies. The amounts are translated automatically using Average
Rate (M Rate for majority cases, EURX Rate for EU currencies
translation to USD). See Section 3.1.3 for Exchange Rate Types used
by AAA.
G/L account transaction figures are also updated in the parallel
currencies, USD, and stored in the FI document as a separate
field.
Exchange rate differences also arise in the parallel
currencies.
3.1.3. Exchange Rates
Exchange rates in the system are for the following purposes:
Posting and Clearing
To translate amounts posted or cleared in foreign currency, or
to check a manually entered exchange rate during posting or
clearing.
Exchange Rate Differences
To determine gains or losses from exchange rate differences
(between transaction rate, i.e. M or EURX, and period-end closing
rate, C)
Foreign Currency Valuation
To valuate GL/ AR/ AP open items in foreign currency and foreign
currency balance sheet accounts as part of the closing
operations.
Exchange Rate Type
In order for the system to translate amounts into various
currencies, exchange rates should be defined. For each currency
pair (e.g. HKD: USD), different exchange rates can be defined and
differentiated using exchange rate types.
The following exchange rate types can be defined in SAP:
Buying rate
Bank selling rate
Average rate
For posting and clearing, the system uses the exchange rate type
M (average rate). This exchange rate type must be entered in the
system and you must also enter the exchange rates for this type in
the currency table. For standard SAP, the update on exchange rate
is a manual process.
Historical exchange rate
Key date exchange rate
(More exchange rate types may be added in the detailed design
phase.)
Not every pair of exchange rates needs to be entered into the
system. There are various tools you can use to automatically
determine other exchange rates from existing ones.
The following tools are available:
Inversion
Inversion is the process of calculating the opposite rate from a
defined exchange rate. (This is the same as direct vs. indirect
rates.)
Reference Exchange Rate
Currency key used to carry out all foreign currency translations
for a specific exchange rate type. Reference currency is assigned
to an exchange rate type. For every other currency, exchange rate
is entered in the reference currency. All other translations are
carried out using the reference currency.
Usage for AAA:
It is required by SAP system that for all EUR, currency
translation should be set as a Reference Currency. The algorithm
has been adjusted to meet the European Monetary Union statutory
guidelines. The indicator must be set if the statutory conversion
rules agreed by the participating countries in the EMU are to be
used. This only applies to Average Rate conversion.
Example:
EUR is set as the reference currency. To translate from GBP to
EUR for day-to-day FI posting, the system uses the EURX exchange
rate type specifications. All other currency translation for
Day-to-Day FI postings uses M exchange rate type instead.
The following is list of Exchange Rate Type for AAA:
Exchange Rate TypeBusiness UsageSAP configuration settings
CodeDescriptionSummaryDetailsReference Currency*Indicator:
Calculation allowed with inverted exchange rate?**European Monetary
Union statutory guidelines met?
EURXEMU - Conversion method not participantAct as Average rate
for all translation with EUR- Used for all translations with EUR-
Direct Quote should be usedEURNY
MAverageFor Day-to Day posting and clearing, the system uses
this exchange rate type - This exchange rate type must be entered
in the system and you must also enter the exchange rates for this
typeN/AYN
CClosing RatePeriod end foreign currency valuation- This rate
applies to all currencies (including EUR)N/AYN
1001Historical Exchange RateConsolidation - Foreign Curr
Translation- Can be applied per specific set of accounts in Group
COAN/AYN
1002Current RateConsolidation - Foreign Curr Translation- Can be
applied per specific set of accounts in Group COAN/AYN
Note:
* Indicator that in the case of a missing exchange rate entry in
the system for the required translation from one currency into
another, the inverted exchange rate relationship may also be
used.
** The algorithm has been adjusted to meet the European Monetary
Union statutory guidelines. The indicator must be set if the
statutory conversion rules agreed by the participating countries in
the EMU are to be used.
Exchange rate will be maintained centrally by AAA Corporate and
all AAA companies will perform business transactions using the rate
updated by Corporate.
All day-to-day transactions, including FI generated Intercompany
Transactions, M rate will be used. For EU related exchange rates,
EURX will be used instead. Since FI generated Intercompany postings
are within the same document including entries of both companies,
the exchange rate used will be the same for both entities in this
case.
For period-end, Foreign currency valuations, Exchange Rates
stated in Exchange Rate Type C Closing Rate will be used (for all
currencies in this case, including EU currencies) for revaluating
open items held in foreign currencies (i.e. different from Company
Code currency). For detail mechanism on Foreign Currency Valuation,
please refer to 3.3.7 Accounts Receivable Period end Processing:
Month End Open Item Revaluation3.1.4. Fiscal Year Variant
A fiscal year is divided into posting periods. Each posting
period is defined by a start and a finish date. In addition to the
posting periods, you can also define special periods for year-end
closing.
In General Ledger Accounting, a fiscal year can have a maximum
of twelve posting periods and four special periods.
In addition to the posting periods, you can also define special
periods for year-end closing.
In General Ledger Accounting, a fiscal year can have a maximum
of twelve posting periods and four special periods.
For all AAA Company Codes, one central Fiscal Year Variant will
be set up with 4-4-5 fiscal period, with 4 special periods for
closing activities. The Fiscal Year Variant is flexible and allows
different period end dates to be defined for subsequent years. For
example, a 4-5-5 or 4-4-6 fiscal period may be defined for future
years.
This centralised Fiscal Year Variant will be assigned in all
Company Code. This Fiscal Year setting will be controlled
centrally.
3.1.5. Opening and Closing Posting Periods
Open and close posting periods for FI modules are controlled in
SAP by Posting Period Variant.
Usually, only the current posting period is open for posting,
all other posting periods are closed. At the end of this posting
period, the period is closed, and the next posting period is
opened. Special periods can be open for closing postings during the
period-end closing.
Each reporting unit in AAA will be created a separate Posting
Period Variant. This enables centralized or decentralised control
on the Period-end closing timing. Each reporting unit can take care
of their own Posting Period Variant and be responsible for their
closing timeliness, or a centralized group can perform the same
activities. Once a period is closed in the branch, the Posting
Period Variant for that reporting unit can be closed and prohibit
further changes in prior periods.
Posting Period Variant can also be differentiated by Account
Type. Meaning opening and closing of posting periods can be
controlled by account type (A-Asset, D-Customers, K-Vendors,
M-Material, S-General Ledger). For example, for a specific posting
period, postings can be permitted to customer accounts, but not to
vendor accounts. Further range of account can be limited in open
and close period as well per account type.
3.2. General Ledger
Figure 3.1 General Overview of a Financial Posting in the
General Ledger and Relevant Cost Objects
The central task of G/L accounting is to provide a comprehensive
picture for external accounting. In SAP G/L accounting, all
business transactions are fully integrated with all the other
operational areas of a company. It ensures that the accounting data
is always complete and accurate.
Essentially, the general ledger serves as a complete record of
all business transactions. It is the centralized, up-to-date
reference for accounts. Actual individual transactions can be
checked at any time in real time processing by displaying the
original documents, line items, and transaction figures at various
levels such as:
Account information
Journals
Total/transaction figures
Balance sheet / profit and loss evaluations
The SAP General Ledger module provides the following function
for all AAA companies across the Group:
COA/ General ledger master
Automatic intercompany postings
Real-time automatic postings from subledgers (Accounts
Receivable, Accounts Payable, Asset Management) to the General
Ledger
Accruals/ Recurring entries/ Regroup account balances
Automated foreign currency valuations
Online real-time report drilldown to source documents in all
ledger/ subledgers
Multi-currency support
Each Company Code will only be able to view and post the GL that
has been assigned to it.
3.2.1. GL Master Data
In SAP, the G/L account master records control the posting of
accounting transactions to G/L accounts and the processing of the
posting data. Before you can make postings to a G/L account, you
have to create a master record in the system for the G/L
account
GL Master Data Structure
G/L account master records are divided into two areas so that
company codes with the same chart of accounts can use the same G/L
accounts.
Chart of accounts area (General Data)
The chart of accounts area contains the data that is valid for
all company codes, such as the account number
Company code specific area
The company code specific area contains data that may vary from
one company code to another, such as the currency in which the
account may be posted.
Chart of Accounts in SAP - Summary
In SAP FI modules, 3 different types of Chart of Accounts (COA)
exists, they are interlinked and serve different purposes. This
section describes the detail usage of each of them in AAA.
Illustration on SAP COA Relationships:
Fig 3.2.1
Note: Peter Bauser is an additional company codes that will be
included in the above Chart of AccountsDetailed Business Usages and
characteristics on different types of SAP COA:
Operating COA
Group COACountry Specific COA
Business Usage
AAA UsageDay to Day OperationConsolidationSupport government
specific format Financial Statement generation
Type of Financial Statements (FS) generatedAll individual AAA
Company FSConsolidated FS (either sub-group level, or Group
level)Government specific format FS
Example of AAA units deployedCCUS, CCUK, CCHK, etc.Sub-group HK,
UK, Germany, etc.
Group AAA CorporateCCSZ, CCFR
SAP specific information
SAP moduleFI-GL
(Financial Accounting General Ledger)EC-CS
(Enterprise Controlling Consolidation)FI-GL
(Financial Accounting General Ledger)
Master DataExist as a complete GL master data (COA segment and
Company Code specific segment)Financial Statement Item (Group
Account account on the Group COA)Only exist as COA segment of GL
Master (account no. and description)
Linkage to FI-GLExist as a GL master data (COA segment and
Company Code specific segment)Linked to FI-GL by Group Account
field in COA segment of GL MasterLinked to FI-GL by Alternate
Account field in Company Code specific segment of GL Master
Document Creation FrequencyFI documents are posted real-time
upon day-to-day business transactions in SAP (FI/MM/SD/PP)ECCS
(consolidation) document are posted upon all postings from FI-GL,
online real-timeNo document will be posted. Reports will draw
values posted on FI-GL
3.2.2. Operating Chart of Accounts
The Finance Team has reengineered the separate As-Is COA from
all AAA companies into one single To-be global Operating Chart of
Accounts (COA). This Global Operating COA will include all the
necessary GL accounts for every AAA company.
In SAP, the Global Operating COA for AAA will be as follows:
Chart of Accounts [4 characters] Description
[50 characters]Length of G/L account numberRelated Group Chart
of Accounts
CONOAAA Global Operating Chart of Accounts8CONC
The Global Operating COA will be presented in SAP as COA segment
of GL Master. Group COA for AAA: CONC is set up for consolidation
purpose. For details, please refer to Section 3.13.3 on EC-CS
Enterprise Consolidation in this design document.
Note:
During the conceptual design stage, the structure of the Global
Operating COA has been confirmed. Please refer to Section 3.2.5 on
Account Group Structure. Account details will be furnished in a
separate document.
Individual GL accounts are to be fine-tuned in Detailed Design
Phase, major tasks relating to additions/ adjustments on the
Operating COA will be as follows:
Sales and Distribution (SAP-SD) account assignments
Material Management (SAP-MM) account assignments
Detailed mapping of As-Is COA (for each AAA subsidiary) to the
To-be single Global Operating COA. One or many As-is accounts can
be mapped to one SAP account. This also creates a foundation for
the conversion process on GL transactions.
Define adjustment accounts for different Multiple Views of the
Financial Books. Please refer to Section 3.2.6 on Multiple
Accounting Books for AAA.
3.2.3. Country-Specific Chart of Accounts
This addresses the needs of AAA France and AAA Shenzhen
governmental financial reporting needs.
Since France and China government need the generation of
financial statements (Balance Sheets, and Profit & Loss
Statements) in predefined numbers and formats, which are different
from that of AAA Global COA, Country-Specific COA are set up for
these 2 countries.
In SAP, Country-Specific COA for AAA will be as follows:
Chart of Accounts [4 characters] Description
[50 characters]Max Length of G/L account numberRelated Group
Chart of Accounts
CCFRFrance Country Chart of Accounts10CONC
CCSZChina Country Chart of Accounts10CONC
The Country Specific COA will be created in SAP as COA segment
of GL Master. No real postings are stored into these GL accounts.
Rather, in the Company Code section of CCFR and CCSZs Operating GL
account Master, the Country-Specific GL is mapped in the field
Alternate Account, so that the data from the G/L account can flow
to the country-specific COA during FI report execution (no separate
Accounting Document will be created for Country-Specific GL.
Information on Country-Specific GL will only be presented to users
via reporting in FI-GL). Please refer to table in Section 3.2.1:
Detailed Business Usages and characteristics on different types of
SAP COA.For CCFR, the reporting on France government financial
statements will be generated in SAP by setting of a unique
Financial Statement Version, which groups Country-specific GL into
desired format. This financial statement format will satisfy French
statutory reporting requirements.
3.2.4. Special Purpose Ledger for CCSZ
For CCSZ, in addition to Country-Specific GL, a Special Purpose
Ledger (FI-SL, separate from FI-GL) will be created to produce
financial statements with a calendar year end (required by Chinese
government as compared to AAAs fiscal year end (June and 4-4-5
based).AAA Day-to-day operations that are posted in FI-GL (to
Operating GL account) will be posted automatically to the Special
Purpose Ledger for CCSZ. Postings in FI-GL will follow AAAs fiscal
year setting, while that in FI-SL follows China governments fiscal
year setting. For example, the posting date is 20-Jun-03, document
for CCSZ in FI-GL will be posted as period 12, while in FI-SL will
be period 6. The Country-specific GL no. will also be posted to
FI-SL through customization. This ensures the FI-SL contains the
correct accounting posting periods with Country-Specific GL no. for
rendering of China specific Balance Sheets and P&L
accounts.
Here is the summarized treatment on CCSZs financial books:
CCSZs day-to day postingsChina government specific postings
COAOperating COACountry-Specific COA
SAP ModuleGeneral Ledger (FI-GL)Special Purpose Ledger
(FI-SL)
Fiscal YearJune, 4-4-5 basedCalendar year
Users inputYesNo (auto-post)
Financial Statement generationSet a Financial Statement Version
to group Operating GL accountsSet a Financial Statement Version to
group Country-specific GL accounts
3.2.5. GL Master Data Maintenance
One global Operating Chart of Accounts will be set up for all
AAA companies. Since it relates to AAAs day to day operations, the
maintenance of the GL Master Data is a critical process for
AAA.
In accordance with the design of SAP GL Master Data, all AAA GL
accounts will be created with the COA segment of the GL Master.
This forms the list of Operating Chart of accounts. Company Code
specific segment GL Master will only be created to necessary AAA
companies, whenever it is appropriate. Only GL Master Data with COA
and Company Code segments can be posted in the General Ledger in
SAP.
For the detailed process flow on the GL Master Data maintenance,
please refer to Figure 3.1.1 below.
CCC on the above chart refers to AAA Bbb Corporate
As stated in the FICO Prototype, for the initial request for GL
account creation/ changes from subsidiaries, a standardised form
need to be applied with reasons on the requests. There will be an
exercise for the users in designing this new standardised form.
This request form is to be processed out of SAP and proposed to
utilise the current AAA Lotus Notes approval features.
Figure 3.1.1 General Ledger Master Data Maintenance
Key control points in GL Master Data:
SAP GL accountUsageRemarks
COA Segment Company Code Specific Segment
General DescriptionShort Text/ Long Text (in different language
if needed)
P&L or B/S account?Radio buttonFor P&L accounts, SAP
will automatically create respective Primary Cost Element upon
saving of new GL Master
Account groupLimit GL account no. rangeExample: Current Assets/
Fixed Assets, etc.
Group Account NumberIntegration to Consolidation moduleRequired
field for all GL Master data
Account CurrencyControls the posting currencies in the accountIf
the account currency is set as the Company Code currency, then all
currencies can be posted to this account . If another currency is
specified, then only that currency can be posted, e.g. if a US bank
accounts currency is GBP, only GBP currency can be posted to this
bank account. (Exchange rate differences are an exception when
valuating G/L balances)
Alternate Account NumberLinkage to Country-Specific COAOnly
populate for CCSZ and CCFR for AAA
Authorization GroupAllows access/control to Company Specific
Segment Each company is set up with a different key for
authorization control
Account Group
With the account group, you group similar accounts together and
control the creating and changing of master records. The account
group determines:
1. The number interval from which the account number is selected
when a G/L account is created.
2. The screen layout for creating G/L accounts in the company
code-specific area
For point 1 above, Account Groups will be defined according to
level 1 Account Group of the AAA Global Operating Chart of Accounts
document. The structure of the Account Groups has been confirmed
during the FICO design confirmation workshop and is listed in the
table below.
Account Group [4 Characters]Description [30 Characters]GL
Account range from/ to
1000Current Assets1000 0000-1999 9999
2000Long Term Assets2000 0000-2999 9999
3000Current Liabilities3000 0000-3999 9999
4000Long Term Liabilities4000 0000-4999 9999
5000Shareholders' Equity5000 0000-5999 9999
6000Revenues6000 0000-6499 9999
6100Sales Returns and Allowances6100 0000-6199 9999
6200Cost of Sales6200 0000-6299 9999
6600Selling Expenses (Var)6600 0000-6699 9999
6700Selling Expenses (Fix)6700 0000-6799 9999
7000General & Administrative Expenses7000 0000-7099 9999
7100Interest & Finance Charges7100 0000-7199 9999
7200Interest Income7200 0000-7299 9999
7300Intercompany Income/ Expense7300 0000-7399 9999
7400Other Income / Expense7400 0000-7499 9999
7500Income Tax Expense7500 0000-7599 9999
8000GAAP Reporting/Statutory Adjustments8000 0000-8099 9999
8100Adjustments for Global Transfer Prices for Tax
(by corporate)8100 0000-8100 9999
9000CO Accounts(secondary cost elements only)9000 0000-9899
9999
9900Data Conversion Accounts9900 0000-9999 9999
AAA Global Operating COA Account Groups are ranges from 1000 to
7999
Account Group 8000 is reserved for adjustments from US GAAP to
Local GAAP
Account Group 8100 is reserved for Adjustments for Global
Transfer Prices for Tax (by corporate)
Account Group 9000 is reserved for creation of Secondary Cost
Element in SAP Controlling (CO) modules. This range will not be
created as GL Master in FI. Due to the integration nature of the
FI/CO, Secondary Cost Elements share the same number range as FI,
therefore a specific range is reserved. These are for cost
allocations that are based on secondary cost elements like
statistical figures, for example, footage, number of heads per
unit, etc.
Account Group 9900 is reserved for Data Conversion account
creation. GL accounts will be created under this range for data
conversion purposes. Details of the account range breakdown will be
revisited upon the data conversion exercise is performed. This is
usually necessary to offset certain G/L postings during conversion.
These conversion accounts are in a specified range so that they
will be excluded from business operation financial statements, and
can be easily referenced for conversion data reconciliation
purposes.
Integration with Enterprise Consolidation module
According to standard SAP design, when EC-CS Consolidation
module is activated, users are required to enter Group Account
number in the COA segment of the GL Master Data upon new GL
creation. This ensures every FI-GL postings are seamlessly
integrated to the EC-CS Consolidation module to automatically
generate Consolidation documents. It also ensures that every
account in COA is specifically mapped to a Group Account in the
Group COA for the Consolidation module.
Integration with Country-Specific COA
For CCFR and CCSZ, Alternate Account field are set as required
field. This ensures users required to enter the Country-Specific GL
for all GL creation in the Company-code specific segment. For
detail treatment on government required Financial Statement formats
for France and PRC, please refer to Sections 3.2.3 on
Country-Specific Chart of Accounts and 3.2.4 on Special Purpose
Ledger for CCSZ.
Integration points with other SAP modules
For all bank accounts, the field Planning level in the
Company-Code Specific segment of GL Master links the cash flow
information to SAP Treasury Cash Management (TR-CM) module. For
details, please refer to Section 3.12 on Cash Management in this
document.
Asset Management/ Account Receivables/ Account Payables
sub-modules are integrated to FI-GL via the field Reconciliation
for Account Type in the Company-Code Specific segment of GL Master.
With this indicator, the GL account can only be posted via
respective sub-ledger in SAP. Different indicators for
Reconciliation for Account Type are:
A Asset Management
D Accounts Receivable
K Accounts Payable
Inventory accounts are posted to directly by movement of
materials. This occurs based on account assignment configuration
between the MM and FI modules. These GL accounts are set as
Automatically Post Only, which ensures the value always in sync
from MM to FI.
3.2.6. Multiple Reporting Views for AAA
This section describes the approach in SAP to cater the AAA
requirement of handling multiple accounting books for individual
company. The following are summarized requirements:
Note: These reporting views are accomplished through using
different financial statement versions for each view in accordance
with the GAAP or tax requirements.
3.3. Accounts Receivables
The accounts receivable application component records and
administers the accounting data of customers and this also
constitutes an integral part of Sales & Distribution module.
All postings in accounts receivable are also recorded directly in
the general ledger. Different G/L accounts are posted to depending
on the transaction involved (for example trade debtors).
3.3.1. Customer Master Maintenance
Customer master records contain data that control how
transaction data is posted and processed. This includes all of the
information about a customer that you need to be able to conduct
business with them. At AAA, customer master records will be
maintained by each Reporting Unit.
The master record is used in Sales and Distribution as well as
Financial Accounting. There are two methods of creation for
customers master data:
a. Create Centrally In Financial Accounting or Sales and
Distribution module
b. Create either in Accounting or SD module only
Customer Master Data are divided into 3 areas:
a. General data
b. Accounting Data
c. Sales Area Data
General data contains information such as Customers name,
address, language, and phone numbers, which is shared by both FI
and SD module. Meanwhile, Account control data like the
reconciliation account number in G/L accounting, Dunning procedures
and the date of the last dunning notice, in which the information
are purely meant for accounting purposes.
Customers who are related to the trade sales in which the sales
order are required from Sales & Distribution module will
require the Sales Area Data. The sales area data will contain
information like Order Currency, Order processing, shipping, and
billing data.
By storing customer master data centrally, you enable it to be
accessed throughout your organization, and avoid the need to enter
the same information twice. This central organization also prevents
data from being inconsistent between different application
components.
There are currently six customer groups identified in AAA Bbb.
For the numbering convention please review S&D Global Design
Document for reference.
Item
Customer GroupRelevant To SD
1CC Sold To Party
2CC Goods Receipts
3CC Payer
4CC Bill To Party
5CC Intercompany
6CC One Time Vendor (Staff)
3.3.2. Document Type
Document typeDescriptionNumber Range
DGCustomer credit memo1600000000-1699999999
DZCustomer payment1400000000-1499999999
DRCustomer invoice1800000000-1899999999
All FI document types are listed in Section 3.1. A document type
for a FI customer debit memos has been added to the list.
SD debit memos are booked in FI as document type RD. SD customer
returns are document type RR. Additional document types can be
defined according to AAAs requirements.
3.3.3. Trade Customer Master Data Maintenance
Please refer to Customer Master Data Maintenance in Sales &
Distribution module
3.3.4. Non-Trade/ Sundry Customer Master Data Maintenance
The customer master data for Sundry and Non Trade customers are
basically the same as the trade customer but without the Sales Area
Master Data
3.3.5. Payment Term
Payment term will serve to determine the invoices due date and
the discount amount as agreed upon at the time of the sale. The
payment term in the master data will default to the respective
invoice document. The payment term on these individual invoices can
be changed manually. Payment terms are independent of company
code.
As at the current stage of the Project, the following Payment
Terms have been identified:
CustomersVendors
Term CodeDescriptionTerm CodeDescription
Cash On deliveryCash On delivery
5 Days Credit5 Days Credit
7 Days Credit7 Days Credit
14 Days Credit14 Days Credit
One Month CreditOne Month Credit
45 Days Credit45 Days Credit
Two Month CreditTwo Month Credit
The FI/CO Design team will continue to collect any outstanding
payment terms from the FI/CO Business Representatives.
Although different coding were suggested for Customer and Vendor
Payment terms, users can decide to have the same payment terms used
for both AR and AP. For consistency, the payment terms should be
consolidated. Any special payment terms for specific countries will
need to be catered for as well.
Payment receipt dates are calculated based on Base Line Dates in
invoices. The Base Line Date is derived from the Document Date
(same as invoice date) that is manually entered.
3.3.6. Accounts Receivable Transaction Posting
Figure 3.2.5.1 Billing/Invoicing from SD Module
Billing From Sales And Distribution Module
For normal customers sales, the posting of invoice amount and
the cost of goods sold are issued during the billing and delivery
stage from the Sales and Distribution module. Refer to the SD
Global Design Document for further explanation.
Outgoing Invoice From FI-AR Module (Non Trade)
Sundry Customer, Staff advance and Inter-company Control
Account
Advance may be issued to staff and this is posted through the
Financial Accounting Account Receivable module. The posting method
is the similar to the GL posting but different in the document
number and document type.
Credit Note
For trade related credit memos please refer to SD document. One
note to point out is Finance will approve the credit memo created
in SD before it is posted in the general ledger. However, for non
trade-related, it will be done through the Financial Account
Account Receivable module.
Down Payment Posting
Figure 3.2.5.4 Customer Down Payment Posting
Down payment is posted into the SAP system using the special GL
indicator (A). The payment item is kept at each customers accounts.
The document header Reference Field will be used to keep track of
the sales order number that the down payment is referenced to.
During the payment period, the balance received from customer
can be cleared against the invoice issued and the down payment
received previously.
Duplication in delivery of goods will not occur since the system
will match the quantity recorded in the Sale Order. Letter of
Credit
Letter of Credit is posted into SAP system using the special GL
indicator (L). Once payment has been received from bank, Accounts
will record transaction in system.
Duplication in delivery of goods will not occur since the system
will match the quantity recorded in the Sale Order. Output Tax /
Sales Tax / Output VAT
In general all Sales Tax are set up in S&D when they bill
customers. For invoices created in FI that need to apply sales tax,
users have to manually select the correct rate before posting in to
SAP
BranchesRates (%)Output/VAT Tax CodesCode Description
CCUK0.0
17.5
0.0
0.0
0.0A0
A1
A3
A4
A5Exempt from output VAT
Standard output VAT
Delivery of goods in EU
Services within the EU
Subcontracting within EU
CCGermany0.0
16.0
7.0
0.0
0.0
0.0A0
A1
A2
A5
A6
A7Exempt from output VAT
Output VAT
Domestic Output VAT
EU exempt VAT - services
Delivery of goods in EU
Subcontracting within EU
CCFrance0.0
17.0A0
A1Exempt from output VAT
Output VAT
CCCorp0.0
6.0O0
O1Exempt from output tax
Output tax
CCCanada0.0
7.0GJ
AJSales GST Exempt,
Sales GST applicable
CCKeystone0.0
O0Exempt from A/R sales tax
(sales tax is always 0%)
CCHK0.0A0Tax exempt
CCWK0.0
17.0X0
X1Exempt form output tax
Output tax
CCSZ0.0
17.0X0
X1Exempt from output tax
Output tax
Each Branch will use one G/L account for tax. Invoices for EU
and non EU sales will contain the customer VAT registration number
and the Reporting Unit VAT registration number for the tax
exemption to be realized. Customer VAT numbers are set up in the
customer master record and will default into the transactions. This
will allow VAT reporting to meet statutory requirements.
Further analysis of the various sales tax applications will
occur during Detailed Design.
Incoming (Customer) payment
Figure 3.2.5.7 Accounts Receivable Payment
Currently, there are several payment terms being used in AAA
Bbb, among the current available terms are Down Payment, Full
Payment and Post Dated. For down payment and full payment, the
customers may use different payment methods such as Cheque Receipt
and Bank Transfer.
Regardless of the payment methods being used by the customer for
payment, the AAA Bbb accounting staff will use the post with
clearing function to offset the customers open item against the
bank or bank clearing account.
Posting With Clearing is done by entering the document line
items and then selecting the open items that need to be cleared.
Once the total amount of selected open items equals the amount of
entered line items, the system will post and clear the open
items.
In clearing these items, the system will assign a clearing
document number and the date on which they were cleared. Open item
management ensures that all items that have not yet been cleared
are available in the system. Only after every open item in a
document is cleared can a document be archived.
Partial and Residual Payment
In SAP, user can define the tolerance limit for system to accept
any payment difference. Please refer to AP for AAAs tolerance
range. SAP provides the flexibility in accepting any part payment
in 2 methods, Partial Payment and Residual Payment.
The difference between the Partial payment and Residual Payment
are as follows:
a. Partial payment will keep the original invoice line item open
until the full amount has been cleared. Meanwhile a cleared new
line item will be created for the paid amount.
b. Residual payment will clear the original invoice and create a
new line item and document with the unpaid amount to replace the
original invoice.
Both functions are available in the current system. However, the
decision on which function to use depends on how the user prefers
to see the line item in the customer records. Currently, the
partial payment function will be more appropriate to use at AAA
Bbb.
Full Payment
For full payment by mailing cheques, the account department will
post and clear the customer open items against the Bank Clearing
Receivables account. Upon clearance by the bank, the account staff
will perform a journal adjustment to clear the Clearing account to
the Bank Account.
For telegraphic transfer, WIRE transfer incoming payments and
direct bank-in, the customer will normally inform the accounting
staff of their intention to pay. They will also fax or send in
their bank in slip as proof of payment. The account staff will post
and clear the customer items upon the confirmation from the bank of
payment clearance.
3.3.7. Accounts Receivable Periodic Processing
Dunning/ Reminders To Customers
Dunning letters are actually the reminders sent to customers for
due payment. The level of dunning letters and the days interval for
each level still need to be identified
Generate Customer Statement
AAABbbThere will be two types of customer statement in AAA Bbb.
One internally which will be used between branches and one which
will be used for external customers.
Month End Open Item Revaluation
Foreign currency transactions may be posted at a different rate
to the current month end rate. Thus in preparing the current month
Balance Sheet, a revaluation process needs to be done.
In order to perform the revaluation in SAP, you must always
specify a Valuation method. This specifies exactly which type of
valuation will be carried out i.e. based on which currency type and
how detailed the resulting list for the valuation is to be.
Exchange rate differences resulting from the valuation of open
items and foreign currency balance sheet accounts are automatically
posted to specific accounts assigned during the configuration. The
amounts can be either a gain or loss, and are, therefore, posted to
either a revenue or expense account stored under a special key.
The unrealized gain or loss is the difference between the
exchange rate posted at the time of booking the invoice and the
current month end exchange rate. A reversal of this booking will be
automatically created for next month to eliminate this gain or
loss3.4. Accounts Payable
The accounts payable application component records and
administers accounting data for all vendors. It is also an integral
part of purchasing, where deliveries and invoices are recorded
based on each vendor. The system automatically makes postings to
the FI component in response to these transactions.
Postings made in Accounts Payable are simultaneously recorded in
the General Ledger where different G/L accounts are updated based
on the transaction involved (payables, down payments, etc.). To
help keep track of open items, there are due date forecasts and
other standard reports that be created.
During the Implementation phase, AAA will design balance
confirmations, account statements and other forms of reports
according to business correspondence requirements with vendors.
There are balance lists, journals, balance audit trails and other
internal evaluations available for documenting transactions in
Accounts Payable.
3.4.1. Vendor Master Maintenance
The vendors are classified in to six different account
groups;
Item
Vendor GroupRelevant To MM
1Vendors with PO
2Intercompany
3One Time Vendor
4Vendors without PO
5Boards of Directors
6Employees
Account Group is used to control the assignment of vendor code
and to maintain the consistency of vendor master data to be
maintained for the vendors in same account group. The vendor groups
are mutually exclusive.
The SAP system can assign vendor codes internally or externally.
At AAA Bbb, vendor codes will be created automatically based on the
system numbering sequence. The exception will be intercompany
vendors that where vendor codes will be externally assigned.
Regardless of the assignment method specified above, the range
and format of vendor codes are predefined in customization. Any
specification of vendor code (especially the external assignment)
beyond the valid vendor code range will not be accepted by the
system. For global vendors, a group key will be placed in their
master record to allow single reporting/monitoring of all related
vendor records in each Branch..In SAP, the data in vendor master
records control how transaction data are posted and processed for a
vendor. The vendor master record also contains all the data you
require to do business with your vendors.
The master record is used not only in Accounting but also in
Materials Management. By storing vendor master data centrally and
sharing it throughout the organization, the data are entered once
and inconsistencies in master data are prevented.
A vendor master record contains:
Vendors name, address, language, and phone numbers
Tax numbers
Bank details
Account control data like the number of the G/L reconciliation
account for the vendor account
Payment methods and terms of payment set up with the vendor
Purchasing data
Withholding tax information, for example 1099 tax
information
In the Materials Management module, the vendors are considered
as the suppliers.
3.4.2. Document Type
Document typeDescriptionNumber Range
KZVendor payment1500000000-1599999999
KGVendor credit memo1700000000-1799999999
KRVendor invoice1500000000-1599999999
For Credit memo in MM the document type will be RE and a
corresponding KG document will be created in FI. See Section 3.1.1
for document type details.
3.4.3. Trade Vendor Master Data Maintenance
Please refer to Vender Master Data Maintenance in Material
Management module
3.4.4. Non-Trade/ Sundry Vendor Master Data Maintenance
The vendor master data for Sundry and Non Trade vendor are
basically the same as the trade customer but without the Purchase
Organisation Master Data
3.4.5. Payment Terms
Payment terms are normally agreed upon by the purchasing
department and the vendors. A range of payment terms will be
maintained in system. See the table below for payment terms that
are identified at the current stage.
CustomersVendors
Term CodeDescriptionTerm CodeDescription
Cash On deliveryCash On delivery
5 Days Credit5 Days Credit
7 Days Credit7 Days Credit
14 Days Credit14 Days Credit
One Month CreditOne Month Credit
45 Days Credit45 Days Credit
Two Month CreditTwo Month Credit
14 days 2%, 30 net14 days 2%, 30 net
14 days 3%, 30 net14 days 3%, 30 net
14 days 5%, 31 net
105 days 3%, 120 net
60 days net60 days net
55 days net
30 days 3%, 45 days net
25. Of overnext month = between 56 and 85 days/ 3%
10. Of next month / 3%
45 days 3%, 60 net
15. Of next month / 3%
With the availability of the SAP system in the future, the
Purchasing Department will initiate the creation and maintenance of
the Basic and Purchasing views of vendor master data. They will
subsequently inform the Accounts Department to maintain the
Accounting and Payment views.
The purpose of dual level creation is mainly to smoothen and
fasten the Purchasing process without having to wait for the
Accounting staff to update the vendor master record. As soon as the
Basic and Purchasing views are maintained, purchase orders can be
issued and goods receipts can be processed.
Accounting Department must maintain the Accounting view for
newly created vendors before the three-way matching of Invoices to
purchase orders and goods receipts can be processed.
3.4.6. Accounts Payable Transaction Posting
Figure 3.3.2.1 Three-Way Matching Invoice Verification
Figure 3.3.2.5A Automatic Outgoing Payments
Figure 3.3.2.5B Automatic Outgoing Payments
Invoice From Material Management Module
The Invoice Verification component is part of the Materials
Management (MM) system. It provides the link between the Materials
Management component and the Financial Accounting, Controlling, and
Asset Accounting components.
Invoice Verification in Materials Management serves the
following purposes:
It completes the materials procurement process - which starts
with the purchase requisition, continues with purchasing and goods
receipt and ends with the invoice receipt
It allows credit memos to be processed, either as invoice
cancellations or adjustments.
The business scenario starts with an invoice sent from vendor.
Before the invoice is posted in the system three way matching of
purchase order, goods receipt and invoice is done manually with the
defaulted PO price and GR quantity from the system. The invoices
are documented and then exported to financial accounting.
During goods receipt, the accounting posting will be
Dr. Inventory
Cr. Goods Receipt \ Invoice Receipt (GRIR)
At the time of Invoice Matching, the posting will be
Dr. GRIR
Cr. Vendor 1
During the invoice matching, the invoice received from vendors
(either on spot or after the purchase) will be matched against the
purchase order and goods receipts given by Purchase Department.
At AAA, raw materials and finished goods will be valuated with
the moving average price using FIFO batch valuation, and
semi-finished goods will be valuated with a standard price in the
material master. If the inventory is valuated using a moving
average price, any price variances will be posted back into
material. If the inventory is valuated with a standard price in the
material master, then price variances will be posted to a purchase
price variance account.
To prevent duplication of invoices in the system, vendors
invoice numbers must be maintained in the Reference field at the
document header. The system will check this field for any
duplication from other vendor invoice and an error message will
appear noting a duplication has occurred. Depending on the
configuration, the system will stop the user from continuing with
the same reference number or allow the user to decide to continue
with the same reference number. Relevant payment methods will
default from the vendor master or will be maintained at the
transaction line item.
Incoming Invoice From FI-AP Module
Non-Purchase Order Invoices can be posted to the system by the
invoice entry function provided in Account Payable. No purchase
order is required during the posting process and the account
posting is as follows:
Dr. Expenses / Balance Sheet account
Cr. Vendor 1
Like the invoices related to Materials Management, in FI, the
vendors invoice number should be placed in the invoice documents
Reference field.
Debit Note/Credit Memo
There are three scenarios of goods returned to vendors:
a. Returned and pending the delivery for replacement
b. Returned before invoice verification and cancelled the
replacement
c. Returned after invoice verification and cancelled the
replacement
All purchasing returns will be done through return to vendor in
Material Management module. A return note will be given to the
accounts department to clear against the subsequent payment when it
is due. The main difference between these 3 scenarios is whether a
debit note/credit memo is required to be issued from the
system.
As in normal circumstances, debit notes are only required for
scenario C where the invoices were already billed at order quantity
above the actual quantity received.
Input Tax / Input VAT / Use Tax
The input tax will generally be shown in the Material Management
module however for invoices created in FI, users will have to
manually choose the tax rate.
BranchesRates (%)SAP Input/ VAT Tax CodesTax Code
Description
CCUK0.0
17.5
0.0
0.0
0.0V0
V1
V3
V4
V5Exempt from input VAT
Standard input VAT
Delivery of goods in EU
Services within the EU
Subcontracting within EU
CCGermany0.0
16.
7.0
16.0
7.0
16.0
7.0
0.0V0
V1
V2
E1
E2
E3
E4
E7Exempt from input VAT
Input VAT
Domestic Input VAT
Acquistion Tax EU delivery of goods
Acquisition Tax EU delivery of goods
Acquistion Tax EU subcontracting
Acquisition Tax EU subcontracting
Acquisition Tax Acquisition within EU
CC PeterB0.0
16.0
7.0
16.0
7.0
16.0
7.0
0.0V0
V1
V2
E1
E2
E3
E4
E7Exempt from input VAT
Input VAT
Domestic Input VAT
Acquistion Tax EU delivery of goods
Acquisition Tax EU delivery of goods
Acquistion Tax EU subcontracting
Acquisition Tax EU subcontracting
Acquisition Tax Acquisition within EC
CCFrance0.0
17.0V0
V1Exempt from input VAT
Input VAT
CCCorp0.0
6.0
0.0
6.0I0
I1
U0
U1Exempt from input tax
Input tax
Exempt from A/P use tax
A/P use tax
CCCanada0.0
7.0
TBDPJ
IJ
SJA/P GST Exempt,
A/P, GST applicable
Self assessment, GST
CCKeystone0.0
6.0
0.0
6.0I0
I1
U0
U1Exempt from input tax
Input tax
Exempt from A/P use tax
A/P use tax
CCHK0.0V0Tax exempt
CCWK0.0
0.0J0
J1Exempt from input tax
Input tax
CCSZ0.0
17.0J0
J1Exempt from input tax
Input tax
Each Branch will use one G/L tax account to record tax. Invoices
for EU and non EU purchases will contain the vendor VAT
registration number and the Reporting Unit VAT registration number
for the EU tax conditions to be implemented. Vendor VAT numbers are
set up in the vendor master record and will default into the
transactions. This will allow VAT reporting to meet statutory
requirements.
Further analysis of the various purchase tax applications will
occur during Detailed Design.
Outgoing (Vendor) Payment
Full Payment
Various payments types such as cheques, wire transfer, and cash
payment will be maintained in the SAP system.
Payment Method CodeDescriptionPayment MediumComments
ECashN/ACash Payment
CChequesCheque printed in-house or out-house, and an electronic
file with cheque information (positive-pay file)The positive-pay
file will be sent to the bank to validate the printed cheques when
deposited by the vendors.
TTeletex TransferN/AManual Payment handed to bank (usually
foreign currency payment to vendor who does not have an account
with HSBC)
WElectronic Funds TransferElectronic payment file with different
formats for different countries:
US ACH format
All other countries need to be confirmed by users whether
interface directly from SAP to Bank is needed
Electronic payment files will be sent to HSBC bank via
Hexagon
Payments are done either automatically or manually. Automatic
payment process starts with the auto-payment run on vendors
invoices. System will propose the vendors transactions that are due
for payment and it can be edited before the payment is posted by
the system.
For automatic payment process, different output will be
generated by the SAP system based on the payment types. For wire
transfer the system will generate only the payment summary with an
electronic file used to send to bank while for cheques payment, the
system will create the physical checks in addition to the summary
output.
For manual payment, posting with clearing concept will be used,
by entering the document line items and then select the open items
that are to be cleared. Once the total amount of selected open
items equals the amount of entered line items, the system clears
the open items by creating one or more offsetting entries. This is
mainly used for the ad-hoc transaction such as payments to vendors
using foreign currency, which do not have a bank account with
HSBC.
Down Payment
Down payment is posted in SAP using the Special GL Indicator
(A). This is similar to the posting of down payment received from
the customers. For down payment by cheque, the system will be able
to generate the physical cheque.
During the payment process, the down payment will be listed and
cleared against the invoices due and only the net amount will be
processed in the current process.
Letter of Credit
Letter of Credit (LOC) is posted in the SAP using the Special GL
indicator (L). This is similar to the posting of LOC received from
the customer.
During the payment process, the LOC will be listed and cleared
against the invoice.
Partial and Residual Payment
In SAP, users can define the tolerance limit for system to
accept any payment difference. The tolerance will be based on the
lesser of amount or percentage rate.
Payment Difference for Vendor / CustomerBased on Local
Currency
AmountPercentage
BranchCurrencyGainLossGainLoss
UKGBP5511
GermanyEUR5511
KeystoneUSD0000
CorpUSD0000
HKHKD0000
WKRMB0000
SZRMB0000
FranceEUR0000
SAP does provide the flexibility in accepting any part payment
in 2 methods, Partial Payment and Residual Payment.
The difference between the Partial payment and Residual Payment
are as follows:
a. Partial payment will keep the original invoice line item open
until the full amount has been cleared, mean while a new line item
will be created for the paid amount.
b. Residual payment will clear the original invoice and create a
new line item and document with the unpaid amount to replace the
original invoice.
Both functions are available in the current system. However, the
decision on which function to use depends on how the user prefers
to see the line item in the customer records. Currently, the
partial payment function will be more appropriate to use at AAA
Bbb.
3.4.7. Blocked Invoices
In general SAP allows manual blocking of invoices and payments,
users can select specific blocking reasons. Specific reports can be
retrieved from the SAP to monitor blocked invoices.
3.4.8. Accounts Payable Period Processing
Month End Open Item Revaluation
Please refer to AR Month End Open Item Revaluation under Section
3.3.7.
3.5. Intercompany AP / AR (FINANCE ONLY)
Several companies are involved in an intercompany transaction.
The system will post a separate document with its own document
number in each of the company codes. A common cross-company code
number links individual documents together. The system generates
line items automatically (receivables and payables arising between
company codes) in order to balance the debits and credits in each
document.
Figure 3.4 Intercompany Transactions
Company One
Dr.Expense / Balance Sheet account for Company One
CR. Intercompany AP
Company Two
DR. Intercompany AR
CR. Expenses / Balance Sheet account for Company Two
Each branch will have different general accounts for AP and AR
to separately identify there debits and credits.
This transaction will only be finance related. Intercompany
posting in Logistics will be posted in the system
automatically.
The process for posting intercompany transactions is as
follows:
1. The initial entry is parked.
2. Then an email is sent to the other branch to view the
document.
3. On approval of the transaction, the parked document is then
posted to the g/l in both companies. The company receiving the
revenue will be the one responsible to book into system using the
US dollar as base currency.
Note:
From FICO Prototype, it is agreed that there should be a
synchronised triggering party (AAA subsidiary) in recording the
intercompany transaction in SAP. Such party should be the
'Recipient of Revenue and should perform the posting in SAP'. AAA
Corporate should impose future policy for Intercompany Posting in
SAP. The rational should be: 'Recipient of Revenue should perform
the posting in SAP'. The party who receive the expense only need to
review the document after the posting.
3.5.1. Authorisation
Limited access will be given to users to restrict any mistake
incurred. The park function when creating the journal entries will
be used if supervisors need to check the entries are correct before
posting.
3.6. Asset Accounting
The Asset Accounting System (FI-AA) in SAP R/3 is used for
managing and supervising all the existing fixed assets in your
enterprise. It also serves as a subsidiary ledger to the FI General
Ledger, proving detailed information on the fixed assets
transactions.
However, according to the requirements in AAA, the Fixed Asset
system has the following limitations:
The Fixed Asset system is designed to manage the existing assets
that have already been purchased. Management of possible future
assets or capital investment cannot be done in fixed asset and is
supposed to be done in Investment Management (IM) module
Fixed Asset system generally does not provide linkage with a
material or product in Material Management (MM). To link a fixed
asset record to a material master, a work around solution is
proposed by using a PP master data called Production Resource Tool
(PRT).
The Fixed Asset system does not support flexible what if
scenario analysis. Changes in depreciation method or useful life is
available but are generally referring to actual changes instead of
changes for simulation only
3.6.1. Chart of Depreciation:
A Charts of Depreciation is the highest level organization
structure in SAP R/3 Asset Accounting which holds all the asset
accounting relevant settings such as Depreciation Areas and the
depreciation methods that are specific to a country. Since
different companies in the same country are subject to the same
legal regulation of fix assets depreciation, Chart of Depreciation
is usually country specific and more than one Company Codes could
be assigned to a single Chart of Depreciation. Each chart of
depreciation also includes the tax book.
Chart of Depreciation is a 3-character code that supports
alpha-numeric format. As it is generally country specific, normally
the coding of the Chart of Depreciation will include the country
codes.
The Chart of Depreciation in the to-be SAP R/3 System in AAA
will be:
Chart of DepreciationChart of Depreciation Descriptions:Company
code(s) assigned
ZHKHK Chart of Depreciation for AAA5100
ZUSUS Chart of Depreciation for AAA1000, 4100
ZCACanada Chart of Depreciation for AAA4200
ZCNChina Chart of Depreciation for AAA5200*
ZUKUK Chart of Depreciation for AAA3100
ZDEGerman Chart of Depreciation for AAA3300
ZFRFrance Chart of Depreciation for AAA3400
*Remarks: It is confirmed that no fixed asset management is
needed in company code 5300 (CCWK) as all the fixed assets in CCWK
are being booked in CCHKs Company Code.3.6.2. Depreciation
Area:
A Depreciation Area represents an independent depreciation book
in which different values can be calculated in parallel for each
fixed asset for different purposes. The depreciation terms and
values of expected life necessary for calculating a fixed asset
book value and depreciation are all managed in depreciation area
level. One single Chart of Depreciation could have more than one
Depreciation Area.
In each Chart of Depreciation in AAA, only the Depreciation Area
01 (Book Depreciation) will be integrated to the General Ledger in
FI for postings. Other than the book depreciation, company codes in
AAA Group could have up to two more Depreciations Areas for
depreciation and net book value calculation for other purposes.
Depreciation Area 15 is the depreciation calculation for Tax
purpose if the tax depreciation rule is different from the book
rule. For company codes that are having a ledger book currency
other than USD, an additional Group Currency Depreciation Area has
to be defined to provide the depreciation amount in group currency
amount. The definition of the group currency depreciation area is
actually a system requirement in a company code of which the
Parallel Ledger Currency has been activated in FI (for details of
the Parallel Ledger Currency, please refer to the FI General Ledger
section).
Depreciation area code is 2-digit numeric code ranging from
01-99. The depreciation areas that will be applied to each Chart of
Depreciation Areas and Company Codes are shown below:
Chart of DepreciationDepreciation areasDepreciation area
descriptionPosting to G/L
ZHK01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZUS01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZCA01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZCN01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZUK01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZDE01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
ZFR01Book depreciationYes
15Tax depreciationNo
30Group currency depreciationNo
3.6.3. Asset Class:
Asset Classes are used to classify fixed assets into different
categories according to their natures and G/L account postings. The
asset class catalog is relevant in all company codes in a client.
That means different companies are sharing the same set of Asset
Classes in the system. However, asset classes that are not
applicable to a certain Chart of Depreciation could be deactivated
in that Cha