You are on page 1of 147

Global SAP Implementation Program Phase One

Prepared by: Finance Design Team


Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Global SAP Implementation Program

Conceptual Design Document


Finance & Controlling
Version 1.1
(12.12.2003)

Document Change History

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 1 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 2 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Table of Contents
1.

INTRODUCTION.............................................................................................................................2
1.1.

2.

FINANCE ENTERPRISE ORGANIZATIONAL STRUCTURES IN SAP................................2


2.1.
2.2.
2.3.
2.4.
2.5.
2.6.

3.

AAAS FINANCIAL PROCESSES IN SAP........................................................................................2


COMPANY CODE STRUCTURE.......................................................................................................2
SAP ENTERPRISE CONSOLIDATION (ECCS) ORGANIZATION STRUCTURE.................................2
CHART OF ACCOUNTS STRUCTURE..............................................................................................2
ASSET ACCOUNTING STRUCTURE................................................................................................2
CONTROLLING ORGANIZATIONAL STRUCTURE............................................................................2
COST CENTER STRUCTURE...........................................................................................................2

FINANCE & CONTROLLING PROCESS DESIGN CONCEPTS.............................................2


3.1.
FINANCIAL ACCOUNTING GLOBAL SETTINGS..............................................................................2
3.1.1.
FI Document Type/ Number Range.....................................................................................2
3.1.2.
Currency..............................................................................................................................2
3.1.3.
Exchange Rates...................................................................................................................2
3.1.4.
Fiscal Year Variant..............................................................................................................2
3.1.5.
Opening and Closing Posting Periods................................................................................2
3.2.
GENERAL LEDGER........................................................................................................................2
3.2.1.
GL Master Data...................................................................................................................2
3.2.2.
Operating Chart of Accounts..............................................................................................2
3.2.3.
Country-Specific Chart of Accounts....................................................................................2
3.2.4.
Special Purpose Ledger for CCSZ......................................................................................2
3.2.5.
GL Master Data Maintenance.............................................................................................2
3.2.6.
Multiple Reporting Views for AAA......................................................................................2
3.3.
ACCOUNTS RECEIVABLES.............................................................................................................2
3.3.1.
Customer Master Maintenance...........................................................................................2
3.3.2.
Document Type....................................................................................................................2
3.3.3.
Trade Customer Master Data Maintenance........................................................................2
3.3.4.
Non-Trade/ Sundry Customer Master Data Maintenance..................................................2
3.3.5.
Payment Term......................................................................................................................2
3.3.6.
Accounts Receivable Transaction Posting..........................................................................2
3.3.7.
Accounts Receivable Periodic Processing..........................................................................2
3.4.
ACCOUNTS PAYABLE....................................................................................................................2
3.4.1.
Vendor Master Maintenance...............................................................................................2
3.4.2.
Document Type....................................................................................................................2
3.4.3.
Trade Vendor Master Data Maintenance............................................................................2
3.4.4.
Non-Trade/ Sundry Vendor Master Data Maintenance.......................................................2
3.4.5.
Payment Terms....................................................................................................................2
3.4.6.
Accounts Payable Transaction Posting...............................................................................2
3.4.7.
Blocked Invoices..................................................................................................................2

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 3 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.4.8.
Accounts Payable Period Processing..................................................................................2
3.5.
INTERCOMPANY AP / AR..............................................................................................................2
3.5.1.
Authorisation.......................................................................................................................2
3.6.
ASSET ACCOUNTING....................................................................................................................2
3.6.1.
Chart of Depreciation:........................................................................................................2
3.6.2.
Depreciation Area:..............................................................................................................2
3.6.3.
Asset Class:.........................................................................................................................2
3.6.4.
Asset Number Range :.........................................................................................................2
3.6.5.
Asset Depreciation Methods:..............................................................................................2
3.6.6.
Asset Master Maintenance:.................................................................................................2
3.6.7.
Asset Transactions...............................................................................................................2
3.7.
COST CENTER ACCOUNTING........................................................................................................2
3.7.1.
Cost Center Structure..........................................................................................................2
3.7.2.
Statistical Key Figures........................................................................................................2
3.7.3.
Overhead Allocation............................................................................................................2
3.7.4.
Re-posting of cost................................................................................................................2
3.7.5.
Period End-Closing.............................................................................................................2
3.8.
INTERNAL ORDER.........................................................................................................................2
3.8.1.
Order Master Data Creation...............................................................................................2
3.8.2.
Order Actual Transaction Posting.......................................................................................2
3.8.3.
Month End Process..............................................................................................................2
3.9.
PRODUCT COSTING.......................................................................................................................2
3.9.1.
Logistics Master Data.........................................................................................................2
3.9.2.
CO Master Data..................................................................................................................2
3.9.3.
Summary of Product Cost Approaches................................................................................2
3.9.4.
Activity type prices planning...............................................................................................2
3.9.5.
Percentage Overhead Rates Maintenance..........................................................................2
3.9.6.
Quantity Overhead Rates Maintenance..............................................................................2
3.9.7.
Cost Estimate Calculation...................................................................................................2
3.9.8.
Standard Price Update from Standard Cost Estimate Mark & Release...........................2
3.9.9.
Standard Cost Estimates for Single Use Bbb (SUC)...........................................................2
3.9.10. Production Order Processing for Semi-finished Goods......................................................2
3.9.11. Production Order Processing for Finished Goods..............................................................2
3.10.
PROFITABILITY ANALYSIS........................................................................................................2
3.10.1. Organisation Unit in COPA.................................................................................................2
3.10.2. COPA Method Deployment..................................................................................................2
3.10.3. COPA Structure - Characteristics.......................................................................................2
3.10.4. COPA Structure Value Fields...........................................................................................2
3.10.5. Actual Value Flow into COPA.............................................................................................2
3.11.
BUDGETING/PLANNING............................................................................................................2
3.11.1. SAP R/3 modules deployed for Annual Budgeting..............................................................2
3.11.2. Plan Version........................................................................................................................2
3.11.3. Planning Layout..................................................................................................................2
3.12.
CASH MANAGEMENT...............................................................................................................2
3.12.1. Common information and differences between Cash Position and Liquidity Forecast......2
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 4 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.12.2. Memo Records.....................................................................................................................2


3.12.3. Cash Position......................................................................................................................2
3.12.4. Liquidity Forecast...............................................................................................................2
3.12.5. Integration with Special GL transactions (FI-GL)..............................................................2
3.12.6. Electronic Bank Reconciliation...........................................................................................2
3.12.7. Cash Concentration.............................................................................................................2
3.13.
CONSOLIDATION PROCEDURES.................................................................................................2
3.13.1. Consolidation Units.............................................................................................................2
3.13.2. Consolidation Groups.........................................................................................................2
3.13.3. Consolidation Chart of Accounts and Financial Statement Items......................................2
3.13.4. Design Highlights................................................................................................................2
3.13.5. Data Collection Process......................................................................................................2
3.13.6. Consolidation Process.........................................................................................................2
4.

REPORTING.....................................................................................................................................2
4.1.

LIST OF TO-BE REPORTS..............................................................................................................2

5.

LIST OF CUSTOMISATIONS.........................................................................................................2

6.

LIST OF INTERFACES...................................................................................................................2

7.

OUTSTANDING ITEMS/ DECISIONS..........................................................................................2

8.

ANNEXES..........................................................................................................................................2
8.1.
8.2.

ANNEX 1: COST CENTER HIERARCHICAL STRUCTURE................................................................2


FINANCE REQUIREMENTS.............................................................................................................2

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 5 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:
o General Ledger,
o Accounts Receivable
o Accounts Payable
o Asset Accounting
Controlling:
o Overhead Cost Controlling
o Product Costing
o 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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 6 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Concord SAP FI/CO Modules


CO
PA

Profitability
segment

Profitability
ProfitabilityAnalysis
Analysis

Internal
orders

Cost centers

Activity
types

CO

CEL

Sales

orders

CO
PC

Consolidation

CO

OM
Overhead
Overhead Cost
Cost Controlling
Controlling

Product
ProductCost
Cost

Controlling
Controlling

Projects

Processes

Material
Material

valuation
valuation

Warehouse
production

EC CS

Cost
Cost Element
Element Accounting
Accounting

FIFinancial
Financial

Accounting

Asset

Revenues

Expense

Accounting

AA

TR

Asset
Accounting

Human
HR
Integration
with
Resources
Logistics Modules:

MM

Materials
Materials

Management
Management

Figure 1.1

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 7 of 147

PP

Treasury
Cash Management

Production
Production

SD

S&D
S&D

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Structure
2) Consolidated Company Structure
3) Chart of Accounts Structure
4) Asset Accounting Structure
5) Controlling Structure
6) 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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 8 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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
Finance
Organizational
Structure
Consolidation
Units
using the consolidation procedures.
SAP Company Codes

Investigations are in progress to determine


the best way to generate consolidated financial reports
SAP Code 1000
for all of Europe.
Concord
Camera Corp.
(US)

SAP Code 4100 SAP Code 4200 SAP Code 3100 SAP Code 3300 SAP Code 3400 SAP Code 5100 SAP Code 4500 SAP Code 3500 SAP Code 4400 SAP Code 4300

SAP Code 4
63
10
00
0

Concord
Concord
Concord
Concord
Concord
Keystone Sales
Camera(Europe)
Camera GmbH Camera France
Camera Canada
Corp.
Limited
S.A.R.L

Concord
Concord
Latin
America
Australia

(US)

(Canada)

(UK and Northern


Ireland)

SAP Code3200

256783903.doc
Goldline
Printed on: 1/9/2015 2:56 (Europe)
PM
Limited

(UK and Northern


Ireland)

(Germany)

StarprintCorp.

(HK)

(France)

SAP Code3500

Concord
Camera HK
Limited

(US)

SAP Code 5200 SAP Code 5300


Concord
Concord
Henggang
Shenzhen
Electronics
Limited
Factory

Page 9 of 147

Peter Bauser
Brauser
(Germany)

(PRC)

(PRC)

Concord
Camera
Hungary
(Hungary)

Concord
Keystone
Graphics
(US)

Concord Latin
America
(Latin America)

(Australia)

Legend:
Grey highlighted box represents a dormant company

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

SAP Consolidate Units &


Consolidation Groups
[100%]

Consolidation
Group

SAP Code 1000

Concord
Camera
Corp.

(Country)
[Ownership
Percentage]

(US)

[100%]

Consolidation
Unit/
Company
(Country)
Ownership
Percentage

[100%]

SAP Code 4100

SAP Code 4200

Concord
Keystone
Sales Corp.

Concord
Camera
Canada

(US)

( Canada )

[100%]

[100%]

[100%]

[100%]

[100%]

SAP Code CG3000

SAP Code CG3300

SAP Code 3400

SAP Code CG5100

Consolidate
Subgroup
CCEurope

Consolidate
Subgroup
(CCGMBH)

Concord Camera
France S.R.R.L

Consolidate
Subgroup
(CCHK)

(Europe)

(Germany)

[100%]

[100%]

(France)

(HK)

[100%]

[100%]

[100%]

SAP Code 3500

SAP Code 4400

SAP Code 4300

SAP Code 6300

Starprint
Corp.

Concord
Camera
Hungary

Concord
Keystone
Graphics

Concord
Latin
America

Concord
Australia

(US)

(Hungary)

(US)

(Latin America)

(Australia)

[100%]

SAP Code 3100

SAP Code 3300

SAP Code 5100

Concord Camera
(Europe) Limited

Concord Camera
(CCGMBH)

Concord Camera
HK Limited

(UK and
Nothern
Ireland)

(Germany)

[100%]

[100%]

[100%]

SAP Code 3200

SAP Code 3600

Goldline
(Europe)
Limited

Peter
Bauser

(UK and
Nothern
Ireland)

[100%]

SAP Code 4500

(Germany)

SAP Code 5200

Concord
Henggang
Electronics
Factory
(PRC)

[100%]
SAP Code 5300

Concord
Shenzhen
Limited
(PRC)

Legend:
Grey highlighted box represents a dormant company These consolidation units will only store historical data;
will have no further activity.

Figure 2.2

AAA 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 30 th, 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 30 th, 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 30 th, then every posting in

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 10 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 11 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

(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.
Chart of
depreciation

Depreciation
area: Book

Depreciation
area: Tax

Depreciation
area:
Group

Company
code(s)

Asset Classes

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 12 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

Controlling Organizational Structure


Operating
Concern (CO -PA)

CCG
Concord Group

[SAP Profitability Analysis


(CO -PA) module]

Controlling
Area(CO)

CCG
Concord Group

[SAP Controlling
modules]

Company
Codes (FI)
[SAP Financial
Accounting modules]

1000

4100

4200

3100

3400

3300

5100

Concord
Camera Corp.

Concord
Keystone Sales
Corp.

Concord
Camera Canada

Concord
Camera(Europe)
Limited

Concord
Camera France
S.A.R.L

Concord
Camera GmbH

Concord
Camera HK
Limited

(US)

(Canada)

(US)

(UK and Northern


Ireland)

(France)

(Germany)

(HK)

SAP Code TBD


3600

SAP Code430
Code TBD
0

SAP Code 320


TBD
0

SAP Code 450


TBD
0

SAP Code3
Code TBD
500

SAP Code6
TBD
100

Concord
Peter
Keystone
Bauser
Graphics

Concord Latin
America

Goldline
(Europe)
Limited

Starprint Corp.

Concord
Camera
Hungary

Concord
Camera
Hungary
Australia

(US)

(Hungary)

(Australia)
)

((Germany)

(Latin America) (UK and Northern


Ireland)

5200
Concord
Henggang
Electronics
Factory
(PRC)

5300
Concord
Shenzhen
Limited
(PRC)

Legend:
Grey highlighted box represents a dormant company

Figure 2.3

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 13 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 14 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Level 1

Description Level
2
Description Level 3

CCG

AAA Bbb Grp 1000

CCC

3100

CCUK

3300

CCGMBH

3400

CCFR

4100

CCUS

4200

CCCA

5100

CCHK

Description

1000-3
1000-5
1000-6
1000-7

Supply Chain
Sales
Engineering
Administration

3100-3
3100-5
3100-7
3300-3
3300-5
3300-7
3400-3
3400-5
3400-7
4100-3
4100-5
4100-7
4200-3
4200-5
4200-7
5100-3
5100-4

Supply Chain
Sales
Administration
Supply Chain
Sales
Administration
Supply Chain
Sales
Administration
Supply Chain
Sales
Administration
Supply Chain
Sales
Administration
Supply Chain
Production

5100-5
5100-6

Sales
Engineering

5100-7

Administration

Level 4

Description

1000-611
1000-791
1000-795
1000-796

US Design
Executives
Information Technology
Finance

4100-333 Warehouse/Storage

5100-449 Supporting Service


5100-44X Production Line
5100-610
5100-612
5100-620
5100-630
5100-640

Design Engineering
US Production Design
Project Management
Production Engineering
Quality Engineering

5100-791 Executives
5100-796 Finance
5200

CCWK

256783903.doc
Printed on: 1/9/2015 2:56 PM

5200-3
5200-4

Supply Chain
Production

5200-6

Engineering

Page 15 of 147

5200-449
5200-44X
5200-610
5200-620
5200-630

Supporting Service
Production Line
Design Engineering
Project Management
Production Engineering

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 16 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Analysis
3.11 Budgeting / Planning
3.12 Cash Management
3.13 Consolidation Procedures

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 17 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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
module

FI Document
Types

AM
AM

AA
AF

AP

FI Document Type
Description

Accoun
t Type

Reverse
Document
Type

Asset posting
Dep. postings

ADKMS
AS

AA
AF

KA

01
03
17

Other Vendor document

AKMS

KA

AP

KG

17

Vendor credit memo

AKMS

KG

AP

KR

19

Vendor invoice

AKMS

KR

AP
AP
AP

KZ
ZP
ZV

15

KS
ADKMS
ADKMS

KZ
ZP
ZV

AR

DA

Vendor payment
AutoPayment Posting
Auto Payment clearing
Other Customer
document

DS

DA

DG

03

Customer credit memo

DS

DG

AR

DR

18

Customer Invoice

ADMS

DR

AR
GL
MM
MM
MM

DZ
SA
PR
RE
RI

14

DS
ADKMS
MS
AKMS
AKMS

DZ
SA

MM

WA

01
48
51
52
49

Customer payment
G/L account document
Price change
Invoice receipt
Invoice receipt-Interco.
Goods issue

AMS

WA

WE

50

Goods receipt

AMS

WE

MM
MM
SD
SD
SD

WI
WL
RC
RD
RR

49

AMS
AMS
DS
DS
DS

WI
WL
RC
RD
RR

SD
SD
SD
CM

RS
RV
RW
ZR

86
88
81
20

Inventory document
Goods issue/delivery
SD Credit Memo
SD Debit Memo
SD Credit for Return
SD Rebate Credit
Memo
SD Invoice
SD Invoice-Interco.
Bank reconciliation

DS
ADS
DS
DKS

RS
RV
RW
ZR

AR

MM

No. Range
assignment

20
20
16

49
82
83
85

RE
RI

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)
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 18 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 19 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 20 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Number Range

Document no. from

Document no. to

01
03
14
15
16
17
18
19
20
47
48
49
50
51
52
81
82
83
85
86
88

0000100001
0000300001
1400000000
1500000000
1600000000
1700000000
1800000000
1900000000
2000000000
4700000000
4800000000
4900000000
5000000000
5100000000
5200000000
8100000000
8200000000
8300000000
8500000000
8600000000
8800000000

0000199999
0000399999
1499999999
1599999999
1699999999
1799999999
1899999999
1999999999
2099999999
4799999999
4899999999
4999999999
5099999999
5199999999
5299999999
8199999999
8299999999
8399999999
8509999999
8699999999
8899999999

3.1.2.

Currency

Currencies in SAP standard system are set as the ISO (International


Standardization)1 standards, for example, USD for US dollar.

Organization for

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 2 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:
1

ISO. The source of ISO 9000 and more than 14 000 International Standards for business, government and society. A
network of national standards institutes from 148 countries working in partnership with international organizations,
governments, industry, business and consumer representatives.
2
Parallel Currency in SAP refers to additional currency that will be updated simultaneously by system upon FI postings.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 21 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 22 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 23 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Exchange Rate Type

Business Usage

SAP configuration settings

Code

Description

Summary

Details

Reference
Currency

*Indicator:
Calculation
allowed
with
inverted
exchange
rate?

**European
Monetary
Union statutory
guidelines
met?

EURX

EMU Conversion
method not
participant

Act as
Average rate
for all
translation
with EUR

- Used for all


translations with
EUR
- Direct Quote
should be used

EUR

Average

For 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 type

N/A

Closing Rate

Period end
foreign
currency
valuation

- This rate
applies to all
currencies
(including EUR)

N/A

1001

Historical
Exchange
Rate

Consolidation
- Foreign
Curr
Translation

- Can be applied
per specific set
of accounts in
Group COA

N/A

1002

Current Rate

Consolidation
- Foreign
Curr
Translation

- Can be applied
per specific set
of accounts in
Group COA

N/A

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 24 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Revaluation

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

Opening and Closing Posting

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 25 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 26 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.2.

General Ledger

G L/FI Posting
FI D ocum ent
H eader

FI docum entLine Item s


FI Posting O nly

Integration to
C O (C ontrolling O nly

B alance Sheet Item

FIN A N C E

Enter
H eader
D etail

Enter FI Line Item

- C om pany C ode
- Posting/ D ocum ent D ate
- R eference no.
- C urrency/ rate

Enter
- G /L A ccount
- A m ount
- Text(if needed)

Enter another FI
Line item

EN D
Is ita B /S
item ?

Y ES
R equired

A .O verhead C ost
B .C ostR educing R evenue
C .O perating Sale
D .Sales R eduction

P& L
Item

C ostC enter
Or
R ealInternal
O rder

B
NO

Enter
- G /L A ccount
- A m ount
- Text(if needed)

W hich C O object
to assign?

C
D

O ptional
Statistical
Internal
O rder

C O PA Profit
Segm ent

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 27 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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/ Regroup3 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

Regroup: Perform transfer postings in presenting assets or liabilities in correct place for Financial Statement Reportings.
For example, for group of bank accounts with total credit balance, value need to be presented on the liability side of the
Financial Statement Reports, this is aided by means of a function called Regroup in SAP in generation of this transfer
posting.
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 28 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 29 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Accounts

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 30 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Detailed Business Usages and characteristics on different types of SAP COA:

Operating COA
Group COA

Country Specific COA

Business Usage
AAA Usage

Day to Day Operation

Consolidation

Support government
specific format Financial
Statement generation

Type of
Financial
Statements
(FS) generated

All individual AAA


Company FS

Consolidated FS
(either sub-group
level, or Group level)

Government specific
format FS

Example of
AAA units
deployed

CCUS, CCUK, CCHK,


etc.

Sub-group HK, UK,


Germany, etc.

CCSZ, CCFR

Group AAA
Corporate

SAP specific information


FI-GL
SAP module
(Financial Accounting
General Ledger)

EC-CS

FI-GL

(Enterprise
Controlling
Consolidation)

(Financial Accounting
General Ledger)

Master Data

Exist 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 FIGL

Exist 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
Master

Linked to FI-GL by
Alternate Account
field in Company Code
specific segment of GL
Master

Document
Creation
Frequency

FI 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-time

No document will be
posted. Reports will
draw values posted on
FI-GL

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 31 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:
Description
Chart of
Accounts
[4
characters]
CONO

[50 characters]

AAA Global Operating Chart of Accounts

Length of
G/L
account
number

Related
Group
Chart of
Accounts

CONC

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

Country-Specific Chart of

This addresses the needs of AAA France and AAA Shenzhen governmental financial
reporting needs.
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 32 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:
Description
Chart of
Accounts
[4
characters]

[50 characters]

Max
Length of
G/L
account
number

Related
Group
Chart of
Accounts

CCFR

France Country Chart of Accounts

10

CONC

CCSZ

China Country Chart of Accounts

10

CONC

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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 33 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

CCSZs day-to day


postings

China government
specific postings

COA

Operating COA

Country-Specific COA

SAP Module

General Ledger (FI-GL)

Special Purpose Ledger


(FI-SL)

Fiscal Year

June, 4-4-5 based

Calendar year

Users input

Yes

No (auto-post)

Financial Statement
generation

Set a Financial
Statement Version to
group Operating GL
accounts

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 34 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

G eneralLedger M asterD ata M aintenance

CCC on the above chart refers to AAA Bbb Corporate


C reate G /L A ccount

As stated in the FICO Prototype,


the initial request for GL account creation/ changes from subsidiaries, a
centrally in CO Afor
level
standardised
form
need
to
be
applied
A
and C om pany Code with reasons on the requests. There will be an exercise for the users in
Level form. This request form is to be processed out of SAP and proposed to utilise
designing this new standardised
the current AAA Lotus Notes(FS00)
approval features.

FIN A N C E

Figure 3.1.1 General Ledger Master Data Maintenance


EnterG /L A ccount
# and Com pany
Code
[C reate w /
TemKey
plate]control

D efine G /L
A ccount
D etails

NO
points in GL Master Data:

Is this a P& L
account?

Y ES

Create Cost
Elem ent
(FS00)

Rem arks:
* N ew G /L num ber should be consistentw ith Concord O perating C O A A ccountG roup D efinition
256783903.doc
* Ensure assignm entofG roup A ccountnum beris correct
Printed on:
1/9/2015 2:56 PM
Page 35 of 147

End

Save A ccount
M asterD ata

D efine C ost
Elem ent
D etail
(FS00)

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

SAP GL account
COA Segment

Usage

Remarks

Company Code
Specific
Segment

General
Description

Short Text/ Long Text


(in different language
if needed)

P&L or B/S
account?

Radio button

For P&L accounts, SAP


will automatically create
respective Primary Cost
Element upon saving of
new GL Master

Account group

Limit GL account no.


range

Example: Current Assets/


Fixed Assets, etc.

Group Account
Number

Integration to
Consolidation module

Required field for all GL


Master data

Account
Currency

Controls the posting


currencies in the
account

If 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
Number

Linkage to CountrySpecific COA

Only populate for CCSZ


and CCFR for AAA

Authorization
Group

Allows 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:
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 36 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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

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]
1000
2000
3000
4000
5000
6000
6100
6200
6600
6700
7000
7100
7200
7300
7400
7500
8000
8100
9000
9900

Description [30 Characters]

GL Account range from/


to

Current Assets
Long Term Assets
Current Liabilities
Long Term Liabilities
Shareholders' Equity
Revenues
Sales Returns and Allowances
Cost of Sales
Selling Expenses (Var)
Selling Expenses (Fix)
General & Administrative Expenses
Interest & Finance Charges
Interest Income
Intercompany Income/ Expense
Other Income / Expense
Income Tax Expense
GAAP Reporting/Statutory
Adjustments
Adjustments for Global Transfer
Prices for Tax
(by corporate)
CO Accounts
(secondary cost elements only)
Data Conversion Accounts

1000 0000-1999 9999


2000 0000-2999 9999
3000 0000-3999 9999
4000 0000-4999 9999
5000 0000-5999 9999
6000 0000-6499 9999
6100 0000-6199 9999
6200 0000-6299 9999
6600 0000-6699 9999
6700 0000-6799 9999
7000 0000-7099 9999
7100 0000-7199 9999
7200 0000-7299 9999
7300 0000-7399 9999
7400 0000-7499 9999
7500 0000-7599 9999
8000 0000-8099 9999
8100 0000-8100 9999
9000 0000-9899 9999
9900 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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 37 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 (TRCM) 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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 38 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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:

Concord Finance Multiple Reporting Views

A
+
B
+
C

B lock B
[A djustm ent
G L]

B lock C
[A djustm ent
G L]

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 39 of 147

IN FO

from
FI

C onsolidation C O A
G R O U P G /L
1
2
3
4
5
6
.
.
E
.
.
.

A ll adjustm ent
G L from FI
m ap to
dum m y G roup
A ccount in
EC -C S
[N ot affecting
C onsolidation]

IN FO

from
FI

M gm t
R eport
(C O PA )

R eports

3. G lobal T ax
Planning

R eports

B lock A
[O perating
CO A ]
1
2
3
4
5
6
.
.
.
.

2.L ocal
GAAP

R eports

U SG A A P

R eports

FI-G L
1.D ay to D ay
G L accounts O peration

V alue Fields
e.g.

*G ross Sales
*Sales
D eduction
*CO G S
*Selling
Expenses
*G & A
...

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Note: These reporting views are accomplished through using different financial statement versions for each view
in accordance with the GAAP or tax requirements.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 40 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 41 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Item
1
2
3
4
5
6

Customer Group

Relevant To SD

CC Sold To Party
CC Goods Receipts
CC Payer
CC Bill To Party
CC Intercompany
CC One Time Vendor (Staff)

3.3.2.

Document Type

Document type Description


Number Range
DG
Customer credit memo
1600000000-1699999999
DZ
Customer payment
1400000000-1499999999
DR
Customer invoice
1800000000-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.
Maintenance

Trade Customer Master Data

Please refer to Customer Master Data Maintenance in Sales & Distribution module

3.3.4.
Master Data Maintenance

Non-Trade/ Sundry Customer

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:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 42 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Term
Code

Customers
Description
Cash On delivery
5 Days Credit
7 Days Credit
14 Days Credit
One Month Credit
45 Days Credit
Two Month Credit

Vendors
Term Code

Description
Cash On delivery
5 Days Credit
7 Days Credit
14 Days Credit
One Month Credit
45 Days Credit
Two 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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 43 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.3.6.
Posting

Accounts Receivable Transaction

Sales &
D istribution

A ccount R eceivable - C reate Invoice

SD B illing
D ocum ent

Sales O rder
Process

FIN A N C E

Service
Provided to
C ustom er

Enter C ustom er
Line Item
(A R )

Enter A R Invoice
(H eader D etail)

A R D ocum ent Posted

Enter R evenue
Line Item
(G /L)

Sim ulate 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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 44 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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

A ccountR eceivable - C reate D ow n paym ent (C ustom er A dvance)

FIN A N C E

R eceive
C ustom er
A dvance

Enter D ow n
paym entD etails
(F-29)

Sim ulate Posting

PostD ocum ent

M anualProcess

C ustom er D ow n
paym ent
C learing
(F-39)

Sim ulate Posting

PostD ocum ent

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 45 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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
Branches
CCUK

CCGermany

CCFrance
CCCorp
CCCanada
CCKeystone
CCHK
CCWK
CCSZ

Rates (%) Output/VAT


Tax Codes
0.0
A0
17.5
A1
0.0
A3
0.0
A4
0.0
A5
0.0
A0
16.0
A1
7.0
A2
0.0
A5
0.0
A6
0.0
A7
0.0
A0
17.0
A1
0.0
O0
6.0
O1
0.0
GJ
7.0
AJ
0.0
O0
0.0
0.0
17.0
0.0
17.0

A0
X0
X1
X0
X1

Code Description
Exempt from output VAT
Standard output VAT
Delivery of goods in EU
Services within the EU
Subcontracting within EU
Exempt from output VAT
Output VAT
Domestic Output VAT
EU exempt VAT - services
Delivery of goods in EU
Subcontracting within EU
Exempt from output VAT
Output VAT
Exempt from output tax
Output tax
Sales GST Exempt,
Sales GST applicable
Exempt from A/R sales tax
(sales tax is always 0%)
Tax exempt
Exempt form output tax
Output tax
Exempt 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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 46 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 47 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Incoming (Customer) payment

Account Receivable - Partial


Payment
Incoming
Payment &
Remittance
Advice
Received from
Customer

FINANCE

NO

Select Invoice
from
Customer
Account
(FB-28)

Partial
Payment
(FB-28)

Partial
Payment
Posted
(FB-28)

View
Customer
Account
(FB-03)

Full
Payment?

YES

Selected Invoice on
Customer Account w/
info from Remittance
Advice
(FB28)

Payment
Posted
(FB-28)

View
Customer
Account
(FB-03)

Small Difference will go into small


difference account

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 48 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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

Accounts Receivable Periodic

Dunning/ Reminders To Customers

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 49 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 loss

3.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.
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 50 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Group

Relevant To MM

1
2
3
4
5
6

Vendors with PO
Intercompany
One Time Vendor
Vendors without PO
Boards of Directors
Employees

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 51 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 type
KZ
KG

Description
Vendor payment
Vendor credit memo

Number Range
1500000000-1599999999
1700000000-1799999999

KR

Vendor invoice

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

Trade Vendor Master Data

Please refer to Vender Master Data Maintenance in Material Management module

3.4.4.
Data Maintenance

Non-Trade/ Sundry Vendor Master

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

Customers
Description
Cash On delivery
5 Days Credit
7 Days Credit
14 Days Credit
One Month Credit

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 52 of 147

Vendors
Term Code

Description
Cash On delivery
5 Days Credit
7 Days Credit
14 Days Credit
One Month Credit

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

45 Days Credit
Two Month Credit
14 days 2%, 30 net
14 days 3%, 30 net
14 days 5%, 31 net
105 days 3%, 120 net
60 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%

45 Days Credit
Two Month Credit
14 days 2%, 30 net
14 days 3%, 30 net
60 days net

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Accounts Payable Transaction

Page 53 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Process Invoice Verification

Purchase

SAP
Purchase
Order

Receive &
Approve
Vendor
Invoice

SAP Goods
Receipt
Document

Enter
Invoice

- Invoice auto-blocked by system


- Can be manually blocked
- Invoice can be parked until further
investigation completed

3 Ways Matching:
Match Invoice with
PO Price & GR Qty

Block
Invoice for
Payment

Finance

NO

Simulate
Posting
(MIRO)

Price & Qty within


tolerance allowed
(3-way matching)?

YES

Invoice
Verification
Document

Save
Document
(MIRO)

Figure 3.3.2.1 Three-Way Matching Invoice Verification


Account Payable- Automated Payment

Invoice
Verification
Documents

FINANCE

Release
Blocked
Invoices ready
for payment

Enter/Revise
Payment
Criteria
(F-110)

Execute
Payment Run
(F-110)

Payment Method:
1.Cheque (+ Positive Pay File)
2. Wire, Transfer

Delete
Payment
Proposals
(F-110)

Create Payment
Proposals
(F-110)

NO

Is Payment Proposal
Correct?

Figure 3.3.2.5A Automatic Outgoing Payments

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 54 of 147

YES

Create
Payment
Output
(F-110)

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Account Payable - Automated Payment (Contd)

Cheque

Payment
Method?

Transfer

Wire

Print Checks

Create Positive
Pay File

Review Check
Register

Create Transfer
File

Transmit EFT
File to the Bank

Receive EFT
confirmation
from bank

Create Wire
File

Transmit Wire
File to the Bank

Receive Wire
confirmaton
from bank

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
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 55 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 56 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

Branches

Rates
(%)

CCUK

0.0
17.5
0.0
0.0
0.0
0.0
16.
7.0
16.0
7.0
16.0
7.0
0.0
0.0
16.0
7.0
16.0
7.0
16.0
7.0
0.0
0.0
17.0
0.0
6.0
0.0
6.0
0.0
7.0
TBD
0.0
6.0

CCGermany

CC PeterB

CCFrance
CCCorp

CCCanada
CCKeystone

256783903.doc
Printed on: 1/9/2015 2:56 PM

SAP Input/
VAT Tax
Codes
V0
V1
V3
V4
V5
V0
V1
V2
E1
E2
E3
E4
E7
V0
V1
V2
E1
E2
E3
E4
E7
V0
V1
I0
I1
U0
U1
PJ
IJ
SJ
I0
I1

Page 57 of 147

Tax Code Description


Exempt from input VAT
Standard input VAT
Delivery of goods in EU
Services within the EU
Subcontracting within EU
Exempt 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
Exempt 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
Exempt from input VAT
Input VAT
Exempt from input tax
Input tax
Exempt from A/P use tax
A/P use tax
A/P GST Exempt,
A/P, GST applicable
Self assessment, GST
Exempt from input tax
Input tax

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

0.0
6.0
0.0
0.0
0.0
0.0
17.0

CCHK
CCWK
CCSZ

U0
U1
V0
J0
J1
J0
J1

Exempt from A/P use tax


A/P use tax
Tax exempt
Exempt from input tax
Input tax
Exempt 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
Code
E
C

Description

Payment Medium

Comments

Cash
Cheques

N/A
Cheque printed in-house or outhouse, and an electronic file with
cheque information (positive-pay
file)

Teletex
Transfer

N/A

Electronic
Funds Transfer

Electronic payment file with


different formats for different
countries:
US ACH format

Cash Payment
The positive-pay file will be
sent to the bank to validate
the printed cheques when
deposited by the vendors.
Manual Payment handed to
bank (usually foreign
currency payment to vendor
who does not have an account
with HSBC)
Electronic payment files will
be sent to HSBC bank via
Hexagon

All other countries need to be


confirmed by users whether
interface directly from SAP to
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 58 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Bank is needed

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 59 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 60 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Payment
Difference for
Vendor /
Customer
Branch
UK
Germany
Keystone
Corp
HK
WK
SZ
France

Currency
GBP
EUR
USD
USD
HKD
RMB
RMB
EUR

Based on Local Currency


Amount
Percentage
Gain
Loss
Gain
Loss
5
5
1
5
5
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

1
1
0
0
0
0
0
0

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Accounts Payable Period

Page 61 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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.
Intercompany Invoice/ Payment - Create non-trade Invoice

Approved
Intercompany
Transaction

FINANCE

Review autogenerated
Intercompany
Payables/
Receivables

Post FI
Document

Create GL
Posting
(Enter Header
Detail)

Enter
Transaction
Details in Co. 1
Line Item 1

Simulate
Posting

Enter
Transaction
Details in Co. 2
Line Item 2

FI document +
Cross Company
document
generated

END

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.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 62 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 63 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

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 Depreciation

Chart of Depreciation Descriptions :

ZHK
ZUS
ZCA
ZCN
ZUK
ZDE
ZFR

HK Chart of Depreciation for AAA


US Chart of Depreciation for AAA
Canada Chart of Depreciation for AAA
China Chart of Depreciation for AAA
UK Chart of Depreciation for AAA
German Chart of Depreciation for AAA
France Chart of Depreciation for AAA

Company code(s)
assigned
5100
1000, 4100
4200
5200*
3100
3300
3400

*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
Depreciation
ZHK

Depreciation areas

Depreciation area description

01
15
30

Book depreciation
Tax depreciation
Group currency depreciation

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 64 of 147

Posting to
G/L
Yes
No
No

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

ZUS

01
15
30
01
15
30
01
15
30
01
15
30
01
15
30
01
15
30

ZCA
ZCN
ZUK
ZDE
ZFR

3.6.3.

Book depreciation
Tax depreciation
Group currency depreciation
Book depreciation
Tax depreciation
Group currency depreciation
Book depreciation
Tax depreciation
Group currency depreciation
Book depreciation
Tax depreciation
Group currency depreciation
Book depreciation
Tax depreciation
Group currency depreciation
Book depreciation
Tax depreciation
Group currency depreciation

Yes
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
No
No

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 Chart of Depreciation
individually such that the company codes assigned to that Chart of Depreciation will not wrongly use the
unwanted Asset Classes.
An asset class could be defined as an 8-character code or less in SAP R/3 system. Since the assets are
generally classified according to the balance sheet G/L account differentiation of the fixed assets, the best
way of defining the asset class coding is to follow the same or similar coding logic of the fix asset G/L
accounts. In the current to-be chart of accounts proposal all the fixed asset related balance sheet accounts
are ranging from 20010000 to 20059999 with differences only in the last 5-digit. So it is suggested that
the asset class is defined as a 5-digit code with the same coding format of the last 5 digits of the
acquisition cost balance sheet account in the G/L.
Addition of new asset class is actually a configuration process which is not supposed to be done by the
users. However, there will be a knowledge transfer to the AAA IT supporting team such that they will be
able to support that after go-live.

3.6.4.

Asset Number Range:

Each asset master record will have a unique master record number for identification in Fixed Asset
Accounting.
The asset master record number is controlled by the asset number ranges. In SAP R/3, the asset number
could be a maximum of 10-character code. The number could be externally assigned or determined
internally by the system during the creation of an asset master record. With externally assigned number,

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 65 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

the format of the asset number could be alpha-numeric. But for internally assigned number, the number
should be pure numeric and is being generated sequentially from a pre-defined number range series.
In AAA Group, an internal numbering system is proposed for asset master record. This is also the best
practice proposed by SAP because this can minimize the numbering maintenance effort and can avoid
duplication of the asset number. Number ranges in Asset Accounting could be asset class dependent.
Different asset classes could have different number ranges such that the asset number itself could serve as
a means for asset class identification. This setting is inline with the current numbering system of asset
records in the legacy system of AAA. About the asset number format, it is proposed that the number is a
pure numeric 10-digit code. The first 3 digits representing the asset class definition and the remaining 7
digits are sequential running numbers. The asset classes and the corresponding number ranges are shown
in the following table:
Asset
Class
10010
10020
10030
10040
10050
10060
10070
10080
10090
10110
10120
10130
10140
10150

Asset Class Descriptions


Automobile/Truck
Plant & Machinery
Computer Hardware
Computer Software
Furniture & Fixture
Fax and Copy Machine
Office Equipment
Leasehold Improvement
Warehouse Equipment
Building
Mould & Tools
Building Improvements
Land Usage Right
Capitalised R&D Cost After AFS (will be
amortized)
Asset Under Construction Capitalizable
Development Cost
Asset Under Construction Construction in
Progress

20010
40010

3.6.5.

Asset No. Range


(From)
101 0000000
102 0000000
103 0000000
104 0000000
105 0000000
106 0000000
107 0000000
108 0000000
109 0000000
111 0000000
112 0000000
113 0000000
114 0000000
115 0000000

Asset No. Range


(To)
101 9999999
102 9999999
103 9999999
104 9999999
105 9999999
106 9999999
107 9999999
108 9999999
109 9999999
111 9999999
112 9999999
113 9999999
114 9999999
115 9999999

201 0000000

201 9999999

401 0000000

401 9999999

Asset Depreciation Methods:

Standard SAP system provides a lot of different standard depreciation methods that can fulfill different
legal requirements in different countries.
Below is a summary of depreciation methods that will be used in different companies within the AAA
Group :
Company 5100 (HK)
Asset Classes
Automobile/Truck

Expected useful
life (month)
80

256783903.doc
Printed on: 1/9/2015 2:56 PM

Book depreciation

Tax depreciation

Straight line

10% / 30% / 60% pool


(TBD)

Page 66 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Plant & Machinery


Computer Hardware
Computer Software
Furniture & Fixture

120
36
36
80

Straight line
Straight line
Straight line
Straight line

Fax and Copy Machine

80

Straight line

Office Equipment

80

Straight line

Leasehold Improvement

36

Straight line

Warehouse Equipment

80

Straight line

Building
Mould & Tools

360
48

Straight line
Straight line

Building Improvements

60

Straight line

Land Usage Right


Capitalised R&D Cost After AFS
(will be amortized)
Asset Under Construction
Capitalizable Development Cost
Asset Under Construction
Construction in Progress

522
24

Straight line
Straight line

Full allowance
Full allowance
Full allowance
10% / 30% / 60% pool
(To be determined)
10% / 30% / 60% pool
(To be determined)
10% / 30% / 60% pool
(To be determined)
10% / 30% / 60% pool
(To be determined)
10% / 30% / 60% pool
(To be determined)
Building allowance
10% / 30% / 60% pool
(To be determined)
10% / 30% / 60% pool
(To be determined)
(To be determined)
N/A

N/A

N/A

N/A

N/A

N/A

N/A

Book depreciation

Tax depreciation

Straight line

Computer Software

Expected useful
life (month)
To be
determined
To be
determined
36

Furniture & Fixture

24

Straight line

Fax and Copy Machine

84

Straight line

Leasehold Improvement

397.2 or 480

Straight line

5 Yr DDB HY
Convention
3 Yr DDB HY
Convention
3 Yr DDB HY
Convention
5 Yr DDB HY
Convention
3 Yr DDB HY
Convention
To be determined

Expected useful
life (month)
12

Book depreciation

Tax depreciation

Straight line

Double declining year


method

Company 1000 and 4100 (US)


Asset Classes
Automobile/Truck
Computer Hardware

Company 4200 (Canada)


Asset Classes
Automobile/Truck

256783903.doc
Printed on: 1/9/2015 2:56 PM

Straight line
Straight line

Page 67 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Computer Hardware

12

Straight line

Computer Software

12

Straight line

Furniture & Fixture

12

Straight line

Fax and Copy Machine

12

Straight line

Leasehold Improvement

12

Straight line

Book depreciation

Tax depreciation

Automobile/Truck

Expected useful
life (month)
60

Straight line

Plant & Machinery

120

Straight line

Computer Hardware

60

Straight line

Computer Software

60

Straight line

Furniture & Fixture

60

Straight line

Fax and Copy Machine

60

Straight line

Office Equipment

60

Straight line

Leasehold Improvement

60

Straight line

Warehouse Equipment

60

Straight line

Building

240

Straight line

Mould & Tools

60

Straight line

Building Improvements

240

Straight line

Straight line with 10%


scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value
Straight line with 10%
scrap value

Book depreciation

Tax depreciation

Computer Hardware

Expected useful
life (month)
36

Straight line

Same as book

Furniture & Fixture

60

Straight line

Same as book

Company 5300 (CCSZ)


Asset Classes

Company 3100 (UK)


Asset Classes

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 68 of 147

Double declining year


method
Double declining year
method
Double declining year
method
Double declining year
method
Double declining year
method

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

200

Straight line

Same as book

Book depreciation

Tax depreciation

Computer Hardware

Expected useful
life (month)
36

Straight line

Same as book

Furniture & Fixture

120

Straight line

Same as book

Office Equipment

Between 36 &
60
180

Straight line

Same as book

Straight line

Same as book

Book depreciation

Tax depreciation

Computer Hardware

Expected useful
life (month)
36

Straight line

Same as book

Furniture & Fixture

120

Straight line

Same as book

Office Equipment

60

Straight line

Same as book

Building

Company 3300 (Germany)


Asset Classes

Goodwill
Company 3400 (France)
Asset Classes

3.6.6.

Asset Master Maintenance:

An asset master record is a record for an individual asset that contains all the relevant information and
control parameters for an asset in Asset Accounting. An asset master record has to be created before any
transaction of an asset could be done. Normally, the first transaction to be done for a fixed asset is the
first acquisition posting. Asset Accounting in SAP R/3 is integrated with the MM module in such a way
that the purchase (i.e. the acquisition posting) could be posted via goods receipt or invoice receipt in MM.
In AAA, asset acquisition will be posted by the invoice verification in the MM modules. To achieve this,
an asset mater record has to be created before the creation of the asset purchase order in MM. Purchases
are also possible without a purchase order. In this case, the approval process will be off-line.
The asset master record will be used as an account assignment in the asset purchase. The asset master
record in AAA is structured as follows:
Tag Pages on Asset Master Record
General

256783903.doc
Printed on: 1/9/2015 2:56 PM

Data
1. Contains general information of the asset such as
descriptions, quantity, serial number and inventory
number which could be printed out from on a barcode
label
2. Contains posting information such as the date of

Page 69 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

capitalization posting and the date of retirement


posting. These dates are updated by the system
automatically by the relevant transaction you posted in
the system
Time-dependent allocation of cost center of which the
depreciation expense will post to. The same asset may
be assigned to different cost centers in different
validity periods of time. (The assignment of a cost
center into a fixed asset record has a validity period.
For example, if an asset originally is belongs to
department 1, you may also change it to department 2
starting from next fiscal year )
Different evaluation groups available for further
classification and grouping of assets for reporting and
analysis purposes
For storage of origin data such as country of origin,
original manufacturer and the vendor you purchase
from. (Origin data is descriptive information only
where you can store more information about the asset
such as country of origin, manufacturer name etc)
Stores all the data relevant for the asset valuation and
depreciation calculation in different books
(depreciation areas) such as depreciation keys,
expected useful life and the depreciation start date.
Depreciation keys and the expected useful life could
be defaulted by the system according to individual
asset classes. The depreciation start date will be
determined and updated by the system according to the
posting date of the first acquisition posting

Time-dependent

Allocation
Origin

Depreciation areas

Linkage Between Asset and Component by PRT:

AAA has a requirement to link the fixed asset of mould and tool with the component it
produces. However, there is no direct system linkage between a fixed asset mater
record and a material master record in MM.
To full-fill the requirement, a work around solution is proposed by using a PP master
data called Production Resource Tool (PRT)

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 70 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Asset

PRT Master
Asset

Routing
PRT

Producti
on Order
Routing

A user field in the asset master record will be used to store the PRT number which is being treated as a
representation of the tooling asset.
The PRT will be assigned to the routing of the component. Later when production order is created for the
component, the PRT record will also be copied into the production order.
From the backflushing transactions posted into the production order, we can have information about the
usage of the tooling such as usage frequency, date of the last usage etc for reporting.
There is no standard report to print out the tooling usage and a customized report will be developed to
meet these requirements.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 71 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.6.7.

Asset Transactions

A ssetA ccounting - A ssetL ifecycle Transaction

Intercom pany A ssetLifecycle


D e fin e T ra n sfe r
D etail .(eg. C om pany
to C om pany; A sset
D etails)
(A B T1N )

Postm issing
A sset
Transactions

Save D ocum ent


(A B T1N )

NO

FIN A N C E

A ssetR etirem ent

D efine A sset
R etirem ent

M onth-E nd A sset
Transactions
C om pleted?

Save D ocum ent

C an R etire A sset
A ) W ith R evenue (F-92)
B )W ithoutR evenue
C )B y scrapping (A B V A N )

D isplay Log
(A FB P)

Y ES

Execute D epreciation
TestR un
(A FA B )

Save D ocum ent


(A FA B )

Enter D epreciation
D etail
(A FA B )

Figure 3.5.8 Asset Transactions

Asset Transactions Document Types :

Standard document types available for the asset transactions are :


Document type
RE

Description
Invoice gross

Usage
General document type for invoice
verification. In asset accounting,
this will be used as the acquisition
posting from MM
AA
Asset Posting
Used in all asset other transactions
AF
Dep. Posting
Used in depreciation posting
The above three document types are the most general ones available from the standard system. Additional
document types could also be added for asset retirements, transfer posting or disposal.
(Note : For details of document types and the corresponding FI document number ranges, please refer to
the FI General Ledger section)

Asset Acquisition

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 72 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

F IN A N C E

A ssetA ccounting - Post A ssetExternalA cquisition

C reate A sset
M aster
A S01

A sset
R equest
A pproved

PU R C H A SE

C reate Purchase
O rder

Purchase O rder
A pproved?

Y ES

G oods R eceipt to
m atch Purchase O rder

NO

Pending for
Further A dvice
upon discussion

Invoice R eceipt to
m atch Purchase O rder/
Post A sset External
A cquisition

Figure 3.5.8.2. Asset Acquisition

With the integration between Asset Accounting System and the Material Management modules, the
posting of acquisition of fix asset is being posted in MM via a transaction called Invoice Verification (for
details of the transactions, please refer to the FI A/P section).
In general, the posting of the invoice verification for a fixed asset PO will be as follows
Dr.
Fixed Asset Acquisition Cost
Cr. Vendor (Accounts payable)
After posting each asset purchase invoice in MM, in parallel to the general ledger document, an asset
accounting document will also be generated to store the detailed information of the transaction in asset
accounting. Besides, the posting date of the document will be copied into the asset master as the
capitalization date and the depreciation start date of each depreciation area will also be determined and
updated in the depreciation area data tag page
Asset acquisition posting could also be done without PO from the MM module. Posting could be done in
FI posting only

Asset Value and Depreciation Simulation

Once an acquisition is posted into an asset master record, the Asset Accounting System will be able to show
the current net book value and the depreciation projection (projection of future depreciation amount based on
the current depreciation method and life) of that asset. To check this kind of information, display the asset
master record or call up a report called Asset Explorer. The most important information available for asset
value display or Asset Explorer is as follows:

Current net book value of each depreciation areas (i.e. Book, Tax, or Group)
Depreciation simulation (projection) by period and by fiscal year
Actual posted depreciation amount by period

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 73 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

However, the simulation of depreciation is only available for current assets of which real acquisitions have been
posted. Depreciation simulation for possible future assets is only available in Investment Management modules
in SAP.
In AAA, what ifanalysis is required to provide a simulation on the depreciation changes if the depreciation
method or the expected useful life is changed. However such changes made in the asset master records are
generally the actual changes which will have actual posting impact in G/L. To provide a workaround solution
for the what if analysis, it is suggested that an additional depreciation area (i.e, depreciation book) will be added
to capture the changes and provide the depreciation amount after the changes. This additional book will be
defined as statistical only and no posting will be generated to the G/L

Asset Disposal Sales to a Customer

Sales of an asset to a customer is one of the possible scenarios of asset disposal in AAA. This transaction
can be posted in Asset Accounting. A customer master record in SAP is needed before this transaction
could be done.
Information that is required to be input for this transaction is the asset being sold, customer master, the
sales proceed amount and the revenue G/L account of the transaction. The system will automatically
generate the required postings and deducted the net book value of the asset being sold.
Supposed an asset with historical cost $1,000 and accumulated depreciation of $100 is being sold to a
customer at a price of $1,100, the posting entries will be as follows:
Dr. Customer account (A/R)
Cr. Revenue for asset disposal
Cr. Fix asset acquisition cost
Dr. Accumulated depreciation
Dr. Clearing account for asset disposal
Cr. Gain/loss of fixed asset disposal

1,100
1,1001,000100
1,100
200-

The system will calculated the net P&L of the transaction and post the amount into a gain/loss of fixed
asset disposal account. The posting date of the retirement posting will also be updated into the field
deactivation date in the asset master as the retirement date.

Asset Disposal Scrap without Revenue

Instead of selling, an asset could be disposed as a scrap. In this case, no revenue is expected and a loss
will be realised in the P&L if the fixed asset being scrapped still carries a net book value
Posting of asset scrapping is also a standard feature in SAP Asset Accounting.
For the same asset with historical cost $1,000 and accumulated depreciation of $100, the posting of the
scrapping will be as follows:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 74 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Cr. Fix asset acquisition cost


Dr. Accumulated depreciation
Cr. Gain/loss of fixed asset disposal

1,000100
900

Asset Transfer within a Company Reclassification

The net book value of an existing asset master record could be transferred to another asset within the
same company. The transaction could be used in the following scenarios:
Reclassify an existing asset to a new class or to correct an error
Transfer an asset to a new one with the same class. This may be necessary to execute the change
of the remaining useful life of an asset but still spread the net book value evenly throughout the
remaining life without allowing the system to catch up the postings of the missing or extra
depreciation of the past periods
For an asset with historical cost $1,000 and accumulated depreciation of $100, the posting of the intracompany transfer posting will be follows:
Cr. Fix asset acquisition cost (old asset)
Dr. Accumulated depreciation (old asset)
Dr. Fix asset acquisition cost (new asset)
Cr. Accumulated depreciation (new asset)

1,000100
1,000
100-

The old asset being transferred will become a retired asset and the transfer posting date will be updated as
the retirement date in the asset master record. For the new receiving asset, the transfer will be the same as
if it is being acquired. The transfer posting date will be used as the capitalization date.

Asset Under Construction (AUC)

Asset under construction in SAP is used to capture the expenditure paid out for assets purchased with
multiple payment instalments or for expenditure of an asset being produced or constructed internally. In
both cases, the depreciation of the amount paid out or the cost incurred during the construction phase is
normally started after the final payment is made or the asset construction is completed. The old and the
new asset will be linked together by the settlement posting document
In AAA, asset under construction is used in the following scenarios:
1. To capture the capitalizable portion of the R&D development cost
2. To capture the expenditure incurred in building construction in progress
3.6.7.1.1.

Transaction with Asset Under Construction

Normally, the transactions that could be associated with an asset under construction
record could be exactly the same as other normal assets described in previous sections.
For example, an acquisition could be posted to an asset under construction from purchase
order. The only difference is that all the costs being posted into an asset under
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 75 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

construction will not be depreciated because the asset master record of an AUC will not
contain any depreciation relevant settings.
Other than the normal acquisition postings, costs could also be posted into an AUC by
means of settlement of other CO objects. In the case of R&D development, the costs
incurred in the development will still be posted into an Internal Order (which is a cost
object in the CO module) as P&L items. The capitalizable portion of the costs will
be capitalized into an AUC (which is a balance sheet item) by a settlement process in
Internal Order.

3.6.7.1.2.

Settlement of AUC

When the asset under construction has come to a stage where depreciation should start, a
settlement should be done to that AUC record in order to settle the amount captured in the
AUC to a real asset master record which carries the required depreciation terms.
Unlike the settlement process for CO cost objects which is normally a periodic (usually
month end) processing, settlement of AUC is not part of a month end processing that has
to be done every month. The settlement of AUC actually is done on an ad hoc basis or at
any time where necessary. Particularly, for the case of R&D development cost in AAA,
the settlement of AUC will not be done until the Available For Shipment (AFS) date is
reached.
Settlement of AUC costs could be done in line items level where you define the
settlement receivers (i.e. the real asset number) in each line items level. Alternatively, the
whole total cost within an AUC record could settled to a single receiver asset or
distributed to several assets by a percentage ratio.

Month End Processing Depreciation Run

The depreciation calculation and posting of each asset is done periodically as a batch job
during month end process. Virtually speaking, there is no format month end closing
procedure required in asset accounting. The depreciation run will be the only regular
month end job to be done. The month end batch job is processed in the background.
The system will calculate the depreciation amount based on the depreciation terms (i.e.
the depreciation methods, useful life, depreciation start date etc) specified in each of the
asset master and post the result to the general ledger. The general posting will be as
follows:
Dr. Depreciation expense

Cr. Accumulated depreciation

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 76 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Note that the above posting to G/L will be done in a summary level by G/L accounts and
cost center levels because the depreciation expense has to be charged to cost center in
CO. However, the detailed depreciation amount of each asset will also be stored in Asset
Accounting such that each unique asset master record will also have its unique posted
depreciation amount. Besides, after each depreciation run, the system will issue a report
which list out the depreciation posting amount of each individual assets as a record. This
is advised that this report should be kept as an additional audit trail.

Year End Processing

At the end of each fiscal year, you are required to do a year end processing in Fixed Asset
Accounting. The year end closing is (i.e. fiscal year change) is just to open the next fiscal
year and at the same time close the previous fiscal year in Asset Accounting.
SAP provides a programme with easy user interface to do the year end closing job. It is
advised that the job should be done in a background mode and the system will convert all
the asset master records from the previous fiscal year to the next year.

3.7.

Cost Center Accounting


Cost Center Accounting provides the mechanism to collect and report operating activity within
organizational units of a company. At AAA, these units are represented by departments within
each Reporting Unit. SAP cost centers have been arranged in a hierarchy to reflect AAAs
department structure that facilitates internal reporting and accountability. Each cost center
generally represents a department or unit that is the responsibility of a manager. Managers can
then monitor the performance of their departments by accessing reports on their cost centers.
Costs in a cost center can be easily allocated to other cost centers or different cost units within the
system. Cost allocations are implemented though allocation cycles where the sending and
receiving cost units, and the allocation basis for cost distribution are user defined
The diagram below shows how financial postings get booked to a cost center through a
transaction in the Financial module. When the expense is posted, a cost center in the Controlling
module may be included as the department responsible for incurring the expense.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 77 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

G L/FI
Posting
FI D ocum ent
H eader

FI docum entLine Item s


FI Posting O nly

Integration to
C O (C ontrolling O nly

B alance Sheet Item

Enter
H eader
D etail

Enter FI Line Item

Enter
- G /L A ccount
- A m ount
- Text(if needed)

Is ita B /S
item ?

Y ES

FIN A N C E

- C om pany C ode
- Posting/ D ocum ent D ate
- R eference no.
- C urrency/ rate

Enter another
Line item

EN D

P& L
Item

NO

R equired

A .O verhead C ost
B .C ostR educing R evenue
C .O perating Sale
D .Sales R eduction

C ostC enter
Or
R ealInternal
O rder

Enter
- G /L A ccount
- A m ount
- Text(if needed)

W hich C O object
to assign?

C
D

O ptional
Statistical
Internal
O rder

C O PA Profit
Segm ent

Figuring 3.6 Postings in FI and CO

The main cost center business transactions are:

Primary cost postings these are postings that occur in CO when expense accounts are posted to
the G/L in the FI module
Actual cost allocations these are the distribution of postings from one cost center (the sender) to
another or a group of cost centers (the receiver). The distribution could be to other receiver
objects besides cost centers (such as an internal order)
Cost center planning (Budgeting) - this is the process of entering budget figures for department
expenses
Plan cost allocations (distribution / assessment) - this is the same as the actual cost allocation but
the figures being distributed are the budget figures rather than the actual postings

3.7.1.

Cost Center Structure

Cost Center Numbering Convention


The first 2 digits represent the first two digits of Company code, e.g. 51 for
51-79100
CCHK with company code 5100
The next digit represent the 5 major functional grouping which are
51-79100
Administration
, Engineering, being 7
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 78 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Sales, being 6
Supply Chain being 3
, Production being 4
The next 2 digits represent the sub groupings of the functional groups of
above

51-79100

The last 2 digits represent a sequential number

51-79100

Cost Center Grouping Number Convection


The first 4 digits represent the Company Code
The next digit represent the 5 major functional grouping which are
Administration being 7
Engineering, being 6
Sales being 5
Supply Chain being 3
Production being 4

5100-791

5100-791

The next 2 digits represent the sub groupings of the functional groups of
above

5100-791

In addition the European cost centers will be added after the Design Document stage. These cost
centers will be included in France, UK and Germanys Administration, Sales and Supply Chain
functional groups

3.7.2.

Statistical Key Figures

Statistical key figures serve as a basis for internal allocations and as references in the key figure
analysis framework. Statistical key figures can be used for internal cost allocations, and can be
defined as either fixed values or totals values. There are two major types of allocation in SAP:

Distribution
Assessment

Distribution is the process of cost allocation used to allocate primary costs of cost center using
the original primary cost elements. In this method, the costs being allocated will be retained into
the original cost elements. On the other hand allocation by assessment could be applied to both
primary and secondary costs using a secondary assessment cost element which is different from
the original cost elements. In this case, the costs being allocated will be posted to a secondary
assessment cost element.
In AAA Bbb, the statistical key figures are defined for assessment purpose:
The statistical key figures used are:
Employees
Man-hours

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 79 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Floor space
Quantity by Finish Goods

3.7.3.

Overhead Allocation

Costs are initially posted to a 'common' (or shared) cost center during the month, and at the month
end these costs are allocated to respective cost centers based on the allocation basis. Costs can be
allocated via reposting or allocation cycle. AAA will re-assign shared costs mainly though
allocation cycles.
Allocations of costs to the respective cost centers are done based on i.e. head-counts, transaction
volumes, percentage, etc.

The following are defined in the allocation cycle:


Sender cost center
Receiving cost center
Allocation basis (floor space, percentage etc)
Sender primary cost element
Receiving secondary cost element (if use assessment allocation method)

3.7.4.

Re-posting of cost

Incorrect posting of costs and revenues can be corrected with the re-posting function in
cost center accounting. This enables users to amend specific line items from CO
documents and provide management with a clear audit trail when reviewing adjusted CO
postings.
3.7.5.

Period End-Closing

Period end closing process is a monthly activity in CO and it refers to the following
areas:

Execution of allocation cycles to apportion cost from common or shared cost centers to final
cost centers
Generation of monthly reports

The following tasks have to be executed at every period end closing:

Ensure postings are completed from sub modules and sub modules have closed
Execute all the active allocation cycles

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 80 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.8.

Check key figures to sub modules (i.e. total Cost Center Accounting figures to agree to total
G/L expense accounts etc)
Generate monthly reports
Lock current posting period for controlling

Internal Order
Internal orders are used to monitor overhead costs incurred for a specific event, project or
activity. It can be used for a restricted period when executing a job, or for long-term monitoring
of portions of overhead costs. Internal Orders are company code dependent. Internal order
groups can be created for cross-company reporting.
Overhead cost orders will be used to collect actual costs incurred. This allows costs to be
monitored continuously. The overhead costs assigned to the overhead cost orders are settled (in
full) as costs to other cost collectors. This is generally on the periodic basis, at month-end.

3.8.1.

Order Master Data Creation

For AAA Bbb HK internal orders will be used to keep track of Project costs. In addition,
internal orders will be used to keep track of the legal costs associated to which law firm
and cases for AAA Bbb Corporation.
The order type determines the following:
The Order Category
Orders have different purposes in the R/3 System, for example they can be used to monitor R&D
expenses that can be settled to fixed, monitor short term or long term overhead expenses. The
structure and function of an order, as well as the transactions you use to process it, all depend on
the order category.
Numbering Assignment
You must assign each order type to a number range. Number assignment takes place centrally for
all orders of this order type.
Control Indicator
This allows you to change the below control indicator centrally for all orders of this order type.
Commitments Management

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 81 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

For each order type, you must specify whether you want to use commitments
management (contractual or scheduled commitment that is not yet reflected in Financial
Accounting but will lead to actual expenditures in the future).
For example when entering into contract such as a Purchase Order, the commitment cost
of this PO can be reflected in the internal order and this amount will be reduced every
time a goods receipt is done based on this PO. This allows scheduled costs that have not
impacted financial accounting to be shown to user.
If service PO is used then commitment management can be applied to this as well.
Integrated Planning
If you want to update planned activity input directly on the sending cost center, you can
activate integrated planning as a default value. When required, you can change the
indicator in the order master data.
Status Management
An order can pass through many statuses. The status controls, for example, which business
transactions are allowed on the order. For example, the system will not allow any posting into an
order that has not released yet
In additions to R&D expenditure and legal expenses, there are some other possible order types for other types of
expenditure such as expatriate expense, travelling expense, trade show etc. More order types could be defined in
the detailed design phase.

3.8.2.

Order Actual Transaction Posting

Currently, at AAA, two transactions types have been identified for Orders:
1. Costs Associated to Projects
These are project expenses which management wishes to capture separately from other
expenses. Certain expenses will be capitalized while others will be expensed off.
2. Legal Cost by Law Firm and Case
These are legal expenses which management wishes to capture separately. Each order will
represent the Law firm and specific Cases the costs are associated to.
More order types are to be defined later.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 82 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.8.3.

Month End Process

Set t l i ng Cost s i n an I nt er nal


D Scenar i o

Or der - - R &

R & D

Ent er AUC num


ber
as r ecei ver i n
set t l em
ent r ul e

F I NANCE

Goods Recei pt /
I nvoi ce
Recei pt ( wi t h
I / O assi gned)
Expense
Val ue Post ed
t o I nt er nal
Or der
FI Docum
ent
Pr ocessi ng
( wi t h I / O
assi gned)

Mont h End
Set t l em
ent
t o AUC
NO
Af t er
fi r st
Shi pm
ent

YES

Set t l em
ent
t o a r eal
Asset s

Figure 3.7.3 Settlement in an Internal Order

For Internal Orders that capture Legal Costs by law firms and case, there is no settlement needed.
For Internal Order that captures Project expenses, there will be a need to settle the capitalized
expenses part to an Asset Under Construction (AUC) on a monthly basis, and the expenses
portion will be settled to a P&L account or cost object. Once the project is completed and all
costs have been settled to AUC, the status of the internal order will be closed and no further
posting can be made. Further settlement will be needed to a Fixed Asset (with an intangible asset
class) in order to amortize the cost over a 24 month period using straight line method.
In order to help the users to separate the total project costs into the portion to be capitalized and
the portion to be expensed more easily, the costs items (i.e. the expense accounts) will be grouped
into these two categories by means of a parameter called source structure assignment used in
the settlement rule of the internal order. When the settlement rule is defined, the user can assign
some costs to be settled to a cost center, and other costs that are tagged as capitalized to be settled
to an Asset Under Construction (AUC).

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 83 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.9.

Product Costing
3.9.1.

Logistics Master Data

The logistics master data required for product costing and the usage is summarized as follows:
Logistics Master data

Major Usage

Material master (MRP


views)

Provide data of procurement source (such as internal


production, external procurement or subcontracting) for
product cost calculation
Provide financial data such as inventory price of raw
materials and the consumption G/L account (through
account determination valuation class)

Material master
(Accounting view)
Material master (Costing
view)
Routing master
BOM master
Purchasing info record of
raw material purchase
Purchasing info record of
subcontracting

Provide costing calculation control parameters such as overhead


group, origin group etc. (will be discussed in more details in later
sections)
Provide standard production time (SPT) that is relevant for labour
and production overhead calculation
Provide list of raw materials and their usage quantities for the
production of the product
Provide purchasing price of raw materials for raw material cost
calculation when the inventory price is not yet available in the
material master
Provide subcontracting labour cost for subcontracting materials

(For detailed definitions and function of the above master data, please refer to the design
documentation of the relevant logistics modules)

3.9.2.

CO Master Data

Cost Center

A cost center is used to represent a department in AAA. The cost centers of the
production departments will be used in product costing. Activity Type prices (i.e. labour
and production overhead rates) are planned at each production department cost centers
and each of the production department cost centers will be assigned to a work center in
PP such that the activity prices could be assigned to work center for labour and overhead
cost calculation.

Activity Types

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 84 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Activity types classify the activities produced in the cost centers within a controlling
area. For production related cost centers, activity types are generally referring to the
production activities. Using the activity types, we can calculate activity prices by cost
budgeting of activity-dependent cost items. The activity prices will be used to calculate
the production labour and overhead costs to be absorbed into inventory of the products
produced.
The production related activity types in AAA are listed below :
Activity type

Description

Activity unit

CAMLAB
CAMAOH
CAMLOH
CAMOH
PAKLAB
PAKAOH
PAKLOH
PAKOH
SKCLAB
SKCAOH
SKCLOH
SKCOH

Labour cost for bulk bbb


Assembly labour overhead for bulk bbb
Component labour overhead for bulk bbb

Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)
Hour (H)

Other overhead for bulk bbb


Labour cost for packaging
Assembly labour overhead for packaging
Component labour overhead for packaging
Other overhead for packaging
Labour cost for silkscreen
Assembly labour overhead for silkscreen
Component labour overhead for silkscreen
Other overhead for silkscreen

Origin Groups

Origin groups is a parameter in the costing view of a material master. If offers an


additional dimension to sub-divide or classify raw materials into different categories for
reporting and analysis purposes in product costing.
In AAA, the origin groups will be defined as a more detailed nature classification of raw
materials and components such that the material costs could be further sub-divided into
different natures for analysis. An appropriate value of the origin group must be assigned
to the Origin Group field in the costing view of the material master.
The origin groups defined in AAA are :
Origin group code

Description

B1
B2
B3
B4
B5
P1

Electronic parts in bulk bbb


Plastics parts in bulk bbb
Metal parts in bulk bbb
Lens parts in bulk bbb
Other parts in bulk bbb
Raw materials for packaging

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 85 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

S1

Raw materials for silkscreen

Overhead group

Overhead group is another parameter that is being entered into the costing view in the
material master data. Unlike the origin group which is generally applied to raw materials,
the overhead group is usually used in semi-finished or finished goods for control of
production overhead calculation.
In AAA, 2 overhead groups will be defined to classify products into two separate
categories according to the need of production royalty calculation. One group represents
production royalty is needed and the other group represents production royalty is not
required. The overhead group is assumed to be entered into the material master for
finished goods products only because the royalty will only be calculated on finished
goods level.
The two overhead groups to be defined are:
Overhead group

Description

ROY0
ROY1

No production royalty
Production royalty calculation required

Different overhead groups represent different products groups which are subject to
different charge rate of royalty. Therefore, number the overhead group required for
royalty calculation could be expanded depending on the detailed requirements

Percentage Overhead Keys

A percentage overhead key is a key where you can specify the conditions in percentage
rates for overhead allocation to the product cost of a product.
You could have a flexibility to define different percentage rates with different overhead
keys. In AAA, the major need of defining different overhead keys to separate the
overheard allocation into three different categories namely bulk bbb, packaging and
silkscreen.
The followings is the list of overhead keys to be defined in AAA:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 86 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Percentage
overhead key
ZMO1

Description

Calculation base to be applied

Material overhead for bulk bbb

ZLO1
ZMO2

Labour overhead for bulk bbb

ZLO2
ZMO3

Labour overhead for silkscreen


Material overhead for packaging

ZLO3

Labour overhead for packaging

All raw material costs for bulk


bbb
All labour costs for bulk bbb
All raw materials cost for
silkscreen
All labour costs for silkscreen
All raw materials costs for
packaging
All labour costs for packaging

Material overhead for


silkscreen

Quantity Overhead Keys

A quantity overhead key is a key where you can specify the conditions of overhead
allocation in terms of a fixed amount per unit of quantity.
In AAA, the major usage of the quantity overhead key is for definition of production
royalty rate which is a fixed amount applied to different products.
In addition to royalty, quantity overhead keys will also be used in the cost estimate
calculation in Net Billing because some of the cost items in Net Billing also require
application of a fixed amount rate to the product cost.
The preliminary design of the quantity overhead keys to be defined is as follows :
Quantity
overhead key
ZR1

Description

Calculation base to be applied

Production royalty

ZNB1

Consumption VAT for testing


battery (Net Billing only)
Consumption VAT for testing
film (Net Billing only)

Finished goods production output


quantity
Finished goods production output
quantity
Finished goods production output
quantity

ZNB2

Costing Variants

A costing variant is a collection of different control parameters of product cost


calculation. The major control is the logic and pricing strategy of the different costing
components such as materials cost, activity prices (SPT costs), subcontracting price and
general overhead allocation.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 87 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Three different major costing variants will be defined in AAA:


Standard cost estimates calculation for material valuation (i.e. cost estimates
calculation for material master standard price update)
Cost estimate calculation for Net Billing
Cost estimate calculation for other Request for Quotation (RFQ) purposes
Pricing control of costing variant for material valuation :
Costing items

Pricing strategy priority sequence

Material cost

1. Inventory valuation price from accounting view of


material master
2. Effective price taken from purchasing info record

Activity price

Standard activity rates for the year

Subcontractin
g cost
General
overhead
allocation

Effective price from subcontracting purchasing info


record
Percentage overhead keys and quantity overhead
keys for royalty

Additional
control

Planning
version 0

Pricing control of costing variant for Net Billing:


Costing items

Pricing strategy priority sequence

Material cost

1. Inventory valuation price from accounting view


of material master
2. Effective price taken from purchasing info
record
(The above strategy is just a preliminary
suggestion. Wilson Yuen and Stanley Wan will
have more detailed discussions on that to finalised
the logic)

Activity price

Standard activity rates for the year

Subcontracting
cost
General
overhead
allocation

Effective price from subcontracting purchasing


info record
Percentage overhead keys and quantity overhead
keys for Net Billing

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 88 of 147

Additional
control

A planning
version
different
from 0 such
that different
standard
rates could
be applied

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Pricing control of costing variant for RFQ:


Costing items

Pricing strategy priority sequence

Material cost

1. Plan price 1 from material master (this price is to


be maintained manually by users on selective
materials)
2. Inventory valuation price from accounting view of
material master
3. Effective price taken from purchasing info record

Activity price

Standard activity rates for the year

Subcontractin
g cost
General
overhead
allocation

Effective price from subcontracting purchasing info


record
Percentage overhead keys and quantity overhead
keys for royalty

Additional
control

Planning
version 0

The source of the pricing will be kept in each product cost estimate as an audit trail.

3.9.3.
Approaches

Finished Goods Inventory in Production Plant 5100

Valuation at moving average price per batch (FIFO batch valuation)


A new batch number will be generated for each production order (work order)
producing the finished product
Each batch will have a unique material cost
The material cost of a batch is calculated from semi-finished goods and raw materials
that are directly constituting to the finished product according to the BOM

Summary of Product Cost

Semi-finished Goods Inventory in Production Plant 5100

Valuation at standard price updated from standard cost estimates


All inventory of each semi-finished product will be valuated the same (at the defined
standard cost)
The standard cost can be updated either: 1) manually, or 2) automatically from the
cost roll-up (can be using weighted average) of the lower levels of the BOM and can
be selectively updated only for certain semi-finished products.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 89 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Re-valuation of existing inventories for semi-finished product will happen whenever


the standard cost is updated. The gain or loss will post to the P/L accounts

Raw materials will be valuated for each batch of the receipts of purchase using the
purchase order price.
The batches of raw materials will be issued to production orders at FIFO.
No re-valuation of raw materials will be required.

Raw Materials Inventory in Production Plant 5100

All Inventory in Branches

Inventory will be valuated for each batch of the receipts of STO using the STO price
(transfer prices plus the landed costs).
The batches of goods will be delivered to customers at FIFO.
No re-valuation of inventory will happen.

3.9.4.

Activity type prices planning

The activity type prices in AAA are the standard labour and overhead rates which will be applied
to the standard production time to calculate the absorption of standard labour and overhead cost.
In AAA, the standard rates are being calculated in the yearly budget and the rates will be applied
for the whole year. In SAP, the same thing is being done in cost center planning.
In cost center planning, the budget of activity type dependent costs (i.e. production related labour
and overhead costs will be entered into each production cost centers). On the other hand, users
have also to plan the budgeted activity quantities and enter the budget into each production cost
centers respectively. After that, users could run an activity price calculation programme to
calculate the related activity price per unit of activity quantity.
The planning data could be entered as a yearly total figures or be broken down into different
monthly total, depending on the actual needs of the user when doing the budgeting.
This activity has to be done before you can calculate the correct product cost estimate.

3.9.5.
Maintenance

256783903.doc
Printed on: 1/9/2015 2:56 PM

Percentage Overhead Rates

Page 90 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

In addition to the activity type prices, the product costing users in AAA have to maintain the
percentage overhead as well such that the general overhead could be allocated into the product
cost by the desired percentage rates.
There is no standard system function in SAP R/3 to help the user to calculate the percentage rates.
Users have to come up with the percentages outside the system and then enter the rates for each
percentage overhead keys. There is a validity period of each rate values. That means users could
enter a monthly or yearly percentage rate by maintaining different validity period.
This activity has to be done before you can calculate the correct product cost estimate.

3.9.6.
Maintenance

Quantity Overhead Rates

The maintenance procedure of quantity overhead rates is very similar to the percentage overhead.
The major difference is that the rate being entered for quantity overhead is a dollar amount value
per unit of quantity instead of a percentage rate. Similar to percentage overhead, there is a userdefinable validity period for each amount rates.
This activity has to be done before you can calculate the correct product cost estimate.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 91 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Pr oduct Costi ng -

Pr ocess Over head Rat e, Act i vi t y Rate f or t he next peri od

Enter budget ed
cost s of the cost
el em
ent s of the
act i vi t y types i n
Cost Cent er
Pl anni ng

Ent er producti on
over head r at es i nt o
t he system

Ent er budget ed
quanti t y of the
act i vi t i es i n Cost
Cent er Pl anni ng

<Funct i on>

Run act i vi t y
pri ces
cal cul at i on

Act i vi t y pr i ces
cal cul at ed by
t he syst em
Cal cul ate
standar d
cost

3.9.7.

Cost Estimate Calculation

This is the process for calculating a product cost of a product. You will have to calculate a cost
estimate of a product in the following major scenarios:
1. Calculation of the standard production cost estimate of a new product and use the
standard cost estimate as the standard price for future inventory valuation
2. Calculation of the new standard cost estimate of an old product if you want to revaluate
that inventory valuation price of that product
3. Calculation of a new standard cost estimate of a product for purposes other than
inventory valuation (such as for Net Billing and other quotation reference or other
purposes)
In scenario 1 and 2 above, you should use the costing variant desired for calculation of standard
price for inventory valuation to process your cost estimate calculation. You could also calculate
different versions of cost estimates for other purposes. However, only one version (version 01)
could be updated into material master standard price as the inventory valuation price. If you have
really calculated different versions of costing for the same materials, they will be kept in the
system unless being deleted or overwritten by a new calculation of the same version.
In scenario 3, you should use the costing variant desired for Net Billing calculation because the
calculation logic and the standard rates required will be different from the normal inventory cost
calculation. Again, you could calculate and save different versions of costs. But in this case, all
versions cannot be updated into the material master for inventory valuation.
Major difference of the calculation logic in Net Billing could be summarized as follows:
Cost items
Assembly labour

256783903.doc
Printed on: 1/9/2015 2:56 PM

Calculation
Standard assembly hours X hourly
rate specific to Kodak

Page 92 of 147

Major difference
Standard rate will be different from
inventory valuation rate from a

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Consumption of VAT for testing


batteries

Fixed amount per unit of product

Consumption of VAT for testing


film

Fixed amount per unit of product

All part costs

Summation of BOM item part costs

different planning version


Fixed amount based on quantity
overhead. This item does not exist
in inventory valuation
Fixed amount based on quantity
overhead. This item does not exist
in inventory valuation
A specific set of exchange rates is
being used to convert the part prices
into USD

The calculation logic for all other cost items will be the same as the inventory valuation
calculation
Two processing options are available for cost estimates calculation, individual processing or mass
processing using a tool called Costing Run. In both cases, you could choose to do the costing
calculation for selective materials only.

3.9.8.
Standard Price Update from
Standard Cost Estimate Mark & Release
Mark and release are two technical steps to be done in SAP product costing to update your
standard cost estimate into the standard price of the material master for inventory valuation. That
means the steps are only required for inventory standard price update. Cost estimates that are
used for other purposes are not required to do these two processes.
From inventory valuation points of views, the inventory valuation will only be effective after the
standard cost estimate has been marked and released to the material master. That means even if
you have calculated a new standard cost estimate in product costing of an old product, the old
product will not be revaluated if you have not yet marked and released the new cost into material
master.

3.9.9.
Single Use Bbb (SUC)

Standard Cost Estimates for

In AAA, the single use bbb could be produced from newly produced components (virgin version)
or recycle components (recycle version). There will be two BOMs for every single use bbb
model, one BOM is for virgin production the other is for recycle production.
When calculating the standard cost of SUC, according to the current practice, AAA CCHK
Finance will define a percentage ratio mix of the two BOMs to come up with a single mixed
standard price for the SUC. This approach is also a standard feature in SAP R/3 product costing
system called Mixed Costing.
Mixed costing allows you to update a mixed standard price from different production alternative
BOMs. You have to define a percentage mixing ratios of the different production alternatives and
the system will mix the prices of the different production alternatives by the mixing ratio to come

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 93 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

up with a single weighted average standard price. (The mix is controlled by CCHK Finance. To
change the mix in the system, change the system mix ratio, then re-calculate the new price)

3.9.10.
Products

Product Cost Estimates for New

In AAA, the development of a new product consist of many different phases. At the early stage, a
material number may not be available for the new product. But AAA finance still needs to come
up with an early estimation of product cost of the new product. In SAP, this process could be
done via Reference and Simulation Costing.
The detailed requirements and the solution of this issue will be defined in the detailed design
phase.

Product Costing - Process Standard Cost Estimates for the next period
Be ginning of the next
month

From
B

Current month
Calculate
standard cost
estimates
individually
(CK1 1N)

Release
standard cost
estimates
individually
(CK24)

Mark standard
cost estimates
individually
(CK24)

Individual

F IN A N C E

No
Individual
material/mass
processing?

Yes
Error in cost
calculation?

Costing run

Mass Calculation
by costing run
(CK40N) for

Sent error
me ssages to
p roduction/MIS
department for
corrections

No
Download
standard cost
estimates with
costing status
"KA"

Download
standard cost
estimates with
costing status
"VO"

Mark standard
cost e stimates
(CK40N)

End

Rele ase
standard cost
estimates
(CK40N)

3.9.11.
Production Order Processing for
Semi-finished Goods
Production order of semi-finished goods are used to manage the production of nonfinished goods components (such as plastic components) or sub-assemblies (such as
PCBA or bulk bbb). All such materials are being regarded as WIP in AAAs terminology

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 94 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Raw material consumption at backflushing

Raw material costs are being posted and captured into the production order by a goods
issue posting. According to the to-be design in PP, the goods issue posting will be done
automatically at backflushing. The system will automatically consume the raw materials
to the production according to the usage quantity defined in production BOM. Suppose
$100 of raw material cost is consumed in the production order, the accounting posting
will be as follows :
Cr. Raw material inventory
Dr. Raw material consumed

100100

The raw material consumption cost will be posted to P&L and captured into the
production order

Labour and production overhead cost allocation

In addition to raw material consumption, the production time consumed in the production
order will also be entered during backflushing entries. Suppose the production time
being entered is 10 hour and the standard rate for labour and overhead are $1/hr and $2/hr
respectively, the labour and overhead cost being allocated into the production order will
be $10.00 and $20.00 respectively. The posting will be as follows
Dr. Labour cost (to production order)
Cr. Labour cost absorption (from cost center)
10Dr. Overhead cost (to production order)
20
Cr. Overhead cost absorption (from cost center) 20-

10

All the above postings are pure CO postings (i.e. statistical postings in CO only) using
secondary cost elements which does not have any posting effect in the general ledger.
But the implication in CO is that $10 and $20 labour and overhead costs are being
charged from the production cost center to the production order.

Absorption of Production Cost to Inventory at Goods Receipt

When the production of certain units of the semi-finished goods is completed, a goods
receipt should be done to post the completed units back to the inventory pool for other
stages of production. This transaction will also be done automatically by means of
backflushing entries. In other words, the backflushing entries will post the consumption
of raw materials, production time being charged to the production order and the goods
receipt of the completed units at the same time. (Raw materials should be issued at FIFO.
But for semi-finished goods, only the standard cost is used)
During each goods receipt posting, the amount of inventory of the semi-finished goods
being received will be posted to inventory account at the standard price which have
already included the raw material cost, labour and production overhead, and the general
percentage overhead (calculated from standard cost estimates).

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 95 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Suppose the standard price of the semi-finished goods is $129.00 which includes $90 of
standard raw material cost, $10 of standard labour cost, $20 of standard production
overhead cost, and $9 of general overall cost (10% of the total standard raw material
cost), the goods receipt posting will be as follows :
Dr. Semi-finished goods inventory
Cr. Factory output from production

129
129-

The credit posting is a P&L item which capitalizes standard cost amount of $129.00 from
the P&L in the production order to the inventory. In other words, the WIP inventory of
the semi-finished goods which is being valuated at the standard price of $129.00 has also
included the absorption of the standard labour cost, the standard overhead cost and the
general overhead cost.

Month End Processing General Overhead Allocation

The percentage general overhead allocation to production order will be done as part of
the month end procedure for production orders.
Continue with our previous example of the production order of which $100 of actual raw
material cost has been posted and general overhead rate is 10%. That means the general
overhead being allocated to the production order will be $10.00. The posting will be as
follows :
Dr. General overhead cost (to production order)
10
Cr. General overhead cost absorption (from cost center) 10Similar to the labour and production overhead cost postings, the above postings are CO
postings only which have no effect in the general ledger.

Month End Processing WIP Calculation

After finishing the general overhead allocation process, all the cost capturing postings of
the production order in that period could be treated as completed. The next step to be
done in the overall month end procedure will be WIP calculation.
With our existing example, the cost items posted into the order are as follows :
Raw material costs
100
Labour cost
10
Production overhead
20
General overhead
10
Factory output
129------------------------------------------Total net P&L in order 11

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 96 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

The net order balance of $11.00 left in the production order will be treated as the WIP
amount in SAP R/3 if the overall status of the production order has not yet completed.
Normally, a production order is treated as completed when the total goods receipt
quantity = the total goods quantity planned to be produced.
In SAP R/3, actually the nature of WIP calculation and the corresponding posting in FI
general ledger is just an accrual posting for the costs that have not yet been absorbed by
goods receipt and are still remained in an incomplete production order at the time of
month end processing.

Month End Processing Variance Calculation

After finishing the WIP calculation, users have to process the variance calculation
process. If the production order in our existing example has been completed, the
remaining order balance of $11.00 will be treated as production variance instead of WIP.
The total $11.00 of production variance could be broken down into different cost natures
(such as $10.00 raw material cost and $1.00 of general overhead costs) and different
sources (such as price or quantity usage of raw materials). The breakdown will be posted
and stored into different value fields in COPA for analysis.

Month End Processing Settlement

Settlement is the last step of the month end procedure for production orders. The usage
of the settlement is to generate accounting postings for the calculation results of WIP and
variance calculations.
If the order is incomplete (i.e. total goods receipt qty is less than the total planned output
qty), WIP will be posted and the entries will be as follows :
Dr. WIP
Cr. WIP capitalisation

11
11-

(You will know if the order is complete when the total delivered quantity is equal to the
total quantity to be produced)
The posting effect is to post an accrual of the P&L amount of $11.00 back to the balance
sheet. If the production order is completed in the next period, this accrual posting will be
reversed automatically by the system of the next month end settlement.
If the order is complete (i.e. the total goods receipt qty = total planned output quantity),
production variance will be posted and the entries will be as follows :
Dr. Production Variance

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 97 of 147

11

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Cr. Factory output from production

11-

The overall effect is to reclassify the net P&L cost in the production order into production
variance account.
In additions to the above general ledger postings, the production variance will also be
broken down and posted into COPA.

3.9.12.
Production Order Processing for
Finished Goods
Production order of finished goods are used to manage the production of the finished
products. In most cases, this present the final packing process in AAA. But actually the
whole production order execution process will be exactly the same as the orders for semifinished goods

Raw material consumption at backflushing

Materials used for final production of finished goods and the required semi-finished
goods will be consumed into the production order by backflushing. Suppose $100 of
packaging raw material cost and $200 costs (from standard price) of semi-finished goods
are consumed in the production order, the accounting posting will be as follows :
Cr. Raw material inventory
Cr. Semi-finished goods inventory
Dr. Raw material consumed
Dr. Semi-finished goods consumed

100200100
200

The material consumption cost will be posted to P&L and captured into the production
order

Labour and production overhead cost allocation

The same logic mentioned in the semi-finished goods case still applies. Suppose the
production time being entered in backflushing is 10 hour and the standard rate for labour
and overhead are $1/hr and $2/hr respectively, the labour and overhead cost being
allocated into the production order will be $10.00 and $20.00 respectively. The posting
will be as follows
Dr. Labour cost (to production order)
Cr. Labour cost absorption (from cost center)
10Dr. Overhead cost (to production order)
20
Cr. Overhead cost absorption (from cost center) 20-

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 98 of 147

10

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Absorption of Production Cost to Inventory at Goods Receipt

The production costs in the finished goods production order will be capitalised into
finished goods inventory during goods receipt (i.e. backflushing). But the production
order cost estimate (i.e. the plan cost of the production order) will be used (instead of the
standard cost) to post the good receipt value
Suppose the production order cost estimate of finished goods is $329.00 which includes
$200 of semi-finished goods costs, $90 of standard raw material cost, $10 of standard
labour cost, $20 of standard production overhead cost, and $9 of general overall cost
(10% of the total standard raw material cost), the goods receipt posting will be as
follows :
Dr. Finished goods inventory
Cr. Factory output from production

329
329-

Month End Processing General Overhead Allocation

Continue with our previous example of the production order of which $100 of actual raw
material cost have been posted and general overhead rate is 10%. That means the general
overhead being allocated to the production order will be $10.00. The posting will be as
follows :
Dr. General overhead cost (to production order)
10
Cr. General overhead cost absorption (from cost center) 10-

Month End Processing WIP Calculation

With our existing example for finished goods order, the cost items posted into the order
are as follows :
Semi-finished goods costs
200
Raw material costs
100
Labour cost
10
Production overhead
20
General overhead
10
Factory output
329------------------------------------------Total net P&L in order 11
Same as semi-finished goods order, the net order balance of $11.00 left in the finished
goods production order will be treated as WIP if the order is incomplete (i.e. the total
goods receipt quantity is less than the total planned output quantity)

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 99 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Month End Processing Variance Calculation

Unlike semi-finished goods, this process is virtually not required for finished goods order
because the finished goods is valuated at moving average price

Month End Processing Settlement

If the order is incomplete (i.e. total goods receipt qty is less than the total planned output
qty), WIP will be posted and the entries will be as follows :
Dr. WIP
Cr. WIP capitalisation

11
11-

If the production order is completed in the next period, this accrual posting will be
reversed automatically by the system of the next month end settlement. The overall
mechanism is exactly the same as the production for semi-finished goods
If the order is complete (i.e. the total goods receipt qty = total planned output quantity)
and the finished goods inventory has not yet been sold before month end, the production
variance will be posted to finished goods inventory as follows :
Dr. Finished goods inventory
Cr. Factory output from production

11
11-

After the posting, the inventory value becomes $340.00 ($290 + $11) which is the total
actual cost incurred in the production order.
If the order is complete (i.e. the total goods receipt qty = total planned output quantity)
and the finished goods inventory has been sold before month end, the production variance
will be posted to P&L as production variance
Dr. Production variance
11
Cr. Factory output from production

11-

After the posting, the total P&L at period end will also become $340 ($290 of COGS +
$11 of production variance)

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 100 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Pr oduct Cost i ng - Pr oduct i on Or der Per i od End Pr ocessi ng

Fi nance

I ndi vi dual
pr ocessi ng of
over head
al l ocati on ( KKAX)

St ar t

I ndi vi dual
pr ocessi ng of W
IP
cal cul at i on
( KKAX)

I ndi vi dual
pr ocessi ng of
var i ances
cal cul at i on
( KKS2)

I ndi vi dual
or der / m
ass
pr ocessi ng?

End

I ndi vi dual
pr ocessi ng of
over head
al l ocati on ( KKAX)

256783903.doc
Printed on: 1/9/2015 2:56 PM

I ndi vi dual
processi ng of
pr oduct i on or der
set tl em
ent ( KO88)

I ndi vi dual
pr ocessi ng of W
IP
cal cul at i on
( KKAX)

Page 101 of 147

I ndi vi dual
pr ocessi ng of
var i ances
cal cul at i on
( KKS2)

I ndi vi dual
processi ng of
pr oduct i on or der
set tl em
ent ( KO88)

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.10. Profitability Analysis


This is the highest organisation level in the Controlling (CO) module (for Cost Accounting
purposes), in which the profitability of the company can be viewed and analysed in multiple
dimensions, like plant, product characteristics, sales organisations, distribution channels, etc.
These dimensions are termed as Characteristics in the SAP CO-PA module.
The aim of the module is to provide your sales, marketing, product management and corporate
planning departments with information to support internal accounting and decision-making.
CO-PA lets you evaluate market segments, classified according to various characteristics such as
products, customers, or strategic business units such as company codes, etc. with respect to your
company's profit or contribution margin.
In AAA, CO-PA will serve both analysis needs from Finance and Supply Chain users. Due to the
integration nature of SAP, necessary Sales/ Profit data are centralised in COPA for different
analysis purposes. This centralisation of logistics characteristics and financial information will be
performed in the COPA in R/3 system. Gathered data will be fed the SAP Business Information
Warehouse(BW) for further reporting capabilities. As a result, AAA needs a comprehensive
review on the requirements for both COPA and BW at the same time to synchronize the
understandings across the company and identify a streamlined solution for different reporting
needs. This exercise is commenced and the confirmed requirement on both COPA and BW will
be obtained from AAA users (both Finance and Supply Chain) by end of Dec 2003.
Note:
The COPA sections in the design document only reflect the initial information gathering and
preliminary mapping to different R/3 structures. Revised version is expected after full review
completed by end of Dec 2003.

3.10.1.

Organisation Unit in COPA

Operating Concern:

Highest organisation level in SAP for Controlling modules (Management Reporting)

One single Operating Concern is proposed to AAA to centralise all margin analysis
data across AAA reporting units

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 102 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Operating Operating Concern


Concern
Description

Assignment to Controlling
Area

1000

1000 AAA Group

AAA Group

For detail organisation unit relationship, please refer to Section 2.5 on Controlling
Organizational Structure in this design document.

3.10.2.

COPA Method Deployment

In SAP CO-PA module, there are 2 methods to account for market segment analysis:
Costing-Based COPA

Accounting-Based COPA
During the design phase, white paper has been issued on the comparison on different COPA
method. AAA Management has confirmed that Costing-based Profitability Analysis will be
deployed by AAA. This section highlights some of the major comparison and will focus on the
rational why Costing-based COPA is the preferred method for AAA.

Common Structure Profitability Segments

Both methods store Cost of Sales information in different Profitability Segments. Each
unique combination of Characteristics forms a specific Profitability Segment.
Examples of Characteristics: Product No., Product Gp, Plant, Company Code, Customer
No., Sales Area, Distribution Channel, Region, etc.

Differences - Media of carrying Revenue/Cost of Sales


information
Costing-Based CO-PA

Account-Based CO-PA

Revenue/
Value Fields
Revenue/ Cost Elements
Cost of Sales Lowest level of data need to Equal to P&L account in the Operating
information
be analysed per Profitability
Chart of Accounts in SAP FI module
presented as
Segment (can be a lower level
than a GL account)

Major comparison of Value Fields and Revenue/ Cost


Elements:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 103 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Value Fields
Level of
analysis

Revenue/ Cost Elements

Same level as P&L GL accounts (always


Can be lower level of details than GL 1:1 relationship with accounts in FI)
accounts
Can be same level as GL accounts (1:1
relationship with accounts in FI)
Can be grouped level of GL accounts
Each Value Field is user-definable

Quantity
capturing/
UOM

Standard Value Field in capturing sales Standard field in capturing sales


quantity/ UOM
quantity/ UOM

Examples:

Example of same level as GL account


Revenue

GL account Revenue

GL account Cost of Goods Sold

Promotional Expenses

GL account Sales Allowance

Example of lower level of details


than GL accounts
Cost of Goods Manufactured - Direct
Material
Cost of Goods Manufactured Indirect Material
Cost of Goods Manufactured - Direct
Labor
Cost of Goods Manufactured Indirect Labor

GL account Prod. Price Variance

GL account Salesperson salaries

GL account Promotional Expenses

And all other P&L GL accounts


posted to Profitability Segment

Reasons for adopting Costing-Based COPA

SAP CO-PA was intended for use with a cost-based approach that stores different
currencies, quantities and values from SD, FI, MM and PP as PA value fields to
manipulate for a variety of reports. This is the recommended path as it allows more
variability in collecting data for PA reports (related to details of cost components for
variances, etc.)
According to Accenture experiences on High-Tech industry companies using SAP COPA, the majority of them utilitise Costing-Based COPA to enable more detail level of
Cost of Sales analysis. Costing-Based CO-PA sometimes does not match with legal book
values. Such discrepancies can be explained mainly by 3 big factors:
o Timing differences:
When the Delivery step is performed in SAP SD, but Billing is not, nothing
gets booked into COPA, but COGS is already booked in the FI legal book.
During the SD Prototype, since Billing Due List (a batch program) will be
executed each day, which perform the billing step for Sales Order with

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 104 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Delivery but not yet billed, the COGS and Revenue will be in syn in both FI
and COPA for AAA.
o

Accruals:
It is possible that accrued values are posted in COPA (might be triggered by
program in Sales Order conditions), without any posting in FI legal book
Rounding differences from Foreign Currency Translations

Note:
Management using/ viewing these COPA reports need to be acknowledged the fact that
due to the intended design of the Costing-Base COPA, values not necessarily always tie
to FI legal book. Discrepancies to FI might occur, but explainable.

3.10.3.

COPA Structure - Characteristics

The characteristics in Profitability Analysis represent those criteria according to which you
analyze your operating results and your sales and profit plan. The combination of the values for
the characteristics in an operating concern is called a Profitability Segment.
Preliminary mapping of AAA requirement to SAP structure are summarized in the following table.
Details are subject to change as part of the exercise in confirming the final COPA/ MOR business
requirement.
As a result of the COPA/BW warehouse, this will be finalized early Jan.
Characteristics
AAA Term
CUSTOMER TYPE
RECORDNO
CUSTOMER_PO
INVOICE NO
CUSTNMBR
CUSTOMER SUMMARY NAME
CUSTOMER NAME
SALES PERSON
OPERATING UNIT

256783903.doc
Printed on: 1/9/2015 2:56 PM

SAP Term [Proposed]


Distribution Channel
[Sales Organisation]
1. Sales Order
2. Item No.
[Sales Order Header/ Item level]
Customer PO number
[Sales Order header level]
Billing Doc No.
[Billing Doc. Header level]
Customer No.
[Sales Order/ Billing Doc.]
Group Key
[Customer Master]
Customer no. Attribute
[Customer Master]
Sales Employee
[Customised Partner]
Company Code
[BURKS]

Page 105 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Characteristics
AAA Term
RESPONSIBLE BRANCH

SAP Term [Proposed]


Sales Office [Customer Master]

REGION

Region [Customer Master - General]

MFG SOURCE

Product Hierarchy-level1 [2 digits]

ORDER TYPE

TBC - HK only [Bulk/ Non-Bulk]???

MARKETING MODEL CODE

Customisation is needed
[Step 1: new table to store versions of 'Marketing Model
Code'
Step2: Reporting need to read this code]
Product Hierarchy-level 2 and 3 [5, 8 digits]

SALES PRODUCT CODE


Assortment Code

Default Package Code


Default Silkscreen Code
LOYALTY PROGRAM

Material No.
[Material Master]
First segment of Material Master
[1st to 6th digits]
Division' in Material Master
[MARA-SPART]
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
TBC from MM/PP Team
Fourth segment of Material Master
[14th to 18th digits]
Third segment of Material Master
[9th to 13th digits]
N/A in SAP
N/A in SAP
Field to be customised in Sales Order Item level

BRAND NAME
PRODUCT LABEL
Set Type
Set Usage
Free Goods
SHIP MODE
Third Party Customer
CUSTOMER CLASS ID

TBC from MM Team [Material Master]


TBC from MM Team [Material Master]
TBC from SD Team
TBC from SD Team
TBC from SD Team
Field TBD from Sales Order header level
TBC from Debbie
Customer Gp' Customer Master - Sales View

Customer Territory

Sales District' Customer Master Sales Area view

APPROVAL STATUS OF
WORLDWIDE ORDER
ITEMNUMBER

TBC from SD Team

MODEL
MODEL TYPE
FILM TYPE
FLIM SPEED
FLASH TYPE
MOTOR TYPE
ZOOM TYPE
Power Zoom
FOCUS TYPE
DISPLAY TYPE
SENSOR TYPE
RESOLUTION (MP)
PACKAGE CODE
SILKSCREEN CODE

256783903.doc
Printed on: 1/9/2015 2:56 PM

TBC from SD Team

Page 106 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Characteristics
AAA Term
PRODUCT TYPE
STATUS1

SAP Term [Proposed]


TBC from SD Team
TBC from SD Team

3.10.4.

COPA Structure Value Fields

The value fields contain values and quantities that were updated or planned for particular objects.
In costing-based profitability analysis, value fields represent the lowest level of detail at which you
can analyze quantities, revenues, sales deductions, and costs for profitability segments in
profitability analysis or contribution margin accounting. You are able to define the revenues and
costs that go into specific value fields for profitability reports or sales and profit planning when you
set up your SAP System.
Preliminary mapping of AAA requirement to SAP structure are summarized in the following table.
Details are subject to change as part of the exercise in confirming the final COPA/ MOR business
requirement.
Value Fields
AAA Term
QUANTITY

SAP Term [Proposed]


New Value Field

UOM

New Value Field

The bbb Quantity

TBC from SD Team

GROSS SELLING PRICE

New Value Field

ADV+CO-OP% GROSS SALES

Calculated Field in COPA Report

Return Allowance(%)

Calculated Field in COPA Report

OTHER ALLOWANCES

Calculated Field in COPA Report

NET SELLING PRICE

Calculated Field in COPA Report

Transfer Price

New Value Field

FOB Commission

New Value Field

SPC MATERIAL COST

New Value Field [from COPC]

SILKSCREEN MATERIAL COST New Value Field [from COPC]


PACKAGE MATERIAL COST

New Value Field [from COPC]

FILM MATERIAL COST

New Value Field [from COPC]

BATTERY MATERIAL COST

New Value Field [from COPC]

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 107 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Value Fields
AAA Term
OTHER PACKAGE MATERIAL
COST
TOTAL MATERIAL COST

SAP Term [Proposed]


New Value Field [from COPC]
Calculated Field in COPA Report

SCRAP RATE

New Value Field [from COPC]

SPC LABOUR COST


SILKSCREEN LABOUR COST
PACKAGE LABOUR COST
TOTAL LABOUR COST
SPC OH COST
SILKSCREEN OH COST
PACKAGE OH COST
TOTAL OH COST
TOTAL GENERAL OH COST
FUJI / DIGITALROYALTY COST
MARKETING BRAND ROYALTY

New Value Field [from COPC]


New Value Field [from COPC]
New Value Field [from COPC]
Calculated Field in COPA Report
New Value Field [from COPC]
New Value Field [from COPC]
New Value Field [from COPC]
Calculated Field in COPA Report
Calculated Field in COPA Report
New Value Field
New Value Field

TOTAL MANUFACTURING COST Calculated Field in COPA Report


Freight and Duty Cost
COST OF GOODS SOLD PER
UNIT
GROSS PROFIT PER UNIT

New Value Field


Calculated Field in COPA Report

CONTRIBUTION MARGIN DIG


CAM T SUPP
CONTRIBUTION MARGIN REP
COMM US
GROSS SALES TOTAL
NET SALES TOTAL
Total FOB Commission
TOTAL COST OF GOOD SOLD
TOTAL GROSS PROFIT
TRANSACTIONUNITCOST

Calculated Field in COPA Report

TRANSACTIONTOTALCOST

TBC from SD Team

CURRENTLANDEDCOST

TBC from SD Team

3.10.5.

Calculated Field in COPA Report

Calculated Field in COPA Report


Calculated Field in COPA Report
Calculated Field in COPA Report
Calculated Field in COPA Report
Calculated Field in COPA Report
Calculated Field in COPA Report
TBC from SD Team

Actual Value Flow into COPA

For Sales and Distribution module triggered business transactions, COPA in AAA will be updated
upon Billing stage. All the sales transactions posted in COPA will therefore have both the Sales
Revenue and Cost of Sales matched, and margin analysis in COPA is possible with complete
data of the sales transaction.
Additional postings directly from FI module are possible for exceptional conditions.
The detail Actual Value Flow design into COPA from other SAP modules will be confirmed upon
completion of the whole COPA/ BW requirement gather stage (by end of Dec 2003).
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 108 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.10.6.
Responsible Branch

Special Treatments on

In AAA, there are sales deals that are recorded in CCHKs accounting book, but belongs to
Responsible Branch in management reporting perspective.
Responsible Branch in this case refer to AAA subsidiaries/ area of concerns which initiate the
sales relationship with the Customer. Each Customer will therefore has a unique Responsible
Branch. In SAP, for every Customer Master Record, Responsible Branch should be identified.
We will use the field Sales Office in the SAP Customer Master Sales View in recording this
information. For example,

Customer:
Sales Office:

A
CCUK

Customer:
Sales Office:

B
CCHK

Sales transactions of both Customer A and B are booked in CCHKs book. This impacts the FIGL.
In Management Reporting (either in COPA or BW in To-be SAP), Customer A will belong to
CCUK. Respective Sales Revenue, COGS, Allowances will all be presented as if the sales
triggered by CCUK. Customer B will remain under CCHK in Management Reports, due to the
Sales Office is CCHK.

List of Sales Office here includes, but not limited to the followings:
CCUS
CCCA
CCUK
CCGE
CCFR
CCJP*
* Not all Sales Office defined here represent AAA subsidiaries (separate legal entity). CCJP is
not a AAA subsidiary, but can be viewed separately in Management Reportings.

3.10.7.
Handling

Sale Allowances/ Provisions

For high level treatment on Sales Allowances/ Provisions, please refer to Sales and Distribution
(SD) Conceptual Design Document. Details of each triggering points of Sales Allowances/
Provisions, treatment upon Returns, Accounting Postings, transaction flows to COPA will be
further discussed during the Detail Design Phase.

3.10.8.
Master

Partner Functions of Customer

For a Customer that AAA has business relationship with, different Business partners are related
to this Customer and have a number of different functions, described as partner functions.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 109 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

They exist in SAP as separate Master Data and linked to Customer


For AAA, there are a number of Parnter Functions defined per each Customer:
Partner Functions
(Customer
Related)
Sold-to-Party

Definitions

Usage in SAP

Ship-to Party

Bill-to Party

Pay-to Party

Sales Employee

A person or company that


places an order for goods or
services.
Contains data on sales, such as
the assignment to a sales office
or a valid price list

SD: Generate Sales Order


COPA: Primary data in
updating COPA
Characteristics. Every line
item Customer no. field is
populated with Sold-to Party
no. Other characteristics are
derived from it

A person or company that


SD: Generate Delivery
receives goods.
The ship-to party may not
necessarily be the sold-to party,
the bill-to party, or the payer.
Contains data for shipping,
such as unloading point and
goods receiving hours
A person or company that
SD: Generate Billing
receives the invoice for a
delivery or service
The bill-to party may not
necessarily be the payer of the
bill.
Contains the address and data
on document printing and
electronic communication
The payer may not be the bill-to FI: Accounting Posting of the
party.
SD Billing document will be
updated with Pay-to Party
A person or company that pays
no. Therefore it is this
the bill.
number which will impact FI.
Contains data on billing
schedules and bank details
Customisated Parnter for AAA in recording responsible Sales EE per
Customer for COPA reporting

Note:
As a preliminary design, the following Partner no. will be updated in COPA:
Sold-to Party (Customer no. in COPA Characteristic)
Bill-to Party
(New Characteristic in COPA to be created)
Sales Employee (New Characteristic in COPA to be created)
Final decision will be based upon further discussion in Detail Design Phase.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 110 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.11.

Budgeting/Planning

A ccountD ept
(C orporate)

Supply C hain

A nnualB udgeting

1.Sales Forecast
R esultfor
com ing year

2.C opy as a
basis for
A nnual
B udgeting

A s a C O Plan
version A

3.R eview
B udgeting
D ata

5.Inform
Sales D ept
to Fix Error

Y ES

4.Error
Exist?

11.Prepare
D ata for
freight/duty
budget

7.Inform
other D ept
for A nnual
B ud

NO

R eporting U nits
(& R espective
D ept)

A ccountD ept
(H K )

AND
8.Prepare D ata
for Std.C ost
Estim ate

9.Perform Std
C ostEstim ate
in C O PC
Y ES

14.B udgeton
D epartm ental
costin C C A

15.A llocation in
C O PA N eeded?

16.
A

<Function>

19.A llocation in
C .C .N eeded?

17.Perform B udgeting
A nalysis vs A ctual
A nalysis in C C A

NO

23.
B

6.A djust
D ata in SA P
NO

256783903.doc
Printed on: 1/9/2015 2:56 PM

13.B udgetC O G S
based on Sales Q ty
autom atically in
C O PA

10.Inform
C orporate of
B udgetC om pleted

Y ES

18.B udget
on Selling
Expense

12.Inputfreight/
duty budget in
C O PC

Page 111 of 147

20.
A

21.Perform
B udgetvs.
A ctualA nalysis

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

A nnualB udget(C ont')

FIN A NC E

Perform A llocation from


C ostC enter to Profit
Segm ent(C O PA )

Perform Top D ow n
D istribution in C O PA

If necessrary

If necessrary

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 112 of 147

EN D

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Annual Budgeting process for AAA has been documented on the process flow section in this
design document. Sales forecast information form the source data for the budgeting process.
Departments involved includes: Accounting Dept (Corporate), Accounting Dept (local
subsidiaries), Sales and Marketing Dept (local subsidiaries).
Budgeting for AAA is termed as Planning in SAP.
Same as the actual financial data capturing, the financial planning function in SAP R/3 is handled
by different modules and can be integrated. Note that though R/3 provides a range of Planning
capabilities to enable the information capturing of AAAs Annual Budgeting process on different
stages, sophisticated Budgeting analysis (for example What-If analysis, sensitivity analysis, etc.)
need to be handled by a more advanced SAP Financial product Strategic Enterprise
Management Business Planning and Simulation (SEM-BPS) module. This solution is based on
SAP-BW technology and is not in-scope for current phase.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 113 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.11.1.
Annual Budgeting

SAP R/3 modules deployed for

For P&L items:


Budgeting on Sales related items (Quantity/ Revenue per customer/ product level) will be
performed in SAP COPA Planning
Budgeting on Cost of Sales (Product related costs) will be performed in SAP COPC
(using Standard Cost Estimate). The information will then pass to COPA Planning in
terms of Characteristics/ Value Field combinations
Budgeting on Cost of Sales (Landed costs) will be performed in SAP COPA Planning
(using Characteristics and Value Fields)
Departmental Costs - Selling expenses (including Freight/ Commission per customer/
product level) will be first performed in SAP COPA Planning. The planned value is then
rolled up to Company-Code level in COPA report. Users extract the rolled-up
information and update the Cost Centre budget on Sales and Marketing Dept. In COPA
Planning, there is function on planning a particular item based on predefined percentage
of another planning item, e.g. Commission = 10% of Gross Sales. However, more
sophisticated formula calculation need to be performed offline.
Departmental Costs (All other budget items Overheads) will be performed in SAP COOM Planning. The Planning dimension will be by P&L account/ Cost Centres. After the
CO-OM planning has been completed and approved, value are allocated to COPA
Planning by Assessment method in SAP. This way, the COPA planning module will
contains all the budgeting data in CO-OM planning.
For B/S Items:
Balance Sheet Items (Consolidated basis) will be performed in Enterprise Controlling
Consolidation (EC-CS) module directly. A specific Plan Version will be defined in ECCS for the Budgeting purpose. Plan versus Actual analysis on Consolidated Balance
Sheet will be performed in EC-CS as well.

3.11.2.

Plan Version

The definition of a version applies to the whole Controlling area. Each version in SAP denotes a
complete set of cost view. They have 2 main groups, Actual Version and Plan Version. All Actual
Costs are captured and stored in Version 0, the default version. Also, Version 0 can capture Plan
Costs. All other versions are separate views used for Planning and capturing planned costs only.
Each Plan Version in SAP is set up for different business meaning
For different purposes (e.g. Sales Forecasting and Annual budgeting will be 2 different
groups of Plan Versions in SAP
Form part of the Budgeting process tool to store value updated/ confirmed by different
parties (e.g. Plan Version for individual reporting unit; Plan Version after Corporate
Review)
Denote the value on different time span (e.g. Plan Version: First quarter; Plan Version:
Second Qtr., etc.)
The followings are the Plan Versions to be configured for AAA:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 114 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Version

Descriptions

Usage

Master Version

050

Sales Forecast

100

Annual Budget from


Sales Forecast
Annual Budget Departmental Cost v1
Annual Budget Departmental Cost v2

-Store Actual/ Plan


values
-Used for reporting
-Required by SAP
-Weekly Sales Forecast
by Supply Chain
-Data copied from
version 050
-Data input based on
version 100
-Data input/
amendment based on
version 110
-Amendment on version
120 and finalize amount
for the year
-Data copied from
version 200
-Data copied from
version 210, with
adjustments for 1st Qtr.
-Data copied from
version 220, with
adjustments for 2nd Qtr.

110
120
200

Annual Budget
Corporate Review

210

Annual Budget 1st Qtr


Corporate Review
Annual Budget 2nd Qtr
Corporate Review

220
230

Annual Budget 3rd Qtr


Corporate Review

AAA Business
Processes
Actual postings

Type of Costs
Captured
Actual/ Plan

Sales Forecast
Annual
Budgeting
Annual
Budgeting
Annual
Budgeting

Plan
Plan
Plan
Plan

Annual
Budgeting

Plan

Annual
Budgeting
Annual
Budgeting

Plan

Annual
Budgeting

Plan

Plan

Note:
It is advised that the Version 0 is always copied with the most updated information for the purpose
of Plan vs. Actual Comparison. Since this acts the master version, all AAA companies can always
refer to value of this version when performing the necessary analysis (e.g. measurement on
departmental/ reporting unit performance). This avoids the unnecessary confusion that might
have caused by too many Plan Versions used in the system.
In terms of reporting capability, though we suggest reporting should mainly refer to Version 0
(which contains both Actual and Plan values), SAP enables users to choose specific Plan Version
upon report selection screen, if necessary.

Plan Version is a configuration setting of CO module in SAP. During the Design Phase, the team
will configure the Plan Version according to the current need of AAA. Future creation/ freezing
of Plan Versions are also possible after system goes live.
It is not a usual practice to reuse the Plan Version, since SAP provide max. 999 different versions.
Take an example, say Sales Forecast information will be kept monthly, the no. of Plan Versions
will be 12. The values are updated to same Monthly Plan Version the next year. If information
per a particular time frame is needed, Report Extract is recommended to use instead of creation
of new Plan Version.

3.11.3.

Planning Layout

This is part of the exercise in the Detail Design Phase to define the SAP Planning Layout for
different Budgeting process for AAA. Standard SAP offers different planning input options:

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 115 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

SAP screen planning layout input Tradition SAP screen input


It provides the wide range of standard SAP Planning function online for users. Real-time data
validation performed online, which enable users to rectify input errors upon planning data
input.
SAP Embedded Excel
MS Excel template is embedded into SAP Graphic User Interface (GUI). Major SAP function
can be used. Users can have the function of Excel during planning as well. Data are saved
directly into SAP database upon completion.
MS Excel upload
MS Excel used as an offline tool. This enable decentralised Budgeting for AAA. Users can
input budget data off SAP system and upload into SAP upon completion.
Internet enabled Planning
This is delivered standard by SAP. However, since Internet server is not adopted in this
phase of SAP implementation, Internet Planning is not an available option for AAA at the
moment.
The full review of the exact planning layout is to-be performed in detail design phase. The review
exercise will be lead by respective functional area designer and coordinate with users. SAP
Planning modules involved:
CO-OM (Controlling Overhead Cost Controlling)
CO-PC (Controlling Product Costing)
CO-PA (Controlling Profitability Analysis)

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 116 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.12. Cash Management


SD Transactions

A/R

Sales Orders

Open invoices
with due date

Cash Position
(Bank account activity, cash
balance on a given date)
+

Bank Accounts
Confirmed cash
account
Bank clearing
accounts

MM Transactions
Purchase Req
Purchase Order

Cash Liquidity Forecast


(Future cash inflows & outflows)
+
Cash Concentration
(Sweeping account balances of
several bank accounts to one
target bank account)

A/P
Open invoices
with due date

A/R
A/R
Open invoices
with due date

1000

Incoming
Payments

1000

Deposit Clearing
1000
Deposit Clearing
1000

A/R

Out Chk Clearing

Check

A/P

1000

Confirmed Cash
Bank Accounts
Postings

Payment Clearing
Accounts Postings

Open invoices
with due date

Confirmed Cash A

Deposit Clearing
Accounts
Postings

1000

A/P

1000

Outgoing
Payments

A/P

Check
Wire

3000

Wire

5000

Out Wire Clearing


2000

Out Chk Clearing

5000

3000
Confirmed Cash B

5000

5000
Out Wire Clearing

Bank
Statement

2000

Figure 3.12a Cash Management Overview

256783903.doc
Printed on: 1/9/2015 2:56 PM

3000

Page 117 of 147

2000

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Figure 3.12a Cash Management Process

SAP R/3 Cash Management offers the following tools, designed to make cash flows clear:
The cash position, which illustrates short term movements in the bank accounts
The liquidity forecast, which illustrates medium-term movements in subledger accounts
The cash position shows how your bank accounts will move in the next few days. Meanwhile, the
liquidity forecast illustrates liquidity changes in the subledger accounts. Functions are also
supported which you can use to obtain relevant information on forecast payment flows. This
information appears in the form of memo records in the cash position, or as planned items in the
liquidity forecast.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 118 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.12.1.
Common information and
differences between Cash Position and Liquidity Forecast
Common:

Both reports contain levels. These supply high-quality information on the commercial reasons
for a movement in an account - that is, they explain how the account opening and closing
balances came about. For example, levels give information on whether a balance in a bank
account is the result of a bank posting or of a memo record entered manually.
They can also be classified according to how secure the receipt is - for example, by
confirmed or unconfirmed memo record.
Differences:
In the cash position, accounts (bank and bank clearing accounts) supply information on the
current balance.
The liquidity forecast contains groups instead of accounts. Vendors and customers are
assigned to a planning group by means of an entry in the master records. Each group reflects
certain features, procedures, or risks.

3.12.2.

Memo Records

Memo records will be used by AAA to include additional liquidity information (e.g. anticipated
incoming and outgoing payments) in short-term planning which does not trigger actual bank
transactions, AR/AP subledger postings
Cash management memo records can be created as individual entries or using fast entry.
The entry is split into three parts:
1. Planning data (date, account - cash management account name, expiration date if required)
2. Amount data (including currency, exchange rate)
3. Additional information (assignment, characteristics, and so on)
- The planning type controls the entry level, screen, and expiration
- The expiration date shows how long the payment advice is included in planning
- Characteristics (free text) can also be input by users for identification of records quickly

The planning type is a unique classification characteristic, entered in all manual memo
records. It controls the level to which a memo record is sent.
For exchange rate on the memo record, system uses the average rate by standard design

Minus sign is needed for outgoing payments advices

List of Planning Type (Difference type of Memo Records) is to be defined during Detail Design
Phase of the Project by Finance users.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 119 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.12.3.

Cash Position

The cash position is the result of the entry, by value date, of all the payments in a given, short
time horizon.
There are three sources of data for the cash position:

FI postings to cash-management-relevant G/L accounts


Memo records entered manually
Cash flows from business transactions managed with the Treasury Management application
component. This type of transactions is not applicable under the current design phase, since
SAP Treasury modules like Loan Management, Market Risk Management are not in-scope
for Release One of the SAP Implementation in AAA

Cash Management Groupings for Cash Position

After the bank statements are posted in FI, the account transactions can be displayed in
the cash position. The balances in the bank accounts, which you can display using the
cash position, form the basis for planning decisions. Cash Management Groupings are
needed to maintain for the display of Cash Position report.
Detail requirements are to-be confirmed by users.

Bank Accounts set up in SAP (FI-GL and Cash Management)

Bank accounting is to provide a bank (current) account for each currency and, in each
case, a clearing account, on a lower level and per processing type. Clearing accounts are
defined to meet specific business needs.
Objectives of setting up different bank clearing account (for a physical bank account at
bank):

Accounts can be reconciled at any time

Foreign currency and local currency are managed in parallel

Can be managed by value date

Line item analysis possible

Items posted automatically using automatic payment transactions

Automatic breakdown using electronic banking transactions


Only transactions which are, according to the bank statement, active are posted in the
bank main (current) accounts.
One general ledger account is needed to set up for each active account you have at the
bank, by currency if applicable. In addition, bank clearing accounts are needed for each

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 120 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

bank main account, also by currency if applicable. In this connection, we recommend the
following grouping as example:
10020010
Bank 1 (current account - domestic - currency USD)

10020011

Bank 1 (outgoing checks)

10020012

Bank 1 (outgoing bank transfers, domestic)

10020013

Bank 1 (outgoing bank transfers, foreign)

10020014

Bank 1 (incoming checks)

10020015

Bank 1 (customer cash receipts)

Note:
The exact differentiation is to be confirmed by users as part of the Chart of Accounts and
Cash Management design exercise.
All bank (current) accounts should be assigned to a unique planning level, where bank
statements and, with them, the actual bank balance are represented. For example,

10020010
Bank 1 (current account - domestic - currency USD): F0 level
All levels starts with F notify this is a bank main account in Cash Management
module
On the other hand, bank clearing accounts should be maintained on an open item basis.
They can, for example, be sorted by local currency amount. Depending on the type of
bank clearing account, a specific planning level is then assigned - for example, for:

10020012
Bank 1 (outgoing bank transfer, domestic): B2 level

10020015
Bank 1 (customer cash receipts): a B9 level
The field Planning Level is stored in the Company Code Specific segment of the GL
Master data for all Bank current accounts. The assignment is critical during the GL
master creation. Otherwise, no information from bank postings will be gathered by Cash
Management module.

Processing sequence on the Bank related transaction (from


GL to Cash Management)

1. Payment transactions: are posted against the clearing accounts using the payment
program.
2. Bank statements: balance the clearing entries against the bank account.
3. Cash Management: displays or monitors postings, with the help of various
groupings.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 121 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Currency Display in Cash Position Report

Specific currency can be specified in the Display field. You can use the currency fields to
display the foreign exchange risk. On the one hand, you can show the cash position split
by currency. You can also display the extent of your currency exposure from the cash
position. The average rate is usually used for the translation from planning currency to
display currency. If you want to use a different rate for the translation, make the
appropriate specification in the rate type field.

3.12.4.

Liquidity Forecast

The cash management module is integrated with both MM and SD modules such that the
commitment information can be directly obtained through these modules.
Liquidity Forecast enables AAA (both subsidiarys Accounting Dept or Corporate) obtain
medium to long term commitment and subledger information. All the Purchase order and sales
order information will be directly extracted and place into the liquidity forecast for analysis. The
value date for both purchase orders and sales orders will be based on the delivery date added to
the payment term. All the vendors and customers can be categorized to different groupings to
enhance their visibility in the liquidity forecast position.
Memo records are used to supplement any additional information which cannot directly obtained
from other modules.
The following are examples of sources of planning information for the liquidity forecast:

Receivables and commitments as expected incoming/ outgoing payments (from MM/ SD)

Planned wage and salary payments (Memo Records from TR-CM)

Cash Management Groupings for Liquidity Forecast

As with the cash position, Cash Management Groupings are set up for the liquidity
forecast structure. The grouping term is used to combine particular levels and planning
groups for display purposes.

Integration with SD/MM/AR/AP modules

Assignment of Planning group in the master record of Customers/ Vendors (CompanyCode Specific segment) is required in order for the system to transfer data between the
customer/vendor accounts and the liquidity forecast.

3.12.5.
transactions (FI-GL)

256783903.doc
Printed on: 1/9/2015 2:56 PM

Integration with Special GL

Page 122 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Line items resulting from special transactions are transferred to a special level. Use Planning
Levels that begin with "F" as these are FI postings. SAP suggests using the special G/L indicator
as the second letter: Example: FF for down payment requests/ FC for LC payments.

3.12.6.

Electronic Bank Reconciliation

The electronic bank statement is used to automatically assign incoming and outgoing payments to
house bank accounts when they relate to items already posted in the system to
customer/vendor/clearing accounts and, where appropriate, the clearing of them.
Each uploaded electronic bank statement will be assigned with a unique no. in SAP and can be
printed retrospectively.

Steps in Electronic Bank Reconciliation:

1. Electronic Bank Statement file (in SWIFT MT940 format) is extracted from HSBC
Hexagon
2. Data (SWIFT MT940 for HSBC Hexagon) is imported into a temporary dataset in
SAP
3. Batch input sessions are generated (per bank statement: one session for G/L
Accounting and one for Subledgers- AR/ AP). Bank accounting and subledger
accounting batch session can be executed separately or jointly
4. Posting rules and account determination are defined in TR-CM customization
5. As an electronic bank statement is being imported, the system identifies the
transactions in it and determines how they are posted.
6. The note-to-payee fields in the electronic bank statement contain various information
relevant to open item clearing. Note to payee fields can be interpreted by document
number or reference document number for the clearing transaction (example:
standard algorithm). If the algorithms we deliver are not sufficient, it is possible to
program a user exit tailored to your business (e.g. change the posting rule; influence
account determination by means of account modification).
7. Post-processing for posting proposals(line items) which cannot be cleared
Note:
Electronic Bank Statement format SWIFT MT940 is compactable with SAP TR-CM.
Standard algorithm for clearing documents is available in the predefined form in SAP.
Customisation, as stated in point 6 above, will be needed to cope with AAA specific
requirements on Bank Reconciliation. The review task will be performed on the Detail
Design Phase, detail of which will be incorporated into the respective customisation
functional specifications.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 123 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.12.7.

Cash Concentration

Cash concentration involves moving the balances from various bank accounts to one target
account, keeping defined minimum balances in the source accounts. The system creates a
concentration proposal, based on the grouping. The proposal contains the balance for the end of
the day, and the planning result - that is, the likely account transfers. Correction can be made on
the concentration proposal at any stage in the process. The result is printed and takes the form of
payment orders to the banks.
The grouping contains only those costs that are to be included in cash concentration. You can
define different groupings in cases where the concentration procedure is different.
AAA Corporate can perform the Cash Concentration function on balances for a number of
company codes at the same time. A Company Code Worklist can be created to combine a
number of company codes for the execution.

Procedure for Cash Concentration function:

Enter the company code or, if you are concentrating cash for more than one company
code, the worklist.

In the Planned to field , enter the planning date up to which you want to concentrate
balances.

Enter a grouping term in the Grouping field, thereby selecting particular accounts for
concentration. Example: BANK-ACT.

Enter the cash management name for the account where the amounts are to be
concentrated. Enter the target company code

If required, use the Minimum Balance field to stipulate the minimum balance an
account must have before it is selected for cash concentration.

In the Planning Type field, enter a planning type assigned to cash concentration.

The plan amount is the total of the cash management end balances, less any defined
minimum balances applicable.

Once you have processed the concentration proposal, you can create two payment
advices for each payment order. One advice is for the sender account and one is for
the receiver.

3.12.8.

Lockbox in Cash Management

In SAP Cash Management, Lockbox function is available for electronic incoming payments
processing for US/ Canada. From the business requirement of AAA, it is confirmed during the
FICO Prototype that customer payments will be applied manually although AAA Canada has a
lockbox already in place. This is due to the small volume of data seems not beneficial to use
Electronic processing at the moment. AAA US plans to use a lockbox to collect customer
payments in the future. Therefore, there will be no customisation in enabling the Lockbox

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 124 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

interface between SAP and the bank for the Lockbox function upon Release 1 of the SAP
implementation.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 125 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

3.13. Consolidation Procedures


SAP Code3200
Goldline
(Europe)
Limited

Consolidation
Unit/
Company
(Country)
[Ownership
Percentage]

(UK and Northern


Ireland)
SAP Code 3100

SAP Code 4100

SAP Code 4200

Concord
Keystone Sales
Corp.

Concord
Camera Canada

(US)

(Canada)

Concord
Camera(Europe)
Limited
(UK and Northern
Ireland)

SAP Code 3600


Peter Bauser

SAP Code 5200

SAP Code 5300

Concord
Henggang
Electronics
Factory

Concord
Shenzhen
Limited

(PRC)
SAP Code 3300
3400

SAP Code 3400


3300

Concord
Camera GMBH

Concord Camera
France S.AR.L

(France)

(Germany)

SAP Code 6100


5300
Concord
Camera
Australia
(Australia)

(PRC)
SAP Code 5100
Concord
Camera HK
Limited

SAP Code 4500

SAP Code 3500

SAP Code 4400

SAP Code 4300

Starprint Corp.

Concord
Camera
Hungary

Concord
Keystone
Graphics

Concord Latin
America

(US)

(Hungary)

(HK)

(US)

(Latin America)

DataCollection
Collection
Data
Consolidation

Validationof
ofData
Data
Validation

Procedures

CurrencyTranslation
Translation
Currency
Inter
-UnitElimination
Elimination
Inter
-Unit
Consolidationof
ofInvestments
Investments
Consolidation
CC Consolidated
Financial Statements

3.13.1.

Consolidation Units

A consolidation unit is the smallest unit element in a corporate group structure that can be used as
a basis of complete consolidation. With integration with the FI general ledger, a consolidation
unit will linked to the company codes by a one-to-one basis in FI. Therefore the whole structure
of the consolidation units should be inline with the company and the coding used for the
consolidation units will be the same as the company codes in FI in AAA for easy identification.
The keys information that will be included in each consolidation unit is:

Description (Name)
Local currency
Address and other correspondence related information
Data collection definition (i.e. real-time updated from FI in AAA)

In AAA, all the consolidation units being setup into the to-be system are actual legal entities (with
the exception of CC Latin America and Keystone Sales Graphics). In the as-is system, AAA has
a dummy unit of Elimination Company that is used for elimination and adjustment postings.
However, in SAP R/3, all such postings could be done directly into the consolidation ledger levels
without affecting the local general ledgers of each reporting units. However, a dummy
consolidation unit will be established to hold historical balances that exist in the Elim company.
This consolidation unit will be dormant; no future postings will be applied. All future Elim
256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 126 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

company postings will be done through SAPs consolidation procedures and manual adjustments
will be posted in the Consolidation Ledger.

3.13.2.

Consolidation Groups

This is a user-defined group of consolidation units created for consolidation and reporting
purposes.
The key information of a consolidation group is:

Description (Name)
Correspondence data
Consolidation ledger assignment
Assignment of underlining consolidation units or consolidation sub-groups

A list of the consolidation group and units is shown below:


Cons group /
subgroup

Cons group desc

Cons unit

Cons unit desc

CG1000

AAA Bbb Group

1000
4200
4500
3400
3500

AAA Corporate US
AAA Bbb Canada
Starprint Corp
AAA Bbb France
AAA Bbb Hungary

6300
CG5100
CG3000

3600
4100

AAA Australia
CCHK Cons Subgroup
CC Europe Cons
Subgroup (UK)
CC GMBH Cons
Subgroup
CC Cons Subgroup for
Keystone Sales
AAA Bbb HK Ltd
AAA Henggang
AAA Shenzhen
AAA Bbb (Europe)
Ltd (UK)
Goldline (Europe) Ltd
AAA Bbb (CC
GMBH)
Peter Bauser
AAA Keystone Sales

4300

AAA Latin America

CG3300
CG4100
CG5100

CCHK Cons Subgroup

CG3000

CC Europe Cons
Subgroup (UK)

CG3300

CC Europe Cons
Subgroup (GmBH)

CG4100

CC Cons Subgroup for


Keystone Sales

256783903.doc
Printed on: 1/9/2015 2:56 PM

5100
5200
5300
3100
3200
3300

Page 127 of 147

Parent in
group/
subgroup
Yes

Yes
Yes
Yes
Yes

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Cons group /
subgroup

Cons group desc

Cons unit

Cons unit desc

4400

AAA Keystone
Graphics

Parent in
group/
subgroup

Note: The consolidation groups are not final due to design issues with the European consolidation
and AAA Australias change to be a subsidiary of CCHK.

3.13.3.
Consolidation Chart of Accounts
and Financial Statement Items
A consolidation chart of accounts consists of a set of financial statement items which correspond
to the G/L accounts in the consolidated book. The operating chart of accounts in FI general
ledger has to be assigned to the consolidation chart of accounts to ensure integration between FI
and Consolidation. Since a single operating chart of accounts will be used for the whole AAA
Group, there will also be only one consolidation chart of accounts in AAA Group. The proposed
consolidation chart of account name is:
Cons. chart of accounts code

Descriptions

CONC

AAA Consolidation Chart of Accounts

Financial statement items are actually the G/L accounts in consolidation. Each of the G/L
accounts in the operating chart of accounts must be assigned to a corresponding group of account
to ensure full integration between FI and EC (Enterprise Controlling). When consolidation is
active, users are forced to assign a group of account every time when they want to create a new
G/L account. This is to enforce data consistency and integrity between the operating COA and
the group (Consolidation) COA, i.e. to ensure that all the operating G/L accounts are assigned to
group accounts)
The FS item code (group account) can be a maximum of 6-digit code. The coding logic for the
FS items will follow the same logic of the G/L account coding in the FI general ledger and the
details of the coding will be determined later.

3.13.4.

Design Highlights

Keys design concept highlights of the Consolidation system in AAA are as follows :

Direct roll up from local ledgers of different reporting units


Ability to support consolidation of companies with different currencies
Group currency amount could be directly extract from local general ledger with flexibility to
revaluate with specific exchange rates for selected FS items in consolidation
Automatic eliminations of most intercompany transactions and consolidation of investment

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 128 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Support direct adjustment postings into consolidation ledger without affecting the local
general ledger of each reporting unit
Supports data upload for planned versions of budgeting

3.13.5.
Data Collection Process
Generally speaking, data collection process in Consolidation is the process for collection
of financial data reported by individual consolidation units. This function can be done
within a single tool called Data Monitor.

Retained Earning Carried Forward

This step is generally the first step of the consolidation procedure in your every month
end processing. This task could be done automatically in Data Monitor. The system will
carry forward the net P&L amount into the retained earning account in the consolidated
book for each reporting units. Both the local and USD currency will be stored.

The process could be done as a single task for all reporting units or could be done
separately for each individual units

Currency Translation

Within AAA Group, each of the reporting units will have their own local ledger
currencies. For example in CCHK, the ledger currency is HKD while in CCUK will be
in GBP. For the company codes that are not using USD as the local currency, the parallel
ledger currency will be activated in the FI general ledger such that USD will also be
stored as an additional ledger currency in the local books of the reporting units. In order
words, ledger balances in USD will be available in all company codes local books. With
the help of the integration with FI, all the USD amount local general ledger balances will
be automatically roll-up into the consolidation ledger.
The USD amount in the FI general ledger is usually being converted from other
transaction currency using an average monthly company rates. For some specific
financial statement items in Consolidation, the transaction may have to be done by
specific exchange rates. This procedure is also a standard feature in EC-CS. In the
standard system, you could choose the following rates for your specific translation needs:
Rate type

Description

1001
1002
1003
1004

Current exchange rate


Average exchange rate
Historical exchange rate
Current exchange rate prior year

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 129 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

The revaluation posting could be done in the Data Monitor as well and the general
posting in the consolidation ledger will be:
Dr./Cr. The balance sheet items being revaluated
Cr./Dr. Exchange gain or loss
Realized and unrealized gains and losses will be separated by using two separating G/L
accounts.

3.13.6.
Consolidation Process
Consolidation process refers to all possible elimination and adjustment postings done in
the consolidation to come up with the consolidated financial statements. The standard
SAP system offers automatic eliminations to most of the intercompany transactions. In
AAA, the automatic eliminations to be done by the system are elimination of
intercompany A/R and A/P and consolidation of investment. Whenever, automatic
postings are not available, manual entries are required to be posted into the consolidation
ledger. You can do all the consolidation postings in a single tool called Consolidation
Monitor. Eliminations will be done in USD currency.

Elimination of Intercompany A/R and A/P

With the help of a parameter called Trading Partner, the elimination of intercompany A/R
and A/P is a feature of automatic elimination in consolidation.
In AAA Group, intercompany transactions are being posted to intercompany vendor and
customer master record. A trading partner is a key which is defined to represent each
company codes within the AAA Group. The trading partners will be assigned to all
intercompany vendors and customers master records and hence all the transactions
associated with the intercompany vendors and customers will store the trading partners.
These also include all P&L item postings associated with the A/R and A/P items. The
consolidation will do an automatic pair up of the entries by the trading partners and do
the elimination posting accordingly. The following figure shows how the elimination is
done :

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 130 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

CC Group
CCUS (4100)
Item
A/R
...
...
A/P

Amt
20

T. Partner
5100

- 60

5100

CCHK (5100)

Item

Unit

P Unit

A/R
A/P
A/R
A/P

4100
4100
5100
5100

5100
5100
4100
4100

Item

Amt

A/R
...
...
A/P

60
- 20

T. Partner
4100
4100

Amt
- 20
60
- 60
20

Elimination posting in Consolidation

Elimination posting in Consolidation

Elimination of Intercompany Profit/Loss in Transferred


Inventory

This component enables you to eliminate profit and loss resulting from inventory
transfers between subsidiaries in your corporate group. However, currently the materials
data that is relevant for the elimination cannot be accessed by means of integration with
the logistics and the product costing modules. The overall mechanism of the elimination
could be summarized as follows:

You define a pair of supplier and purchaser relationship between two reporting
units within the group by means of manual data entry done in Data Monitor
On the purchaser side, you have to get the ending inventory amount that is
relevant to elimination of the period outside the system and then manually
entered the figure in Data Monitor
On the supplier side, you have to manually enter the mark-up percentages of
different product groups in Data Monitor.

After entering the required data, elimination posting could be done in the Consolidation
Monitor.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 131 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

It is confirmed that a customized report will be developed to provide the information of


transferred ending inventory values that the relevant mark up amounts in each branches
such that users could entered the relevant data for elimination run or directly post an
manual elimination document.

Consolidation of Investment

The major features of consolidation of investment in SAP include:


Automatic generation of elimination postings of investment in subsidiary for first
consolidation
Calculation and posting of minority interest for subsidiaries that are not wholly owned
Automatic postings for subsequent change in investment for join venture
Amortization of goodwill
In AAA Group, all the company units are wholly owned by the corporate. Therefore the
major function of consolidation of investment in AAA will be the elimination of
subsidiary investments.
Highlights of this function are listed below:
The relevant information for elimination including the percentage of ownership,
investment amount paid by the investor, the book value of the investee at the time
of acquisition have to be entered manually into the system in Data Monitor
Once the data is entered, it will be stored for future postings and no further entry
is needed.
The elimination posting will be automatically generated by executing the posting
run in Consolidation Monitor

Manual Adjustment Posting

Manual journal posting into consolidation is possible in SAP Consolidation system. Such
entries may be required in the following scenarios:

Manual adjustment of reported financial data. This is used to adjust the amount
roll up from the FI general ledger. However, instead of doing this, the best way
is to do the adjustment in the relevant local general ledger and roll up the
adjustment into the consolidated book
Manual elimination posting that cannot be automatically generated by the
system
Adjustment entries that are done in the corporate consolidated level

The concept of the manual posting is exactly the same as the voucher posting in the
general ledger. The adjustment entries have to be posted to a certain posting period of the
consolidated ledger and therefore the adjustment is only valid to the period being

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 132 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

adjusted only. If similar or even the same adjustments has to be done in the next period,
users have to post a separate voucher in the next period.
All the manual adjustment postings done directly into the consolidation ledger will not
have effect on the local general ledger of each reporting units in FI.

Consolidated Financial Statements

The consolidated financial statements are the final products of the whole consolidation
procedure. However in standard SAP R/3 system, there is no pre-defined format of
consolidated balance sheet and income statement because the format required may be
varied according to different requirements.
The consolidated financial statements are usually defined and customized by report
painter or report writer. Both tools are standard user-friendly reporting development
tools in both FI and CO modules.
The detailed requirements and layouts of the consolidated financial statements will be
defined and confirmed later.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 133 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

4.

Reporting
More than 100 standard reports are available on-line and real-time in SAP. A selection of
standard reports to be used will be done. The report list below addresses reports that have
been specifically identified to cover gaps in the functionality of SAP to meet design
requirements. All other reports will be addressed after Conceptual Design Sign-Off.

4.1.

List of To-Be Reports


Ref.

Reporti
ng Units

Report Name

Description

20

All
Branches
All
Branches
All
Branches
All
Branches

Global Vendor Aging Report

Global Vendor Aging Report shown in group


currency
Global Customer Aging Report shown in group
currency
Global Credit Report for common legal entity
customers across all Reporting Units
AR Aging Report with Reason shown in local and
group currency

TBD

CCFR,
CCUK,
CCGmbH

VAT Report for EU and


non-EU Countries

Required tax reports to government to show


VAT charged or paid for EU and non-EU
countries.

23

CCHK,
CCSZ,
CCWK
CCHK,
CCSZ,
CCWK
CC Corp

Remaining useful life of


moulds and tools

Quarterly report to analyse remaining useful life


of moulds & tools based on the projected
demands for products produced by the moulds.
Cost summary report with layout and
presentation specific Net Billing

CCHK,
CCSZ,
CCWK

61

CCHK,
CCSZ,
CCWK

Breakdown of mark-up cost


and inventory cost for
intercompany inventory
transfers
Product cost estimate
internal summary report

CCHK,
CCSZ,
CCWK

Product cost estimate with


special scrap rates

108

CCHK

Production usage of tooling


and moulding asset

21
TBD
22

4
5

256783903.doc
Printed on: 1/9/2015 2:56 PM

Global Customer Aging


Report
Global Credit Report
AR Aging Report with Reason
codes

Net Billing Report


Consolidated Reconciliation
Report with CO-PA

Page 134 of 147

Report to reconcile Consolidated Financial


Statements with applicable consolidated PA
reports by customer and by product.
Monthly report to list out the Branchs ending
inventory values that and mark-up costs in
intercompany transfers so that elimination of the
mark-up could be posted in consolidation
Product cost display with the exact layout as the
current internal summary cost report prepared
in Excel. This report should also support printing
of cost estimates for Net Billing purposes with
special currency translation requirements
specified by the users
A report similar to the internal summary report
with similar layout but will be able to convert the
scrap costs into specific scrap rates defined by
the users. This is a separate ad hoc report that
is seldom run.
A report of production usage frequency and
components produced of tooling and moulding
asset (linkage

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Additional reports requested have been added to the Project Customization Inventory:

a) Sales Statistics Reports has been added to the Report Inventory under the SD module
b) Cash paid for interest expense and income taxes, and Product group summary on a consolidated
basis of gross sales, SRAs and COGS have been added to the Report Inventory under FICO
c) Confirming whether Global Inventory Aging Report with Reason Codes, and Global Inventory
Returns Report with Reason Codes should be assigned to the MM or FI modules in the Report
Inventory
d) AR Aging with Partial Payments Detail has been added to the FICO Report Inventory
e) Provision of high risk / obsolete / discontinued product inventory as well as ending inventory
projection per month / quarter or per any specific month-end closing
f) Estimation of labour overhead absorption per month / quarter or any specific month-end closing
for the projected ending inventory
g) Standard cost LOH absorption calculation per production, per shipment and per ending inventory
based on actual performance and comparing to the budget and last year actual.
h) Material variance analysis by product, by customer, by product group, and include the
dimensions of actual, forecast, budget.
i) Selling, G&A and freight out expenses report
j)

Age gross receivables, allowances and rebates, etc., returns provisions and calculated
net receivables
k) Freight in expense analysis report

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 135 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

5.

List of Customisations
The following items may be customised and the priority needs to be confirmed:
Ref
.

Reporti
ng
Units
CCSZ,
CCWK

Customizati
on Type

Priority

Description

Purpose

Enhancement

Essentia
l

Variable field
move exit in
special purpose
ledger

CCFR

Enhancement

Essentia
l

Validation exit
for posting in FIGL

64

CCUS,
CCHK,
CCFR,
CCGmbH
CCUK

Enhancement

Essentia
l

10

CCUS,
CCHK,
CCFR,
CCGmbH
CCUK
CCUS,
CCHK,
CCFR,
CCGmbH
CCUK
All

Form

Essentia
l

Flat file with


electronic
payment data
multiple formats
depending on
country
requirements
Check Layouts

Enhancement (user exit) in


special purpose ledger to
update the country specific
G/L account numbers for
CCSZ for calendar year
financial reporting.
Enhancement (user exit) in
general ledger to set up a
validation in CC France to
ensure that financial posting
at the end of June are not
posted in AAAs new fiscal
year.
Output of Electronic file from
Auto Payment run.

Form

Essentia
l

Customer
Statements

Correspondence to customers
on financial status and
payments due

Form

Essentia
l

Statutory and local GAAP


financial reports

CCSZ,
CCWK,

Enhancement

Essentia
l

Financial
Statements (7
versions)
Customization in
quantity
overhead
allocation in
product costing

14

CCFR,
CCUK,
CCGmbH
All
Branche

Form

Essentia
l

INTRASTAT
Reports

Enhancement

High

Gross & Net


Receivable

11

12

TBD

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 136 of 147

For check printing to pay


vendors

Enhancement (user exit) in


product costing to apply fix
amount quantity overhead
(i.e. royalty and the fix rates
in Net Billing) per unit of
finished goods output quantity
To report to the government
sales amount, units sold, and
weight by customer
To create a report on gross
receivables, estimated

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Ref
.

Reporti
ng
Units
s

Customizati
on Type

Priority

Description

Purpose

Customer
Analysis

allowances, returns and bad


debt, and net receivables by
customer
Required tax report to US
government on payment to
independent contractors
Correspondence to customers
to remind them of outstanding
payments
To notify vendors quickly of
rejected goods so that they
will pick them up promptly

13

CCUS

Form

High

1099 Tax
Reports

TBD

All

Form

Low

Dunning Letters

CCHK

Enhancement

Low

Automatic
creation of Debit
Note once
vendor goods
have been
rejected

Note: These customizations are pending the executive steering committee's final decision on
approval and priority.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 137 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

6.

List of Interfaces
The following items may be customised and the priority needs to be confirmed:
Ref.

Priori
ty

15

High

17

High

62

High

63

High

16

High

18

Medium

19

Low

Customization Description
Outgoing electronic payments to Hexagon system at HSBC
Sending Positive Pay File to Bank to confirm checks from vendors (interface with
HSBC Hexagon system)
Payroll from ADP to SAP for CCUS
Payroll from in-house program to SAP for CCHK and CCWK
Incoming Bank Statements for reconciliation with SAP bank accounts (interface
with HSBC Hexagon system)
D&B Credit Interface to SAP for customer credit history information
Auto-update of foreign exchange table with Wall St. published rates (incoming)

Note: These customizations are pending the executive steering committee's final decision on
approval and priority.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 138 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

7.

Outstanding Items/ Decisions


The following section lists the major outstanding Finance issues where resolutions are being discussed
and finalized.
Ref
.
1

XRef.
/Comm.
Log
N/A

HK00095
0

N/A

HK00075
1

HK00073
9

HK00075
2
HK00095
1

N/A
(See #10)

HK00099
2
HK00046
3
HK00030

Issue Description

Action Item

Finalization of Global Operating


Chart of Accounts
Finalization of the Group Chart
of Accounts for Consolidation

Brian is working with Larry and the Controllers to


close this item by the end of January 2004
Brian and Stanley are working with Larry and the
Controllers to close this item by the end of January
2004
Brian is working with the Business Warehouse team
and Business Representatives to close this item by
the first week of January 2004.
Decision on whether all configuration for active
companies should be set up for Peter Bauser. This
will be addressed again during the Implementation
Phase.
Janet, Brian and Larry are working with the SD team
to review these bookings in SAP. The target date for
closure January 23rd.

Finalization of characteristics
and values for Profitability
Analysis
Configuration of Peter Bauser

Methodology for recording and


analyzing , allowances (and
rebates, price protection
allowances, discounts, etc.),
returns, cogs, and the related
balance sheet items of gross
receivables, allowances,
provisions, and inventory, at
the customer and product
level, as applicable.
Explanation on frequency of
entering manual entries
against the Consolidation
Ledger as a substitute for
entering manual entries in an
Elim Consolidation Unit
Internal order usage
explanation.

Proposed solution for showing


breakdown costs of
Assortments
Proposed solution for booking

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 139 of 147

Requires system customization. The project team


successfully populated the G/L AR reserves line item
with the customer number. Investigations will
continue to determine the effort required to create
customized report to meet the requirements.
Stanley and Janet to communicate and discuss
response with Larry for closure by Wed. Dec. 3rd.
(Closed)

Decided to create a dummy Consolidation Unit for t


historical balances that exist in the Elim company to
avoid monthly manual entry.
Stanley and Janet to communicate and discuss
response with Larry for closure by Friday Dec. 5th .

Stanley demonstrated how internal orders can be


used on Dec. 10th. Subsequent to this demonstratio
Paul requested more details on the functionality of
tracking capital and operating expenses in the
Investment Management module.
The SD team is continuing to work out the solution
intercompany sales. A partial resolution has been
defined for assortments to world-wide customers. T
target closure date is TBD.
The SD team is continuing to resolve the final detail

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Ref
.

XRef.
/Comm.
Log
8

Issue Description

Action Item

returned goods

10

HK00111
5

Depreciation simulation for


future assets & collection of
capitalized costs vs. expenses
in a project

11

HK00112
3

Consolidated FI Statement for


all of Europe

12

HK00063
8

Mapping of freight activity


codes to accounting

13

HK00108
4

Add Latin America as an active


company code

14

HK00075
7

Finalize whether AAA Bbb Aust.


(Regional) Pty. Ltd is a
subsidiary of CC Corp or CC HK

of the proposed solution to use the World Wide Cod


to determine the inventory value for returned goods
The current proposal is to use bar-code technology
that will have the intelligence for the world wide cod
and serial numbering. The bar code will be applied
the batch level to track the inventory. Value added
service expenses will be booked separately from the
returned product cost in a cost center. This is to be
confirmed.
Stanley and Janet to communicate and discuss
response with Larry and Rick the advantages of
using Internal Orders vs. Investment Management t
meet these requirements. The target date for
discussion/communication is Wed. Dec. 3rd.
Two meetings were held to discuss above. Accentu
is seeking an IM expert to demonstrate the detailed
functionality of IM to meet these requirements.
Stanley and Janet to communicate and discuss
response with Larry and Rick for closure by January
28th.
Janet/Stanley are investigating the details of any
technical limitations on creating the requested repo
David Wand, Patrick Lee and Nancy Ling are workin
out the details of these requirements. Any applicab
G/L freight accounts will be added as needed.
FICO team will work with the Supply Chain team to
ensure that all SAP organizational structures are set
up appropriately for Latin America.
Closed: E-mail from Harlan Press confirmed that CC
Aust. is a subsidiary of CC HK.

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 140 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

8.

Annexes
8.1.

Annex 1: Cost Center Hierarchical Structure

Legend
Functional
Sub Group
Number Group
Administration Admin & Human Resources
99
Administration
99
Executives
91
Finance
96
Human Resources
99
Information Technology
95
Legal
94
Public Company
93
Engineering Design Engineering
10
US Design
11
US Production Design
12
Project Management
20
Quality Engineering
40
Production Engineering
30
Production
Production Line
4X
Supporting Service
49
Sales
Marketing
20
Sales
10
Sales Personnel
00
Supply Chain Bonded Warehouse
32
Customer Service
44
Material Control
49
Order Fulfillment
50
Packaging & Repacks
52
Planning
11
Purchasing
20
Return Processing & Warranty
51
Shipping
40
Store
31
SZ Export
45
Warehouse/Storage
33
WK Export
46
Customs Service
48
Supply Chain
30
Shipping Export unplanned
41
Shipping Import unplanned
42

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 141 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 142 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

CCC

Administration

Admin & Human Resources


Executives

Finance

Information Technology

Engineering

Sales

CCCA

Supply Chain
Administration

Sales

Supply Chain

CCFR

Administration

Sales

Legal
Public Company
Administration
Design Engineering
US Design

Non-Officers
Officers
Executives
Accounting
Financial Planning & Analysis
Tax
Treasury
Finance
Network Spt
SAP
Information Technology

Photo Evaluation
Software
Systems
US Design

Marketing
Sales
Sales Personnel
Supply Chain
Admin & Human Resources
Finance
Information Technology
Administration
Marketing
Sales
Sales Personnel
Customer Service
Order Fulfillment
Packaging & Repacks
Planning
Return Processing & Warranty
Supply Chain
Warehouse/Storage
Admin & Human Resources
Finance
Information Technology
Administration
Marketing

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 143 of 147

110-79900
10-79101
10-79102
10-79100
10-79601
10-79602
10-79604
10-79605
10-79600
10-79501
10-79502
10-79500
110-79400
110-79300
110-79901
110-61000
10-61101
10-61102
10-61103
10-61100
110-52000
110-51000
110-50009
110-33000
142-79900
142-79600
142-79500
142-79901
142-52000
142-51000
142-50009
142-34400
142-35000
142-35200
142-31100
142-35100
142-33000
142-33300
134-79900
134-79600
134-79500
134-79901
134-52000

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 144 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

8.2.

Finance Requirements

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 145 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

Accounts Payable
Ref #
AP-1
AP-2
AP-3
AP-4
AP-5
AP-6
AP-7
AP-8
AP-9
AP-10
AP-11
AP-12
AP-13
AP-14
AP-15
AP-16

AP-17
AP-18
AP-19
AP-20
AP-21

Requirement
Ability to add new vendors real time.
Provide a real-time interface with the Purchasing system.
Provide a real-time interface with the Inventory system.
Share the vendor file with Purchasing and Inventory.
Allow for the identification of tax exempt items.
System automatically assigns a vendor number.
Vendor lookup by name, address or vendor number.
On-line access to vendor information (e.g. balance due
information.
Ability to view purchase orders on-line.
Ability to view open and paid items on-line.
Ability to view current and YTD activity on-line by account.
Provide inter-company, inter-divisional processing and
transferring.
Support user defined posting cycles.
Provide automated 3-way matches of the invoice, purchase
order/requisition and receiving report.
Produce a discrepancy report to identify unmatched
receiving reports, purchase orders or invoices.
Display historical vendor payments in chronological order.

Nice Not
to Impor Requirement Requirements Addressed
Must Have Have tant Comments in the Current Design?

Provide features to facilitate off-site check printing.


Post G/L either in detail or summary.
Allow transactions to be posted to a subsequent period
before the current period has been closed.
Ability to auto-assign a vendor, customer, and voucher
number.
Ability to combine a user-defined batch of invoices into a
single check for a vendor.
256783903.doc
Printed on: 1/9/2015 2:56 PM

X
X
X
X

due to HK volume
Not used today Not in Phase 1 scope
Not used today Not in Phase 1 scope
Not used today Not in Phase 1 scope
X

Yes
Yes
Yes

X
X
X
X

Yes
Yes
Yes
Yes

X
X

Yes
Yes

X
X

Not used

X
X

X
X
X

Yes
Yes
Yes
Yes*
Customisation is needed for
output of check information
as an external file via DME
(and subsequent provision to
bank)
Yes
Yes

Yes

Yes
Yes*
* SAPScript form needs to

Page 146 of 147

Global SAP Implementation Program Phase One


Prepared by: Finance Design Team
Conceptual Design Document Finance & Controlling
Approved by: XXXXXXX

256783903.doc
Printed on: 1/9/2015 2:56 PM

Page 147 of 147