Fico conceptual designdocumentv1.1

Global SAP Implementation Program – Phase One Prepared by: Finance Design TeamConceptual 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

document.doc Printed on: 5/3/2023 1:44 AM Page 1 of 164


Document Approval:

We have reviewed the contents of the Finance & Controlling Global Conceptual Design Document and agree that it represents the conceptual design of the financial processes that will be implemented in Phase One of the Global SAP Implementation Program.

This is with the understanding that the Program team has maintained, in good faith, a high level of integrity across all conceptual design documents (Supply Chain & Finance/Controlling). As a general rule, the Program team will proceed with the subsequent Program tasks and resolve design issues based on the design that is described in more detail across all conceptual design documents. The Finance & Controlling Program team will be responsible for working with the Business Representatives and Supply Chain Program team to resolve all open items/issues identified and recorded in this Finance & Controlling design document.

Signed:



Table of Contents

1. INTRODUCTION...............................................................................................................................2

1.1. AAA’S FINANCIAL PROCESSES IN SAP.......................................................................................2

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

2.1. COMPANY CODE STRUCTURE......................................................................................................22.2. SAP ENTERPRISE CONSOLIDATION (EC–CS) ORGANIZATION STRUCTURE................................22.3. CHART OF ACCOUNTS STRUCTURE..............................................................................................22.4. ASSET ACCOUNTING STRUCTURE................................................................................................22.5. CONTROLLING ORGANIZATIONAL STRUCTURE............................................................................22.6. COST CENTER STRUCTURE...........................................................................................................2

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

3.1. FINANCIAL ACCOUNTING GLOBAL SETTINGS..............................................................................23.1.1. FI Document Type/ Number Range.....................................................................................23.1.2. Currency..............................................................................................................................23.1.3. Exchange Rates....................................................................................................................23.1.4. Fiscal Year Variant..............................................................................................................23.1.5. Opening and Closing Posting Periods................................................................................2

3.2. GENERAL LEDGER........................................................................................................................23.2.1. GL Master Data...................................................................................................................23.2.2. Operating Chart of Accounts...............................................................................................23.2.3. Country-Specific Chart of Accounts....................................................................................23.2.4. Special Purpose Ledger for CCSZ.......................................................................................23.2.5. GL Master Data Maintenance.............................................................................................23.2.6. Multiple Reporting Views for AAA......................................................................................2

3.3. ACCOUNTS RECEIVABLES............................................................................................................23.3.1. Customer Master Maintenance............................................................................................23.3.2. Document Type....................................................................................................................23.3.3. Trade Customer Master Data Maintenance........................................................................23.3.4. Non-Trade/ Sundry Customer Master Data Maintenance...................................................23.3.5. Payment Term......................................................................................................................23.3.6. Accounts Receivable Transaction Posting...........................................................................23.3.7. Accounts Receivable Periodic Processing...........................................................................2

3.4. ACCOUNTS PAYABLE...................................................................................................................23.4.1. Vendor Master Maintenance...............................................................................................23.4.2. Document Type....................................................................................................................23.4.3. Trade Vendor Master Data Maintenance............................................................................23.4.4. Non-Trade/ Sundry Vendor Master Data Maintenance......................................................23.4.5. Payment Terms....................................................................................................................23.4.6. Accounts Payable Transaction Posting...............................................................................23.4.7. Blocked Invoices..................................................................................................................23.4.8. Accounts Payable Period Processing..................................................................................2



3.5. INTERCOMPANY AP / AR.............................................................................................................23.5.1. Authorisation.......................................................................................................................2

3.6. ASSET ACCOUNTING....................................................................................................................23.6.1. Chart of Depreciation:........................................................................................................23.6.2. Depreciation Area:..............................................................................................................23.6.3. Asset Class:..........................................................................................................................23.6.4. Asset Number Range :.........................................................................................................23.6.5. Asset Depreciation Methods:...............................................................................................23.6.6. Asset Master Maintenance:.................................................................................................23.6.7. Asset Transactions...............................................................................................................2

3.7. COST CENTER ACCOUNTING........................................................................................................23.7.1. Cost Center Structure..........................................................................................................23.7.2. Statistical Key Figures.........................................................................................................23.7.3. Overhead Allocation............................................................................................................23.7.4. Re-posting of cost................................................................................................................23.7.5. Period End-Closing.............................................................................................................2

3.8. INTERNAL ORDER.........................................................................................................................23.8.1. Order Master Data Creation...............................................................................................23.8.2. Order Actual Transaction Posting.......................................................................................23.8.3. Month End Process..............................................................................................................2

3.9. PRODUCT COSTING.......................................................................................................................23.9.1. Logistics Master Data..........................................................................................................23.9.2. CO Master Data..................................................................................................................23.9.3. Summary of Product Cost Approaches................................................................................23.9.4. Activity type prices planning...............................................................................................23.9.5. Percentage Overhead Rates Maintenance...........................................................................23.9.6. Quantity Overhead Rates Maintenance...............................................................................23.9.7. Cost Estimate Calculation...................................................................................................23.9.8. Standard Price Update from Standard Cost Estimate – Mark & Release..........................23.9.9. Standard Cost Estimates for Single Use Bbb (SUC)...........................................................23.9.10. Production Order Processing for Semi-finished Goods......................................................23.9.11. Production Order Processing for Finished Goods..............................................................2

3.10. PROFITABILITY ANALYSIS........................................................................................................23.10.1. Organisation Unit in COPA................................................................................................23.10.2. COPA Method Deployment.................................................................................................23.10.3. COPA Structure - Characteristics.......................................................................................23.10.4. COPA Structure – Value Fields...........................................................................................23.10.5. Actual Value Flow into COPA.............................................................................................2

3.11. BUDGETING/PLANNING............................................................................................................23.11.1. SAP R/3 modules deployed for Annual Budgeting..............................................................23.11.2. Plan Version........................................................................................................................23.11.3. Planning Layout...................................................................................................................2

3.12. CASH MANAGEMENT...............................................................................................................23.12.1. Common information and differences between Cash Position and Liquidity Forecast......23.12.2. Memo Records.....................................................................................................................2



3.12.3. Cash Position.......................................................................................................................23.12.4. Liquidity Forecast................................................................................................................23.12.5. Integration with Special GL transactions (FI-GL)..............................................................23.12.6. Electronic Bank Reconciliation...........................................................................................23.12.7. Cash Concentration.............................................................................................................2

3.13. CONSOLIDATION PROCEDURES................................................................................................23.13.1. Consolidation Units.............................................................................................................23.13.2. Consolidation Groups..........................................................................................................23.13.3. Consolidation Chart of Accounts and Financial Statement Items.......................................23.13.4. Design Highlights................................................................................................................23.13.5. Data Collection Process......................................................................................................23.13.6. Consolidation Process.........................................................................................................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. ANNEX 1: COST CENTER HIERARCHICAL STRUCTURE................................................................28.2. Finance Requirements.................................................................................................................2



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. AAA’s Financial Processes in SAP

All of AAA’s 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 Receivableo Accounts Payableo Asset Accounting

Controlling:o Overhead Cost Controllingo Product Costingo Profitability Analysis

Treasury – Cash Management Enterprise – Consolidation

Note: Business Warehouse will have a separate Design Document. Planned time for gathering all BW requirements is 31 Dec., 2003.



Figure 1.1


Product Cost Controlling Product Cost Controlling

Profitability Analysis Profitability Analysis

C

onsolidation

Profitability segment

Financial Accounting

Financial Accounting

Asset Revenues FI FI Expense

Overhead Cost Controlling Overhead Cost Controlling

Cost centers

Activity types Processes

Sales orders

Projects

Warehouse production

Internal orders

Material valuation Material valuation

Cost Element Accounting Cost Element Accounting

CO CO PA PA

CO CO OM OM

CO CO CEL CEL

EC- CS

CO CO PC PC

AA Asset Accounting

Concord SAP FI/CO Modules

Human Resources

HR Human Resources

HR S&D S&D Materials Management

Materials Management Production Production MM SD PPIntegration with

Logistics Modules:

TR Treasury Cash Management


2. Finance Enterprise Organizational Structures in SAP

All financial enterprises must identify organizational structures in SAP that will be the foundation for how all financial transactions will be reported. These organizational structures reflect the legal and managerial organizations that support external and internal financial reporting. The organizational structures described in this section are global and will affect all Reporting Units in AAA. They are the:1) Company Code Structure2) Consolidated Company Structure3) Chart of Accounts Structure4) Asset Accounting Structure5) Controlling Structure6) Cost Center Structure

2.1. Company Code Structure

Company Codes generally represent legal entities within the Corporation that provide external financial statements such as Balance Sheet and Operating Income Statement reports. Each Company Code must have a complete set of accounting records for reporting purposes.

AAA has identified sixteen Company Codes, ten of which are active and six dormant. Note: Not every AAA company code represents a legal entity. AAA Latin America and AAA Keystone Graphics are divisions that belong to the legal entity AAA Keystone Sales Corp. AAA Henggang represents the factory that belongs to AAA Shenzhen.

A change request has been submitted to make Latin America an active company code. This change will be addressed in separate documentation and is outside the scope of this design document.

The proposed German acquisition will be handled as part of a change request.

See Figure 2.1.



Figure 2.1

2.2. Enterprise Consolidation (EC–CS) Organization Structure

The Enterprise Consolidation structure facilitates the procedures that create Consolidated Financial Statement reports for all AAA Reporting Units. The Consolidation structure is arranged to allow consolidated financial reports for Global AAA Bbb Corp., all European Reporting Units, and subsidiary group reports for CC UK, CC Germany and CC Hong Kong. See Figure 2.2.

AAA Australia will be shown as wholly owned by CCHK and its name will be changed to reflect the correct legal name, AAA Bbb Aust. (Regional) Pty. Ltd.

Consideration is being given to configure a dummy Consolidation Unit for the Legacy ‘Elim company’. This Consolidation Unit will house the historical balance sheet Elim data and avoid the need to manually re-enter these data every month. The dummy Consolidation Unit will be dormant once AAA goes live on SAP. Future elimination postings will occur in the active Consolidation Units using the consolidation procedures.

Investigations are in progress to determine the best way to generate consolidated financial reports for all of Europe.


Finance Organizational StructureSAP Company Codes

Concord Camera Corp.

SAP Code 1000


SAP Code 1000

Concord Keystone Sales

Corp.

SAP Code 4100Concord

Keystone Sales Corp.

SAP Code 4100

Concord Camera Canada

SAP Code 4200



Camera(Europe) Limited



SAP Code 3100

Concord Camera France

S.A.R.L


Camera France S.A.R.L


Camera HK Limited


Camera HK Limited

SAP Code 5100

Concord HenggangElectronics

Factory


HenggangElectronics

Factory

SAP Code 5200ConcordShenzhenLimited


SAP Code 5300

Concord Camera GmbH

SAP Code 3300

Concord Camera GmbH

SAP Code 3300

(US)

(US) (Canada) (UK and Northern Ireland)

(Germany) (France) (HK)

(PRC) (PRC)

Concord Keystone Graphics

SAP Code 4400Concord Keystone Graphics

SAP Code 4400

Concord Latin America

SAP Code 4300


SAP Code 4300

StarprintCorp.

SAP Code 4500

StarprintCorp.

SAP Code 4500

(US) (US) (Latin America)

Concord Camera Hungary

SAP Code 3500Concord Camera Hungary

SAP Code 3500

(Hungary)

Legend: Grey highlighted box represents a dormant company

Goldline(Europe) Limited

SAP Code3200

(UK and Northern Ireland)


SAP Code3200


Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Bauser

SAP Code3500

(Germany)


SAP Code 4300

Concord

SAP Code 6100

(Australia)

Australia

Finance Organizational StructureSAP Company Codes


SAP Code 1000


SAP Code 1000


Corp.


Keystone Sales Corp.

SAP Code 4100


SAP Code 4200






SAP Code 3100


S.A.R.L


Camera France S.A.R.L


Camera HK Limited


Camera HK Limited

SAP Code 5100


Factory


HenggangElectronics

Factory



SAP Code 5300

Concord Camera GmbH

SAP Code 3300

Concord Camera GmbH

SAP Code 3300

(US)


(Germany) (France) (HK)

(PRC) (PRC)


SAP Code 4400Concord Keystone Graphics

SAP Code 4400


SAP Code 4300


SAP Code 4300

StarprintCorp.

SAP Code 4500

StarprintCorp.

SAP Code 4500

(US) (US) (Latin America)


SAP Code 3500Concord Camera Hungary

SAP Code 3500

(Hungary)



SAP Code3200



SAP Code3200


Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Bauser

SAP Code3500

(Germany)


SAP Code 4300

Concord

SAP Code 6100

(Australia)

Australia


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

China’s statutory law further stipulates that Financial Statements must fall within the calendar year of January to December, in contrast to AAA’s fiscal year of July to June. Creating calendar year Financial Statement reports will be supported by special configuration in the Special Purpose Ledger. Although the French and German governments allow fiscal year reporting from July to June, they have a stipulation that the end of the fiscal year must be on June 30th, in contrast to AAA’s 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 AAA’s 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 30th, then every posting in



SAP Code 1000

[100%]

Concord Keystone Sales Corp.

SAP Code 4100

[100%]


SAP Code 4200

[100%]

Consolidate Subgroup CCEurope

SAP Code CG3000

[100%]

Consolidate Subgroup

(CCGMBH)

SAP Code CG3300

[100%]

Concord Camera France S.R.R.L

SAP Code 3400

[100%]

Consolidate Subgroup (CCHK)

SAP Code CG5100

[100%]

Starprint Corp.

SAP Code 4500

[100%]


SAP Code 3500

[100%]


SAP Code 4400

[100%]


SAP Code 4300

[100%] [100%]

Concord Australia

SAP Code 6300

(US)

(US) (Canada )

Concord Camera (Europe) Limited

SAP Code 3100

[100%]

(UK and NothernIreland)

Goldline (Europe) Limited

SAP Code 3200

[100%]

(UK andNothernIreland)

Concord Camera (CCGMBH)

SAP Code 3300

[100%]

(Germany)

Peter Bauser

SAP Code 3600

[100%]

(Germany)

(Europe) (Germany) (France)

Concord Camera HK Limited

SAP Code 5100

[100%]

Concord Henggang Electronics

Factory

SAP Code 5200

[100%]

Concord Shenzhen Limited

SAP Code 5300

[100%]

(PRC) (PRC)

(HK) (US) (Hungary) (US) (Latin America) (Australia)

These consolidation units will only store historical data; will have no further activity.


SAP Consolidate Units &Consolidation Groups

ConsolidationConsolidationGroupGroup(Country)(Country)[Ownership [Ownership Percentage]Percentage]

Consolidation Unit/Company(Country)Ownership Percentage


SAP Code 1000

[100%]

Concord Keystone Sales Corp.

SAP Code 4100

[100%]


SAP Code 4200

[100%]

Consolidate Subgroup CCEurope

SAP Code CG3000

[100%]

Consolidate Subgroup

(CCGMBH)

SAP Code CG3300

[100%]

Concord Camera France S.R.R.L

SAP Code 3400

[100%]

Consolidate Subgroup (CCHK)

SAP Code CG5100

[100%]

Starprint Corp.

SAP Code 4500

[100%]


SAP Code 3500

[100%]


SAP Code 4400

[100%]


SAP Code 4300

[100%] [100%]

Concord Australia

SAP Code 6300

(US)

(US) (Canada )

Concord Camera (Europe) Limited

SAP Code 3100

[100%]

(UK and NothernIreland)

Goldline (Europe) Limited

SAP Code 3200

[100%]

(UK andNothernIreland)

Concord Camera (CCGMBH)

SAP Code 3300

[100%]

(Germany)

Peter Bauser

SAP Code 3600

[100%]

(Germany)

(Europe) (Germany) (France)

Concord Camera HK Limited

SAP Code 5100

[100%]

Concord Henggang Electronics

Factory

SAP Code 5200

[100%]


SAP Code 5300

[100%]

(PRC) (PRC)

(HK) (US) (Hungary) (US) (Latin America) (Australia)

These consolidation units will only store historical data; will have no further activity.


SAP Consolidate Units &Consolidation Groups

ConsolidationConsolidationGroupGroup(Country)(Country)[Ownership [Ownership Percentage]Percentage]

Consolidation Unit/Company(Country)Ownership Percentage


June will not post beyond AAA’s 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.3Note: Peter Bauser is an additional company code that is to be included for the above Chart of Accounts

2.4. Asset Accounting Structure

Asset Accounting is used for managing and supervising all existing fixed assets. Like A/R and A/P, it is also a subsidiary ledger to the General Ledger, and provides detailed fixed asset transaction information. Asset Accounting integrates with the Operating Chart of Accounts and other SAP modules such as Production Planning, Materials Management, Plant Maintenance and Investment Management. Each country will have a defined Chart of Depreciation with three Depreciation Areas – a) Book Depreciation, b) Tax Depreciation and c) Group Depreciation.



(Group depreciation is required by the system to store asset values in USD, the group currency, for company codes with local currencies that are not USD. In these companies, parallel ledger currency has been activated so that transactions are recorded in their local currency and in USD. Particularly in AAA, these companies will be in HK, China and Europe.)

All fixed asset financial transactions will post to the Book Depreciation Area. Tax depreciation methods have been defined in the Tax Depreciation Area for all Reporting Units with specific tax depreciation requirements. The Group Depreciation Area is system defined and necessary for completing all fixed asset transactions in SAP. Each Reporting Unit has specific Asset Classes associated with them. See Figure 2.4 for the Asset Accounting Structure.

Figure 2.4 Asset Accounting Structure

2.5. Controlling Organizational Structure

The Controlling Area represents the cost accounting environment where costs and revenues are managed, and internal managerial reports are generated. AAA will have one Controlling area, AAA Group, CCG. In addition to the Controlling Area an Operating Concern, AAA Group, CCG has also been defined. The Operating Concern is the main organizational unit for Profitability Analysis. It contains the tools for analyzing contribution margins of business units and market segments.

In the Controlling Structure hierarchy, the Controlling Area is under the Operating Concern and all Company Codes are linked to the Controlling Area. The Operating Concern and Controlling


Company code(s)

Chart of depreciation

Depreciation area: Book

Depreciation area: Tax

Depreciation area:

Group

Asset Classes


Area currencies have been identified as USD. See Figure 2.5.

Figure 2.3

2.6. Cost Center Structure

The standard cost center hierarchy represents the organizational structure of AAA’s 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 AAA’s legal entities, for example, Keystone Sales (CC US), CC UK, CCGermany and CC HK.

Level 3: Cost Center Groups that represent AAA’s major department categories, for example, Sales, Administration and Production.

Level 4: Cost Centers and Cost Center Groups. The Cost Centers represent departments within major department categories (Level 3 Cost Center Groups). The Cost Center Groups are other


Operating Concern (CO -PA)[SAP Profitability Analysis (CO-PA) module]


Corp.

4100


Corp.

4100


4200


4200

Concord Camera(Europe)

Limited

3100


Limited

3100


S.A.R.L

3400


S.A.R.L

3400

Concord Camera HK

Limited

5100

Concord Camera HK

Limited

5100Concord

HenggangElectronics

Factory

5200Concord

HenggangElectronics

Factory

5200

ConcordShenzhenLimited

5300


5300

Concord Camera GmbH

3300

Concord Camera GmbH

3300


(France) (Germany) (HK) (PRC) (PRC)

Controlling Area(CO)[SAP Controllingmodules]


1000


1000

(US)

Company Codes (FI)[SAP Financial Accounting modules]

Concord Group

CCG

Concord Group

CCG

Concord Group

CCG

Concord Group

CCG

Starprint Corp.

SAP Code TBD

Starprint Corp.

SAP Code 4500

(US)


SAP Code TBD


SAP Code3500

(Hungary)


SAP Code TBD

Peter Bauser

SAP Code 3600


SAP Code TBD


SAP Code4300


SAP Code TBD


SAP Code TBD

(Germany) (Latin America) (UK and Northern Ireland)


Controlling Organizational Structure


SAP Code TBD


SAP Code 3200

( (Latin America) (UK and Northern Ireland)




SAP Code TBD

Concord Camera

SAP Code 6100

(Australia))

Australia

Operating Concern (CO -PA)[SAP Profitability Analysis (CO-PA) module]


Corp.

4100


Corp.

4100


4200


4200


Limited

3100


Limited

3100


S.A.R.L

3400


S.A.R.L

3400

Concord Camera HK

Limited

5100

Concord Camera HK

Limited

5100Concord

HenggangElectronics

Factory

5200Concord

HenggangElectronics

Factory

5200


5300


5300

Concord Camera GmbH

3300

Concord Camera GmbH

3300


(France) (Germany) (HK) (PRC) (PRC)

Controlling Area(CO)[SAP Controllingmodules]


1000


1000

(US)

Company Codes (FI)[SAP Financial Accounting modules]

Concord Group

CCG

Concord Group

CCG

Concord Group

CCG

Concord Group

CCG

Starprint Corp.

SAP Code TBD

Starprint Corp.

SAP Code 4500

(US)


SAP Code TBD


SAP Code3500

(Hungary)


SAP Code TBD

Peter Bauser

SAP Code 3600


SAP Code TBD


SAP Code4300


SAP Code TBD


SAP Code TBD

(Germany) (Latin America) (UK and Northern Ireland)




SAP Code TBD


SAP Code 3200

( (Latin America) (UK and Northern Ireland)




SAP Code TBD

Concord Camera

SAP Code 6100

(Australia))

Australia

SAP Code 6100

(Australia))

Australia


department categories that are further sub-divided into more specific departments. Examples of Level 4 Cost Centers are Marketing, Finance and Production Line under Sales, Administrative and Production Cost Center Groups respectively. Examples of Level 4 Cost Center Groups are Design Engineering and Quality Engineering.

Level 5: Cost Centers (departments) for Level 4 Cost Center Groups. An example is Industrial Engineering department under Design Engineering Cost Center Group.

In addition to the standard cost center hierarchy described above, alternate hierarchies can be defined specifically for reporting or allocation purposes. The European head office will be set up as an alternate hierarchy where European head office cost centers from each European company code will be grouped together as an alternate hierarchy cost center group.

Below is a summary of the Cost Center Groups on the Standard Cost Center Hierarchy. The detailed cost center information is documented in Appendix 8.1 The naming convention for Cost Center Groups and Cost Centers will be described in more detail in Section 3.7 on Cost Center Accounting.

AAA BBB COST CENTER GROUPS:

Level 1Description Level

2 Description Level 3 Description Level 4 Description

CCGAAA Bbb Grp 1000 CCC 1000-3 Supply Chain

1000-5 Sales 1000-6 Engineering 1000-611US Design 1000-7 Administration 1000-791Executives 1000-795Information Technology 1000-796Finance 3100 CCUK 3100-3 Supply Chain 3100-5 Sales 3100-7 Administration 3300 CCGMBH 3300-3 Supply Chain 3300-5 Sales 3300-7 Administration 3400 CCFR 3400-3 Supply Chain 3400-5 Sales 3400-7 Administration 4100 CCUS 4100-3 Supply Chain 4100-333Warehouse/Storage 4100-5 Sales 4100-7 Administration 4200 CCCA 4200-3 Supply Chain 4200-5 Sales 4200-7 Administration



5100 CCHK 5100-3 Supply Chain 5100-4 Production 5100-449Supporting Service 5100-44XProduction Line 5100-5 Sales 5100-6 Engineering 5100-610Design Engineering 5100-612US Production Design 5100-620Project Management 5100-630Production Engineering 5100-640Quality Engineering 5100-7 Administration 5100-791Executives 5100-796Finance 5200 CCWK 5200-3 Supply Chain 5200-4 Production 5200-449Supporting Service 5200-44XProduction Line 5200-6 Engineering 5200-610Design Engineering 5200-620Project Management 5200-630Production Engineering 5200-640Quality Engineering 5200-7 Administration 5300 CCSZ 5300-3 Supply Chain 5300-4 Production 5300-449Supporting Service 5300-44XProduction Line 5300-5 Sales 5300-6 Engineering 5300-610Design Engineering 5300-630Production Engineering 5300-640Quality Engineering 5300-7 Administration



3. Finance & Controlling Process Design Concepts

The following sections will describe the design concepts for each business financial process identified for AAA Bbb Corp.’s Global SAP Implementation for Phase 1. Each section will show the business process flow, its design concept and an overview of the master data and configuration variables that meet the design. The global system settings will also be highlighted.

The business financial processes and system settings of the Finance and Controlling modules are described in the following sections of this document: 3.1 Financial Global Settings3.2 General Ledger3.3 Accounts Receivable3.4 Accounts Payable 3.5 Intercompany Financial Transactions3.6 Asset Accounting3.7 Cost Center Accounting3.8 Internal Order 3.9 Product Costing 3.10 Profitability Analysis3.11 Budgeting / Planning3.12 Cash Management 3.13 Consolidation Procedures



3.1. Financial Accounting Global SettingsThis section describes the high level settings in Financial Accounting that affects every FICO modules.

3.1.1. FI Document Type/ Number RangeSAP module

FI Document Types

No. Range assignment

FI Document Type Description

Account Type

Reverse Document Type

AM AA 01 Asset posting ADKMS AAAM AF 03 Dep. postings AS AFAP KA 17 Other Vendor document AKMS KAAP KG 17 Vendor credit memo AKMS KGAP KR 19 Vendor invoice AKMS KRAP KZ 15 Vendor payment KS KZAP ZP 20 AutoPayment Posting ADKMS ZPAP ZV 20 Auto Payment clearing ADKMS ZV

AR DA16 Other Customer

document DS DAAR DG 03 Customer credit memo DS DGAR DR 18 Customer Invoice ADMS DRAR DZ 14 Customer payment DS DZGL SA 01 G/L account document ADKMS SAMM PR 48 Price change MSMM RE 51 Invoice receipt AKMS REMM RI 52 Invoice receipt-Interco. AKMS RIMM WA 49 Goods issue AMS WAMM WE 50 Goods receipt AMS WEMM WI 49 Inventory document AMS WIMM WL 49 Goods issue/delivery AMS WLSD RC 82 SD Credit Memo DS RCSD RD 83 SD Debit Memo DS RDSD RR 85 SD Credit for Return DS RR

SD RS 86SD Rebate Credit Memo DS RS

SD RV 88 SD Invoice ADS RVSD RW 81 SD Invoice-Interco. DS RWCM ZR 20 Bank reconciliation DKS ZR

The above table acts as a baseline for further discussion.(New doc types requested are: a) FI customer debit memo and b) lower of cost or market document)

Explanation Notes for Items in Table 3.1.1: SAP Modules stated on table above:

AM - Asset Management (Financial Accounting)



AP - Accounts Payable (Financial Accounting) AR - Accounts Receivable (Financial Accounting) GL – General Ledger (Financial Accounting) MM- Material Management (Logistics) SD – Sales and Distribution (Logistics) CM – Cash Management (Treasury)

MM related Document Types:* Note that Purchase Order does not have accounting impact and hence no FI document type needs to be mapped to PO document types.

‘PR’ – Price ChangePostings 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 ReceiptPostings 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 IssuePostings on Goods Issues or MM Transfer Postings. For detail definitions on Goods Issues/ Transfer Postings, please refer to MM Conceptual Design Document.

‘WE’ – Goods ReceiptsPostings on Goods Receipts with reference to Purchase Order or Production Orders. For detail definitions, please refer to MM Conceptual Design Document.

‘WI’ – Inventory DocumentPostings on Physical Inventory Differences. For detail definitions, please refer to MM Conceptual Design Document.

‘WL’ – Goods Issue/ DeliveryPostings 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 InvoicePostings of Sales Invoice from SD transactions. A Sales Order and delivery need to be completed before Sales Invoice is created in SD.

‘RW’ – SD Invoice-Interco.



Postings of Intercompany Invoice from SD transactions. A Stock Transport Order (STO) and delivery need to be completed before Sales Invoice is created in SD.

‘RC’ – SD Credit MemoPostings 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 MemoPostings 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 ReturnPostings 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 MemoPostings of Rebate Credit Memo from SD transactions. A Credit Memo Request (a special Sales Order Type) need to be raised before Rebate Credit Memo is created in SD.

Number range assignment: It links to the number range table below. FI document numbers are ‘Fiscal Year Dependent’. Meaning in interpreting a FI document, system always require users to quote the Fiscal Year involved, e.g. FY2004, Doc no. 2000000

Account Type:This is the SAP code in defining which type of account can be posted to particular type of document. This is preset by SAP system in the FI Document Type definitions. Here are the SAP Account Types:

A-Asset D-Customer K-Vendor M-Material S-General Ledger

Reverse Document Type:Upon reversal of a particular FI document, the system will use this Document Type for the reversal transaction. This way, certain reversal documents can be separately analysed, if needed. In standard SAP setting, all the reversal document types are the same as original document type.

Data Conversion Document Types:They depend on the detail flow and procedures of data conversion in AAA, thus are unique to the company and not suggested at the moment.

Document Number Ranges:The number range in the table below is defaulted from SAP and is suggested here as a reference. The exact settings depend on individual company policies.



Number Range Document no. from Document no. to

01 0000100001 000019999903 0000300001 0000399999 14 1400000000 1499999999 15 1500000000 1599999999 16 1600000000 1699999999 17 1700000000 179999999918 1800000000 1899999999 19 1900000000 1999999999 20 2000000000 2099999999 47 4700000000 4799999999 48 4800000000 4899999999 49 4900000000 4999999999 50 5000000000 5099999999 51 5100000000 5199999999 52 5200000000 5299999999 81 8100000000 8199999999 82 8200000000 8299999999 83 8300000000 8399999999 85 8500000000 8509999999 86 8600000000 8699999999 88 8800000000 8899999999

3.1.2. Currency

Currencies in SAP standard system are set as the ISO (International Organization for Standardization)1 standards, for example, USD for US dollar.

In Financial Accounting, the national currency of the company code is considered the local currency (or company code currency). From a company code view, all other currencies are then foreign currencies.

Parallel currency 2 is maintained for AAA in addition to the local currency. Group currency, USD, will be set as AAA’s 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.



During posting, the amounts are also saved in the parallel currencies. The amounts are translated automatically using Average Rate (M Rate for majority cases, EURX Rate for EU currencies translation to USD). See Section 3.1.3 for Exchange Rate Types used by AAA.

G/L account transaction figures are also updated in the parallel currencies, USD, and stored in the FI document as a separate field.

Exchange rate differences also arise in the parallel currencies.

3.1.3. Exchange Rates

Exchange rates in the system are for the following purposes:

Posting and Clearing

To translate amounts posted or cleared in foreign currency, or to check a manually entered exchange rate during posting or clearing.

Exchange Rate Differences

To determine gains or losses from exchange rate differences (between transaction rate, i.e. M or EURX, and period-end closing rate, C)

Foreign Currency Valuation

To valuate GL/ AR/ AP open items in foreign currency and foreign currency balance sheet accounts as part of the closing operations.

Exchange Rate Type

In order for the system to translate amounts into various currencies, exchange rates should be defined. For each currency pair (e.g. HKD: USD), different exchange rates can be defined and differentiated using exchange rate types.

The following exchange rate types can be defined in SAP:

Buying rate Bank selling rate Average rate

For posting and clearing, the system uses the exchange rate type M (average rate). This exchange rate type must be entered in the system and you must also enter the exchange rates for this type in the currency table. For standard SAP, the update on exchange rate is a manual process.



Historical exchange rate Key date exchange rate

(More exchange rate types may be added in the detailed design phase.)

Not every pair of exchange rates needs to be entered into the system. There are various tools you can use to automatically determine other exchange rates from existing ones.

The following tools are available:

Inversion

Inversion is the process of calculating the opposite rate from a defined exchange rate. (This is the same as direct vs. indirect rates.)

Reference Exchange Rate

Currency key used to carry out all foreign currency translations for a specific exchange rate type. Reference currency is assigned to an exchange rate type. For every other currency, exchange rate is entered in the reference currency. All other translations are carried out using the reference currency.

Usage for AAA:

It is required by SAP system that for all EUR, currency translation should be set as a Reference Currency. The algorithm has been adjusted to meet the European Monetary Union statutory guidelines. The indicator must be set if the statutory conversion rules agreed by the participating countries in the EMU are to be used. This only applies to Average Rate conversion.

Example:

EUR is set as the reference currency. To translate from GBP to EUR for day-to-day FI posting, the system uses the EURX exchange rate type specifications. All other currency translation for Day-to-Day FI postings uses M exchange rate type instead.

The following is list of Exchange Rate Type for AAA:



Exchange Rate 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 N Y

M 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 Y N

C Closing Rate Period end foreign currency valuation

- This rate applies to all currencies (including EUR)

N/A Y N

1001 Historical Exchange Rate

Consolidation - Foreign Curr Translation

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

N/A Y N

1002 Current Rate Consolidation - Foreign Curr Translation

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

N/A Y N

Note:

* Indicator that in the case of a missing exchange rate entry in the system for the required translation from one currency into another, the inverted exchange rate relationship may also be used.

** The algorithm has been adjusted to meet the European Monetary Union statutory guidelines. The indicator must be set if the statutory conversion rules agreed by the participating countries in the EMU are to be used.

Exchange rate will be maintained centrally by AAA Corporate and all AAA companies will perform business transactions using the rate updated by Corporate.

All day-to-day transactions, including FI generated Intercompany Transactions, M rate will be used. For EU related exchange rates, EURX will be used instead. Since FI generated Intercompany postings are



within the same document including entries of both companies, the exchange rate used will be the same for both entities in this case.For period-end, Foreign currency valuations, Exchange Rates stated in Exchange Rate Type ‘C – Closing Rate’ will be used (for all currencies in this case, including EU currencies) for revaluating open items held in foreign currencies (i.e. different from Company Code currency). For detail mechanism on Foreign Currency Valuation, please refer to 3.3.7 Accounts Receivable Period end Processing: Month End Open Item 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. Opening and Closing Posting Periods

Open and close posting periods for FI modules are controlled in SAP by ‘Posting Period Variant’.

Usually, only the current posting period is open for posting, all other posting periods are closed. At the end of this posting period, the period is closed, and the next posting period is opened. Special periods can be open for closing postings during the period-end closing.

Each reporting unit in AAA will be created a separate ‘Posting Period Variant’. This enables centralized or decentralised control on the Period-end closing timing. Each reporting unit can take care of their own ‘Posting Period Variant’ and be responsible for their closing timeliness, or a centralized group can perform the same activities. Once a period is closed in the branch, the ‘Posting Period Variant’ for that reporting unit can be closed and prohibit further changes in prior periods.

‘Posting Period Variant’ can also be differentiated by Account Type. Meaning opening and closing of posting periods can be controlled by account type (A-Asset, D-Customers, K-Vendors, M-Material, S-General Ledger). For example, for a specific posting period, postings can be permitted to customer



accounts, but not to vendor accounts. Further range of account can be limited in open and close period as well per account type.



3.2. General Ledger

Figure 3.1 General Overview of a Financial Posting in the General Ledger and Relevant Cost Objects

The central task of G/L accounting is to provide a comprehensive picture for external accounting. In SAP G/L accounting, all business transactions are fully integrated with all the other operational areas of a company. It ensures that the accounting data is always complete and accurate.

Essentially, the general ledger serves as a complete record of all business transactions. It is the centralized, up-to-date reference for accounts. Actual individual transactions can be checked at any time in real time processing by displaying the original documents, line items, and transaction figures at various levels such as:

Account information Journals Total/transaction figures


GL/FI Posting

FINAN

CE

Required

FI Document Header

FI document Line Items

Enter Header Detail

- Company Code- Posting/ Document Date- Reference no.- Currency/ rate

Enter FI Line Item

Is it a B/S item?

Enter- G/L Account- Amount- Text (if needed)

Enter- G/L Account

- Amount- Text (if needed)

YES

Which CO object to assign?

Enter another FI Line item

END

Cost Center

FI Posting Only Integration to CO(Controlling Only

P&L Item

Balance Sheet Item

COPA Profit Segment

Statistical Internal Order

Optional

B

A

CD

A. Overhead CostB. Cost Reducing RevenueC. Operating SaleD. Sales Reduction

Real Internal Order

Or

NO


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

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.

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



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



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

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

Group – AAA Corporate

CCSZ, CCFR

SAP specific information

SAP moduleFI-GL

(Financial Accounting – General Ledger)

EC-CS

(Enterprise Controlling – Consolidation)

FI-GL

(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 FI-GL

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



3.2.2. Operating Chart of Accounts

The Finance Team has reengineered the separate As-Is COA from all AAA companies into one single To-be global Operating Chart of Accounts (COA). This Global Operating COA will include all the necessary GL accounts for every AAA company.

In SAP, the Global Operating COA for AAA will be as follows:

Chart of Accounts [4 characters]

Description

[50 characters]Length of G/L account number

Related Group Chart of Accounts

CONO AAA Global Operating Chart of Accounts 8 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. Country-Specific Chart of Accounts

This addresses the needs of AAA France and AAA Shenzhen governmental financial reporting needs.



Since France and China government need the generation of financial statements (Balance Sheets, and Profit & Loss Statements) in predefined numbers and formats, which are different from that of AAA Global COA, Country-Specific COA are set up for these 2 countries.

In SAP, Country-Specific COA for AAA will be as follows:

Chart of Accounts [4 characters]

Description

[50 characters]Max Length of G/L account 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 CCSZ’s 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 AAA’s 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 AAA’s fiscal year setting, while that in FI-SL follows China government’s 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 CCSZ’s financial books:



CCSZ’s 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

User’s 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 AAA’s day to day operations, the maintenance of the GL Master Data is a critical process for AAA.

In accordance with the design of SAP GL Master Data, all AAA GL accounts will be created with the COA segment of the GL Master. This forms the list of Operating Chart of accounts. Company Code specific segment GL Master will only be created to necessary AAA companies, whenever it is appropriate. Only GL Master Data with COA and Company Code segments can be posted in the General Ledger in SAP.

For the detailed process flow on the GL Master Data maintenance, please refer to Figure 3.1.1 below.



CCC on the above chart refers to AAA Bbb Corporate

As stated in the FICO Prototype, for the initial request for GL account creation/ changes from subsidiaries, a standardised form need to be applied with reasons on the requests. There will be an exercise for the users in designing this new standardised form. This request form is to be processed out of SAP and proposed to utilise the current AAA Lotus Notes approval features.

Figure 3.1.1 General Ledger Master Data Maintenance

Key control points in GL Master Data:


General Ledger Master Data Maintenance

FINAN

CE

NO

YESCreate Cost

Element(FS00)

Create G/L Account centrally in COA level and Company Code

Level(FS00)

Remarks:* New G/L number should be consistent with Concord Operating COA Account Group Definition* Ensure assignment of Group Account number is correct

Define Cost Element Detail (FS00)

Enter G/L Account # and Company

Code [Create w/ Template]

Is this a P&L account?

Define G/L Account Details

A

Save Account Master Data

End


SAP GL account Usage Remarks

COA Segment 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 account’s 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 Country-Specific 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:

1. The number interval from which the account number is selected when a G/L account is created.

2. The screen layout for creating G/L accounts in the company code-specific area

For point 1 above, Account Groups will be defined according to level 1 – ‘Account Group’ of the AAA Global Operating Chart of Accounts document. The structure of the Account Groups has been confirmed during the FICO design confirmation workshop and is listed in the table below.

Account Group [4 Characters]

Description [30 Characters] GL Account range from/ to

1000 Current Assets 1000 0000-1999 99992000 Long Term Assets 2000 0000-2999 99993000 Current Liabilities 3000 0000-3999 99994000 Long Term Liabilities 4000 0000-4999 99995000 Shareholders' Equity 5000 0000-5999 99996000 Revenues 6000 0000-6499 99996100 Sales Returns and Allowances 6100 0000-6199 99996200 Cost of Sales 6200 0000-6299 99996600 Selling Expenses (Var) 6600 0000-6699 99996700 Selling Expenses (Fix) 6700 0000-6799 99997000 General & Administrative Expenses 7000 0000-7099 99997100 Interest & Finance Charges 7100 0000-7199 99997200 Interest Income 7200 0000-7299 99997300 Intercompany Income/ Expense 7300 0000-7399 99997400 Other Income / Expense 7400 0000-7499 99997500 Income Tax Expense 7500 0000-7599 99998000 GAAP Reporting/Statutory

Adjustments8000 0000-8099 9999

8100 Adjustments for Global Transfer Prices for Tax (by corporate)

8100 0000-8100 9999

9000 CO Accounts(secondary cost elements only)

9000 0000-9899 9999

9900 Data Conversion Accounts 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 as FI, therefore a specific range is reserved. These are for cost allocations that are based on secondary cost elements like statistical figures, for example, footage, number of heads per unit, etc.

Account Group 9900 is reserved for Data Conversion account creation. GL accounts will be created under this range for data conversion purposes. Details of the account range breakdown will be revisited upon the data conversion exercise is performed. This is usually necessary to offset certain G/L postings during conversion. These conversion accounts are in a specified range so that they will be excluded from business operation financial statements, and can be easily referenced for conversion data reconciliation purposes.

Integration with Enterprise Consolidation module

According to standard SAP design, when EC-CS Consolidation module is activated, users are required to enter ‘Group Account’ number in the COA segment of the GL Master Data upon new GL creation. This ensures every FI-GL postings are seamlessly integrated to the EC-CS Consolidation module to automatically generate Consolidation documents. It also ensures that every account in COA is specifically mapped to a Group Account in the Group COA for the Consolidation module.

Integration with Country-Specific COA

For CCFR and CCSZ, ‘Alternate Account’ field are set as required field. This ensures users required to enter the Country-Specific GL for all GL creation in the Company-code specific segment. For detail treatment on government required Financial Statement formats for France and PRC, please refer to Sections 3.2.3 on Country-Specific Chart of Accounts and 3.2.4 on Special Purpose Ledger for CCSZ.

Integration points with other SAP modules

For all bank accounts, the field ‘Planning level’ in the Company-Code Specific segment of GL Master links the cash flow information to SAP Treasury Cash Management (TR-CM) module. For details, please refer to Section 3.12 on Cash Management in this document.

Asset Management/ Account Receivables/ Account Payables sub-modules are integrated to FI-GL via the field ‘Reconciliation for Account Type’ in the Company-Code Specific segment of GL Master. With this indicator, the GL account can only be posted via


Block A [Operating COA]

123456....

Block B [Adjustment

GL]

Block C [Adjustment

GL]

FI-GLGL accounts

1. Day to Day Operation USGAAP

Reports

A A

2. Local GAAP

B

Concord Finance Multiple Reporting Views3. Global Tax

Planning

Reports

C

A+B+C

D

Consolida-tion COA

Reports

INFO from FI

GROUP G/L123456..E...

All adjustment GL from FI

map to dummy Group Account in

EC-CS [Not affecting Consolidation]

E

Mgmt Report (COPA)

Reports

INFO from FI

Value Fieldse.g.

*Gross Sales*Sales Deduction*COGS*Selling Expenses*G&A

...

Block A [Operating COA]

123456....

Block B [Adjustment

GL]

Block C [Adjustment

GL]

FI-GLGL accounts

1. Day to Day Operation USGAAP

Reports

A A

2. Local GAAP

B

Concord Finance Multiple Reporting Views3. Global Tax

Planning

Reports

C

A+B+C

D

Consolida-tion COA

Reports

INFO from FI

GROUP G/L123456..E...

All adjustment GL from FI

map to dummy Group Account in

EC-CS [Not affecting Consolidation]

E

Mgmt Report (COPA)

Reports

INFO from FI

Value Fieldse.g.

*Gross Sales*Sales Deduction*COGS*Selling Expenses*G&A

...


respective sub-ledger in SAP. Different indicators for ‘Reconciliation for Account Type’ are:

o A – Asset Management

o D – Accounts Receivable

o K – Accounts Payable

Inventory accounts are posted to directly by movement of materials. This occurs based on account assignment configuration between the MM and FI modules. These GL accounts are set as ‘Automatically Post Only’, which ensures the value always in sync from MM to FI.

3.2.6. Multiple Reporting Views for AAA

This section describes the approach in SAP to cater the AAA requirement of handling multiple accounting books for individual company. The following are summarized requirements:

Note: These



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



3.3. Accounts Receivables

The accounts receivable application component records and administers the accounting data of customers and this also constitutes an integral part of Sales & Distribution module. All postings in accounts receivable are also recorded directly in the general ledger. Different G/L accounts are posted to depending on the transaction involved (for example trade debtors).

3.3.1. Customer Master MaintenanceCustomer 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 moduleb. Create either in Accounting or SD module only

Customer Master Data are divided into 3 areas:

a. General datab. Accounting Datac. Sales Area Data

General data contains information such as Customer’s name, address, language, and phone numbers, which is shared by both FI and SD module. Meanwhile, Account control data like the reconciliation account number in G/L accounting, Dunning procedures and the date of the last dunning notice, in which the information are purely meant for accounting purposes.

Customers who are related to the trade sales in which the sales order are required from Sales & Distribution module will require the Sales Area Data. The sales area data will contain information like Order Currency, Order processing, shipping, and billing data.

By storing customer master data centrally, you enable it to be accessed throughout your organization, and avoid the need to enter the same information twice. This central organization also prevents data from being inconsistent between different application components.

There are currently six customer groups identified in AAA Bbb. For the numbering convention please review S&D Global Design Document for reference.



Item Customer Group Relevant To SD

1 CC Sold To Party √2 CC Goods Receipts √3 CC Payer √4 CC Bill To Party √5 CC Intercompany √6 CC One Time Vendor (Staff) √

3.3.2. Document Type

Document type Description Number RangeDG Customer credit memo 1600000000-1699999999DZ Customer payment 1400000000-1499999999DR 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 AAA’s requirements.

3.3.3. Trade Customer Master Data Maintenance

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

3.3.4. Non-Trade/ Sundry Customer Master Data Maintenance

The customer master data for Sundry and Non Trade customers are basically the same as the trade customer but without the Sales Area Master Data

3.3.5. Payment Term

Payment term will serve to determine the invoices due date and the discount amount as agreed upon at the time of the sale. The payment term in the master data will default to the respective invoice document. The payment term on these individual invoices can be changed manually. Payment terms are independent of company code.

As at the current stage of the Project, the following Payment Terms have been identified:

Customers VendorsTerm Description Term Code Description



CodeCash On delivery Cash On delivery5 Days Credit 5 Days Credit7 Days Credit 7 Days Credit14 Days Credit 14 Days CreditOne Month Credit One Month Credit45 Days Credit 45 Days CreditTwo Month 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.



3.3.6. Accounts Receivable Transaction Posting

Figure 3.2.5.1 Billing/Invoicing from SD Module

Billing From Sales And Distribution Module

For normal customers’ sales, the posting of invoice amount and the cost of goods sold are issued during the billing and delivery stage from the Sales and Distribution module. Refer to the SD Global Design Document for further explanation.

Outgoing Invoice From FI-AR Module (Non Trade)

Sundry Customer, Staff advance and Inter-company Control Account

Advance may be issued to staff and this is posted through the Financial Accounting – Account Receivable module. The posting method is the similar to the GL posting but different in the document number and document type.

Credit Note


Account Receivable - Create Invoice

FINAN

CESa

les &

Di

stribu

tion

Enter Customer Line Item

(AR)

Simulate Posting

Service Provided to Customer

AR Document Posted

Enter Revenue Line Item

(G/L)Enter AR Invoice (Header Detail)

Sales Order Process

SD Billing Document


For trade related credit memos please refer to SD document. One note to point out is Finance will approve the credit memo created in SD before it is posted in the general ledger. However, for non trade-related, it will be done through the Financial Account – Account Receivable module.

Down Payment Posting

Figure 3.2.5.4 Customer Down Payment Posting

Down payment is posted into the SAP system using the special GL indicator (A). The payment item is kept at each customer’s 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


Account Receivable - Create Down payment (Customer Advance)

FINAN

CE

Receive Customer Advance

Enter Down payment Details

(F-29)Simulate Posting Post Document

Customer Down payment Clearing(F-39)

Manual Process

Simulate Posting Post Document


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 Rates (%) Output/VAT Tax Codes

Code Description

CCUK 0.017.50.00.00.0

A0A1A3A4A5

Exempt from output VATStandard output VATDelivery of goods in EUServices within the EUSubcontracting within EU

CCGermany 0.016.07.00.00.00.0

A0A1A2A5A6A7

Exempt from output VATOutput VATDomestic Output VATEU exempt VAT - servicesDelivery of goods in EUSubcontracting within EU

CCFrance 0.017.0

A0A1

Exempt from output VATOutput VAT

CCCorp 0.06.0

O0O1

Exempt from output taxOutput tax

CCCanada 0.07.0

GJAJ

Sales GST Exempt, Sales GST applicable

CCKeystone 0.0 O0 Exempt from A/R sales tax(sales tax is always 0%)

CCHK 0.0 A0 Tax exemptCCWK 0.0

17.0X0X1

Exempt form output taxOutput tax

CCSZ 0.017.0

X0X1

Exempt from output taxOutput tax

Each Branch will use one G/L account for tax. Invoices for EU and non EU sales will contain the customer VAT registration number and the Reporting Unit VAT



registration number for the tax exemption to be realized. Customer VAT numbers are set up in the customer master record and will default into the transactions. This will allow VAT reporting to meet statutory requirements.

Further analysis of the various sales tax applications will occur during Detailed Design.



Incoming (Customer) payment

Figure 3.2.5.7 Accounts Receivable Payment

Currently, there are several payment terms being used in AAA Bbb, among the current available terms are Down Payment, Full Payment and Post Dated. For down payment and full payment, the customers may use different payment methods such as Cheque Receipt and Bank Transfer.

Regardless of the payment methods being used by the customer for payment, the AAA Bbb accounting staff will use the post with clearing function to offset the customer’s open item against the bank or bank clearing account.

Posting With Clearing is done by entering the document line items and then selecting the open items that need to be cleared. Once the total amount of selected open items equals the amount of entered line items, the system will post and clear the open items.



In clearing these items, the system will assign a clearing document number and the date on which they were cleared. Open item management ensures that all items that have not yet been cleared are available in the system. Only after every open item in a document is cleared can a document be archived.

Partial and Residual Payment

In SAP, user can define the tolerance limit for system to accept any payment difference. Please refer to AP for AAA’s tolerance range. SAP provides the flexibility in accepting any part payment in 2 methods, Partial Payment and Residual Payment.

The difference between the Partial payment and Residual Payment are as follows:

a. Partial payment will keep the original invoice line item open until the full amount has been cleared. Meanwhile a cleared new line item will be created for the paid amount.

b. Residual payment will clear the original invoice and create a new line item and document with the unpaid amount to replace the original invoice.

Both functions are available in the current system. However, the decision on which function to use depends on how the user prefers to see the line item in the customer records. Currently, the partial payment function will be more appropriate to use at AAA Bbb.

Full Payment

For full payment by mailing cheques, the account department will post and clear the customer open items against the Bank Clearing Receivables account. Upon clearance by the bank, the account staff will perform a journal adjustment to clear the Clearing account to the Bank Account.

For telegraphic transfer, WIRE transfer incoming payments and direct bank-in, the customer will normally inform the accounting staff of their intention to pay. They will also fax or send in their bank in slip as proof of payment. The account staff will post and clear the customer items upon the confirmation from the bank of payment clearance.

3.3.7. Accounts Receivable Periodic Processing

Dunning/ Reminders To Customers

Dunning letters are actually the reminders sent to customers for due payment. The level of dunning letters and the days interval for each level still need to be identified



Generate Customer Statement

AAABbbThere will be two types of customer statement in AAA Bbb. One internally which will be used between branches and one which will be used for external customers.

Month End Open Item Revaluation

Foreign currency transactions may be posted at a different rate to the current month end rate. Thus in preparing the current month Balance Sheet, a revaluation process needs to be done.

In order to perform the revaluation in SAP, you must always specify a Valuation method. This specifies exactly which type of valuation will be carried out i.e. based on which currency type and how detailed the resulting list for the valuation is to be.

Exchange rate differences resulting from the valuation of open items and foreign currency balance sheet accounts are automatically posted to specific accounts assigned during the configuration. The amounts can be either a gain or loss, and are, therefore, posted to either a revenue or expense account stored under a special key.

The unrealized gain or loss is the difference between the exchange rate posted at the time of booking the invoice and the current month end exchange rate. A reversal of this booking will be automatically created for next month to eliminate this gain or 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.

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 Vendors with PO √2 Intercompany √3 One Time Vendor √4 Vendors without PO5 Boards of Directors6 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:

Vendor’s name, address, language, and phone numbers Tax numbers Bank details Account control data like the number of the G/L reconciliation account for the vendor

account Payment methods and terms of payment set up with the vendor Purchasing data



Withholding tax information, for example 1099 tax information

In the Materials Management module, the vendors are considered as the suppliers.

3.4.2. Document Type

Document type Description Number RangeKZ Vendor payment 1500000000-1599999999KG Vendor credit memo 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. Trade Vendor Master Data Maintenance

• Please refer to Vender Master Data Maintenance in Material Management module

3.4.4. Non-Trade/ Sundry Vendor Master Data Maintenance

The vendor master data for Sundry and Non Trade vendor are basically the same as the trade customer but without the Purchase Organisation Master Data

3.4.5. Payment Terms

Payment terms are normally agreed upon by the purchasing department and the vendors. A range of payment terms will be maintained in system. See the table below for payment terms that are identified at the current stage.

Customers VendorsTerm Code

Description Term Code Description

Cash On delivery Cash On delivery5 Days Credit 5 Days Credit7 Days Credit 7 Days Credit14 Days Credit 14 Days CreditOne Month Credit One Month Credit45 Days Credit 45 Days CreditTwo Month Credit Two Month Credit14 days 2%, 30 net 14 days 2%, 30 net14 days 3%, 30 net 14 days 3%, 30 net



14 days 5%, 31 net105 days 3%, 120 net60 days net 60 days net55 days net30 days 3%, 45 days net25. Of overnext month = between 56 and 85 days/ 3% 10. Of next month / 3% 45 days 3%, 60 net15. Of next month / 3%

With the availability of the SAP system in the future, the Purchasing Department will initiate the creation and maintenance of the Basic and Purchasing views of vendor master data. They will subsequently inform the Accounts Department to maintain the Accounting and Payment views.

The purpose of dual level creation is mainly to smoothen and fasten the Purchasing process without having to wait for the Accounting staff to update the vendor master record. As soon as the Basic and Purchasing views are maintained, purchase orders can be issued and goods receipts can be processed.

Accounting Department must maintain the Accounting view for newly created vendors before the three-way matching of Invoices to purchase orders and goods receipts can be processed.

3.4.6. Accounts Payable Transaction Posting



Figure 3.3.2.1 Three-Way Matching Invoice Verification

Figure 3.3.2.5A Automatic Outgoing Payments


Process Invoice Verification

Fina

nce

Purc

hase

SAPPurchase

Order

SAP GoodsReceipt

Document

SaveDocument

(MIRO)

InvoiceVerificationDocument

Price & Qty withintolerance allowed(3-way matching)?

BlockInvoice forPayment

YESSimulatePosting(MIRO)

A

NO

Receive &ApproveVendorInvoice Enter

Invoice

3 Ways Matching:Match Invoice withPO Price & GR Qty

- Invoice auto-blocked by system- Can be manually blocked- Invoice can be parked until furtherinvestigation completed

Account Payable- Automated Payment

FINA

NCE

A

InvoiceVerificationDocuments

Enter/RevisePaymentCriteria(F-110)

Is Payment ProposalCorrect?

DeletePaymentProposals

(F-110)

NO

ExecutePayment Run

(F-110)

Create PaymentProposals

(F-110)

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

CreatePaymentOutput(F-110)

BYES

ReleaseBlocked

Invoices readyfor payment


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

Cr. Goods Receipt \ Invoice Receipt (GRIR)

At the time of Invoice Matching, the posting will be


Account Payable - Automated Payment (Cont’d)

B

Print Checks

Create TransferFile

Create WireFile

Create PositivePay File

Transmit EFTFile to the Bank

Transmit WireFile to the Bank

Review CheckRegister

Receive EFTconfirmationfrom bank

Receive Wireconfirmatonfrom bank

PaymentMethod? Transfer

Cheque

Wire


Dr. GRIRCr. 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 document’s Reference field.

Debit Note/Credit Memo

There are three scenarios of goods returned to vendors:

a. Returned and pending the delivery for replacementb. Returned before invoice verification and cancelled the replacementc. Returned after invoice verification and cancelled the replacement

All purchasing returns will be done through “return to vendor” in Material Management module. A return note will be given to the accounts department to clear against the subsequent payment when it is due. The main difference between these 3 scenarios is whether a debit note/credit memo is required to be issued from the system.



As in normal circumstances, debit notes are only required for scenario C where the invoices were already billed at order quantity above the actual quantity received.

Input Tax / Input VAT / Use Tax

The input tax will generally be shown in the Material Management module however for invoices created in FI, users will have to manually choose the tax rate.

Branches Rates (%)

SAP Input/ VAT Tax Codes

Tax Code Description

CCUK 0.017.50.00.00.0

V0V1V3V4V5

Exempt from input VATStandard input VATDelivery of goods in EUServices within the EUSubcontracting within EU

CCGermany 0.016.7.016.07.016.07.00.0

V0V1V2E1E2E3E4E7

Exempt from input VATInput VATDomestic Input VATAcquistion Tax EU delivery of goodsAcquisition Tax EU delivery of goodsAcquistion Tax EU subcontractingAcquisition Tax EU subcontractingAcquisition Tax – Acquisition within EU

CC PeterB 0.016.07.016.07.016.07.00.0

V0V1V2E1E2E3E4E7

Exempt from input VATInput VATDomestic Input VATAcquistion Tax EU delivery of goodsAcquisition Tax EU delivery of goodsAcquistion Tax EU subcontractingAcquisition Tax EU subcontractingAcquisition Tax – Acquisition within EC

CCFrance 0.017.0

V0V1

Exempt from input VATInput VAT

CCCorp 0.06.00.06.0

I0I1U0U1

Exempt from input taxInput taxExempt from A/P use taxA/P use tax

CCCanada 0.07.0

TBD

PJIJSJ

A/P GST Exempt, A/P, GST applicableSelf assessment, GST

CCKeystone 0.06.0

I0I1

Exempt from input taxInput tax



0.06.0

U0U1

Exempt from A/P use taxA/P use tax

CCHK 0.0 V0 Tax exemptCCWK 0.0

0.0J0J1


CCSZ 0.017.0

J0J1


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

Description Payment Medium Comments

E Cash N/A Cash PaymentC Cheques Cheque printed in-house or out-

house, and an electronic file with cheque information (‘positive-pay’ file)

The ‘positive-pay’ file will be sent to the bank to validate the printed cheques when deposited by the vendors.

T Teletex Transfer

N/A Manual Payment handed to bank (usually foreign currency payment to vendor who does not have an account with HSBC)

W Electronic Funds Transfer

Electronic payment file with different formats for different countries:US – ACH format

All other countries need to be confirmed by users whether interface directly from SAP to

Electronic payment files will be sent to HSBC bank via Hexagon



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



In SAP, users can define the tolerance limit for system to accept any payment difference. The tolerance will be based on the lesser of amount or percentage rate.



Payment Difference for Vendor / Customer Based on Local Currency Amount PercentageBranch Currency Gain Loss Gain LossUK GBP 5 5 1 1Germany EUR 5 5 1 1Keystone USD 0 0 0 0Corp USD 0 0 0 0HK HKD 0 0 0 0WK RMB 0 0 0 0SZ RMB 0 0 0 0France EUR 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. Accounts Payable Period Processing



Month End Open Item Revaluation

Please refer to AR Month End Open Item Revaluation under Section 3.3.7.

3.5. Intercompany AP / AR (FINANCE ONLY)

Several companies are involved in an intercompany transaction. The system will post a separate document with its own document number in each of the company codes. A common cross-company code number links individual documents together. The system generates line items automatically (receivables and payables arising between company codes) in order to balance the debits and credits in each document.

Figure 3.4 Intercompany Transactions

Company OneDr. Expense / Balance Sheet account for Company One CR. Intercompany AP

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


Intercompany Invoice/ Payment - Create non-trade Invoice

FINA

NCE

ApprovedIntercompanyTransaction

Create GLPosting

(Enter HeaderDetail)

EnterTransaction

Details in Co. 1Line Item 1

EnterTransaction

Details in Co. 2Line Item 2

SimulatePosting

Review auto-generated

IntercompanyPayables/

Receivables

Post FIDocument

FI document +Cross Company

documentgenerated

END


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 AccountingThe Asset Accounting System (FI-AA) in SAP R/3 is used for managing and supervising all the existing fixed assets in your enterprise. It also serves as a subsidiary ledger to the FI General Ledger, proving detailed information on the fixed assets transactions.

However, according to the requirements in AAA, the Fixed Asset system has the following limitations:

The Fixed Asset system is designed to manage the existing assets that have already been purchased. Management of possible future assets or capital investment cannot be done in fixed asset and is supposed to be done in Investment Management (IM) module

Fixed Asset system generally does not provide linkage with a material or product in Material Management (MM). To link a fixed asset record to a material master, a work around solution is proposed by using a PP master data called Production Resource Tool (PRT).

The Fixed Asset system does not support flexible “what if” scenario analysis. Changes in depreciation method or useful life is available but are generally referring to actual changes instead of changes for simulation only

3.6.1. Chart of Depreciation:A Charts of Depreciation is the highest level organization structure in SAP R/3 Asset Accounting which holds all the asset accounting relevant settings such as Depreciation Areas and the depreciation methods that are specific to a country. Since different companies in the same country are subject to the same legal regulation of fix assets depreciation, Chart of Depreciation is usually country specific and more than one



Company Codes could be assigned to a single Chart of Depreciation. Each chart of depreciation also includes the tax book.

Chart of Depreciation is a 3-character code that supports alpha-numeric format. As it is generally country specific, normally the coding of the Chart of Depreciation will include the country codes.

The Chart of Depreciation in the to-be SAP R/3 System in AAA will be :

Chart of Depreciation Chart of Depreciation Descriptions : Company code(s) assigned

ZHK HK Chart of Depreciation for AAA 5100ZUS US Chart of Depreciation for AAA 1000, 4100ZCA Canada Chart of Depreciation for AAA 4200ZCN China Chart of Depreciation for AAA 5200*ZUK UK Chart of Depreciation for AAA 3100ZDE German Chart of Depreciation for AAA 3300ZFR France Chart of Depreciation for AAA 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 CCHK’s 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

Depreciation areas Depreciation area description Posting to G/L

ZHK 01 Book depreciation Yes15 Tax depreciation No30 Group currency depreciation No

ZUS 01 Book depreciation Yes15 Tax depreciation No



30 Group currency depreciation NoZCA 01 Book depreciation Yes

15 Tax depreciation No30 Group currency depreciation No

ZCN 01 Book depreciation Yes15 Tax depreciation No30 Group currency depreciation No

ZUK 01 Book depreciation Yes15 Tax depreciation No30 Group currency depreciation No

ZDE 01 Book depreciation Yes15 Tax depreciation No30 Group currency depreciation No

ZFR 01 Book depreciation Yes15 Tax depreciation No30 Group currency depreciation No

3.6.3. Asset Class:Asset Classes are used to classify fixed assets into different categories according to their natures and G/L account postings. The asset class catalog is relevant in all company codes in a client. That means different companies are sharing the same set of Asset Classes in the system. However, asset classes that are not applicable to a certain Chart of Depreciation could be deactivated in that 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, 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

Asset Class Descriptions Asset No. Range (From)

Asset No. Range (To)

10010 Automobile/Truck 101 0000000 101 999999910020 Plant & Machinery 102 0000000 102 999999910030 Computer Hardware 103 0000000 103 999999910040 Computer Software 104 0000000 104 999999910050 Furniture & Fixture 105 0000000 105 999999910060 Fax and Copy Machine 106 0000000 106 999999910070 Office Equipment 107 0000000 107 999999910080 Leasehold Improvement 108 0000000 108 999999910090 Warehouse Equipment 109 0000000 109 999999910110 Building 111 0000000 111 999999910120 Mould & Tools 112 0000000 112 999999910130 Building Improvements 113 0000000 113 999999910140 Land Usage Right 114 0000000 114 999999910150 Capitalised R&D Cost After AFS (will be

amortized)115 0000000 115 9999999

20010 Asset Under Construction – Capitalizable Development Cost

201 0000000 201 9999999

40010 Asset Under Construction – Construction in Progress

401 0000000 401 9999999

3.6.5. 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 Expected useful

life (month)Book depreciation Tax depreciation

Automobile/Truck 80 Straight line 10% / 30% / 60% pool (TBD)

Plant & Machinery 120 Straight line Full allowanceComputer Hardware 36 Straight line Full allowanceComputer Software 36 Straight line Full allowance



Furniture & Fixture 80 Straight line 10% / 30% / 60% pool (To be determined)

Fax and Copy Machine 80 Straight line 10% / 30% / 60% pool (To be determined)

Office Equipment 80 Straight line 10% / 30% / 60% pool (To be determined)

Leasehold Improvement 36 Straight line 10% / 30% / 60% pool (To be determined)

Warehouse Equipment 80 Straight line 10% / 30% / 60% pool (To be determined)

Building 360 Straight line Building allowanceMould & Tools 48 Straight line 10% / 30% / 60% pool

(To be determined)Building Improvements 60 Straight line 10% / 30% / 60% pool

(To be determined)Land Usage Right 522 Straight line (To be determined)Capitalised R&D Cost After AFS (will be amortized)

24 Straight line N/A

Asset Under Construction – Capitalizable Development Cost

N/A N/A N/A

Asset Under Construction – Construction in Progress

N/A N/A N/A

Company 1000 and 4100 (US)Asset Classes Expected useful


Automobile/Truck To be determined

Straight line 5 Yr DDB HY Convention

Computer Hardware To be determined

Straight line 3 Yr DDB HY Convention

Computer Software 36 Straight line 3 Yr DDB HY Convention

Furniture & Fixture 24 Straight line 5 Yr DDB HY Convention

Fax and Copy Machine 84 Straight line 3 Yr DDB HY Convention

Leasehold Improvement 397.2 or 480 Straight line To be determined

Company 4200 (Canada)Asset Classes Expected useful


Automobile/Truck 12 Straight line Double declining ½ year method

Computer Hardware 12 Straight line Double declining ½ year method

Computer Software 12 Straight line Double declining ½ year



methodFurniture & Fixture 12 Straight line Double declining ½ year

methodFax and Copy Machine 12 Straight line Double declining ½ year

methodLeasehold Improvement 12 Straight line Double declining ½ year

method

Company 5300 (CCSZ)Asset Classes Expected useful


Automobile/Truck 60 Straight line Straight line with 10% scrap value

Plant & Machinery 120 Straight line Straight line with 10% scrap value

Computer Hardware 60 Straight line Straight line with 10% scrap value

Computer Software 60 Straight line Straight line with 10% scrap value

Furniture & Fixture 60 Straight line Straight line with 10% scrap value

Fax and Copy Machine 60 Straight line Straight line with 10% scrap value

Office Equipment 60 Straight line Straight line with 10% scrap value

Leasehold Improvement 60 Straight line Straight line with 10% scrap value

Warehouse Equipment 60 Straight line Straight line with 10% scrap value

Building 240 Straight line Straight line with 10% scrap value

Mould & Tools 60 Straight line Straight line with 10% scrap value

Building Improvements 240 Straight line Straight line with 10% scrap value

Company 3100 (UK)Asset Classes Expected useful


Computer Hardware 36 Straight line Same as book

Furniture & Fixture 60 Straight line Same as book

Building 200 Straight line Same as book



Company 3300 (Germany) Asset Classes Expected useful




Office Equipment Between 36 & 60

Straight line Same as book

Goodwill 180 Straight line Same as book

Company 3400 (France)Asset Classes Expected useful




Office Equipment 60 Straight line Same as book

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 DataGeneral 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 label2. Contains posting information such as the date of 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 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 )

Allocation Different evaluation groups available for further classification and grouping of assets for reporting and analysis purposes

Origin 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)

Depreciation areas 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

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)


AssetPRT Master

Routing

Production Order

Asset

PRTRoutin

g


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.

3.6.7. Asset Transactions

Figure 3.5.8 Asset Transactions

Asset Transactions Document Types :Standard document types available for the asset transactions are :

Document type Description UsageRE Invoice – gross 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


Asset Accounting - Asset Lifecycle Transaction

FINAN

CE

Enter Depreciation Detail (AFAB)

Save Document (AFAB)

Execute Depreciation Test Run (AFAB)

Display Log(AFBP)

Intercompany Asset Lifecycle

Defi ne T ransfer Detail .(eg. Company to Company; Asset Details)(ABT1N)

Save Document (ABT1N)

Asset Retirement

Define Asset Retirement Save Document

Month-End Asset Transactions Completed?

Post missing Asset

Transactions

NO

YESCan Retire Asset A) With Revenue (F-92)B)Without RevenueC)By scrapping (ABVAN)


AF Dep. Posting Used in depreciation postingThe 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

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 followsDr. 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 Accounting - Post Asset External Acquisition

PURC

HASE

FINAN

CE

Create Asset MasterAS01

Purchase Order Approved?

Goods Receipt to match Purchase Order

Pending for Further Advice upon discussion

NO

Asset Request

Approved

Create Purchase Order YES

Invoice Receipt to match Purchase Order/ Post Asset External

Acquisition


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

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 if”analysis 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) 1,100Cr. Revenue for asset disposal 1,100-Cr. Fix asset – acquisition cost 1,000-Dr. Accumulated depreciation 100Dr. Clearing account for asset disposal 1,100Cr. Gain/loss of fixed asset disposal 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:

Cr. Fix asset – acquisition cost 1,000-Dr. Accumulated depreciation 100Cr. Gain/loss of fixed asset disposal 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 intra-company transfer posting will be follows:

Cr. Fix asset – acquisition cost (old asset) 1,000-Dr. Accumulated depreciation (old asset) 100Dr. Fix asset – acquisition cost (new asset) 1,000Cr. Accumulated depreciation (new asset) 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 cost2. 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 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

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



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 CCHK with company code 5100 51-79100The next digit represent the 5 major functional grouping which are Administration, Engineering, being 7 Sales, being 6

51-79100


GL/FI Posting

FINAN

CE

Required

FI Document Header

FI document Line Items

Enter Header Detail

- Company Code- Posting/ Document Date- Reference no.- Currency/ rate

Enter FI Line Item

Is it a B/S item?

Enter- G/L Account- Amount- Text (if needed)

Enter- G/L Account

- Amount- Text (if needed)

YES

Which CO object to assign?

Enter another Line item

NO

END

Cost Center

FI Posting Only Integration to CO(Controlling Only

P&L Item

Balance Sheet Item

COPA Profit Segment

Statistical Internal Order

Optional

B

A

CD

A. Overhead CostB. Cost Reducing RevenueC. Operating SaleD. Sales Reduction

Real Internal Order

Or


Supply Chain being 3, Production being 4The 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 5100-791The next digit represent the 5 major functional grouping which are Administration being 7Engineering, being 6 Sales being 5Supply Chain being 3Production being 4

5100-791The 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 Germany’s 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 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 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

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

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.



3.8.3. Month End Process

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


Set tl i ng Cost s i n an I nt er nal Order - - R &D Scenar i o

FINA

NCE

R & D

Goods Recei pt/I nvoi ce

Recei pt ( wi thI / O assi gned)

FI DocumentProcessi ng(wi t h I / Oassi gned)

ExpenseVal ue Postedto I nternal

Order

Ent er AUC numberas recei ver i nset t l ement rul e

Mont h EndSett l ement

to AUC

Af terfi rst

Shi pment

Set tl ementto a real

Assets

NO

YES


3.9. Product Costing

3.9.1. Logistics Master DataThe 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

Material master (Accounting view)

Provide financial data such as inventory price of raw materials and the consumption G/L account (through account determination valuation class)

Material master (Costing view)

Provide costing calculation control parameters such as overhead group, origin group etc. (will be discussed in more details in later sections)

Routing master Provide standard production time (SPT) that is relevant for labour and production overhead calculation

BOM master Provide list of raw materials and their usage quantities for the production of the product

Purchasing info record of raw material purchase

Provide purchasing price of raw materials for raw material cost calculation when the inventory price is not yet available in the material master

Purchasing info record of subcontracting

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

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 Labour cost for bulk bbb Hour (H)CAMAOH Assembly labour overhead for bulk bbb Hour (H)CAMLOH Component labour overhead for bulk bbb Hour (H)CAMOH Other overhead for bulk bbb Hour (H)PAKLAB Labour cost for packaging Hour (H)PAKAOH Assembly labour overhead for packaging Hour (H)PAKLOH Component labour overhead for packaging Hour (H)PAKOH Other overhead for packaging Hour (H)SKCLAB Labour cost for silkscreen Hour (H)SKCAOH Assembly labour overhead for silkscreen Hour (H)SKCLOH Component labour overhead for silkscreen Hour (H)SKCOH Other overhead for silkscreen Hour (H)

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 Electronic parts in bulk bbbB2 Plastics parts in bulk bbbB3 Metal parts in bulk bbbB4 Lens parts in bulk bbbB5 Other parts in bulk bbbP1 Raw materials for packagingS1 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 No production royaltyROY1 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:



Percentage overhead key

Description Calculation base to be applied

ZMO1 Material overhead for bulk bbb All raw material costs for bulk bbb

ZLO1 Labour overhead for bulk bbb All labour costs for bulk bbbZMO2 Material overhead for

silkscreenAll raw materials cost for silkscreen

ZLO2 Labour overhead for silkscreen All labour costs for silkscreenZMO3 Material overhead for packaging All raw materials costs for

packagingZLO3 Labour overhead for packaging All labour costs for packaging

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

Description Calculation base to be applied

ZR1 Production royalty Finished goods production output quantity

ZNB1 Consumption VAT for testing battery (Net Billing only)

Finished goods production output quantity

ZNB2 Consumption VAT for testing film (Net Billing only)

Finished goods production output quantity

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.

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 Additional control

Material cost 1. Inventory valuation price from accounting view of material master2. Effective price taken from purchasing info record

Activity price Standard activity rates for the year Planning version 0

Subcontracting cost

Effective price from subcontracting purchasing info record

General overhead allocation

Percentage overhead keys and quantity overhead keys for royalty

Pricing control of costing variant for Net Billing:


Material cost 1. Inventory valuation price from accounting view of material master2. 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 A planning version different from 0 such that different standard rates could be applied

Subcontracting cost



Percentage overhead keys and quantity overhead keys for Net Billing



Pricing control of costing variant for RFQ:


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 master3. Effective price taken from purchasing info record

Activity price Standard activity rates for the year Planning version 0

Subcontracting cost



Percentage overhead keys and quantity overhead keys for royalty

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

3.9.3. Summary of Product Cost 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

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.

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 Inventory in Production Plant 5100

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.

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 planningThe 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. Percentage Overhead Rates Maintenance

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.




3.9.6. Quantity Overhead Rates Maintenance

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 user-definable validity period for each amount rates.




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 Calculation Major differenceAssembly labour Standard assembly hours X hourly

rate specific to KodakStandard rate will be different from inventory valuation rate from a


Product Costi ng - Process Overhead Rate, Acti vi ty Rate f or the next peri od

<Fun

ctio

n>

Run act ivi typri ces

cal culati on

Act i vi ty pri cescal cul ated by

the system

Cal cul atestandard

cost

B

Enter budgetedcosts of the costel ements of the

acti vi ty types i nCost Center

Pl anni ng

Enter budgetedquanti ty of the

act i vi t i es i n CostCenter Pl anning

Enter producti onoverhead rates i nto

the system


different planning versionConsumption of VAT for testing batteries

Fixed amount per unit of product Fixed amount based on quantity overhead. This item does not exist in inventory valuation

Consumption of VAT for testing film

Fixed amount per unit of product Fixed amount based on quantity overhead. This item does not exist in inventory valuation

All part costs Summation of BOM item part costs 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. Standard Cost Estimates for Single Use Bbb (SUC)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 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. Product Cost Estimates for New ProductsIn 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.

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

Raw material consumption at backflushingRaw 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


Product Costing - Process Standard Cost Estimates for the next period

FIN

AN

CE

Individual

Costing run

Yes

No

No

Current month

Error in costcalculation?

Beginning of the nextmonth

End

Sent errormessages to

production/MISdepartment for

corrections

Individualmaterial/massprocessing?

FromB

Calculatestandard cost

estimatesindividually(CK11N)

Mass Calculationby costing run(CK40N) for

Downloadstandard costestimates withcosting status

"KA"

Mark standardcost estimates

individually(CK24)

Mark standardcost estimates

(CK40N)

Downloadstandard costestimates withcosting status

"VO"Release

standard costestimates(CK40N)

Releasestandard cost

estimatesindividually

(CK24)


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 100-Dr. Raw material consumed 100

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

Labour and production overhead cost allocationIn 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) 10Cr. Labour cost absorption (from cost center) 10-Dr. Overhead cost (to production order) 20Cr. Overhead cost absorption (from cost center) 20-

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

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 129Cr. Factory output from production 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) 10Cr. General overhead cost absorption (from cost center) 10-

Similar 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 100Labour cost 10Production overhead 20General overhead 10Factory output 129--------------------------------------------Total net P&L in order 11

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 11Cr. WIP capitalisation 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 11Cr. 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 GoodsProduction 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 semi-finished goods

Raw material consumption at backflushingMaterials 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 100-Cr. Semi-finished goods inventory 200-Dr. Raw material consumed 100Dr. Semi-finished goods consumed 200

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

Labour and production overhead cost allocationThe 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) 10Cr. Labour cost absorption (from cost center) 10-Dr. Overhead cost (to production order) 20Cr. Overhead cost absorption (from cost center) 20-



Absorption of Production Cost to Inventory at Goods ReceiptThe 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 329Cr. Factory output from production 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) 10Cr. 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 200Raw material costs 100Labour cost 10Production overhead 20General overhead 10Factory 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)



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 11Cr. WIP capitalisation 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 11Cr. Factory output from production 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 11Cr. 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)




Product Costi ng - Producti on Order Peri od End Processi ngFi

nanc

e I ndi vi dualorder/massprocessi ng?

Start

I ndi vi dualprocessi ng of WI P

cal cul at i on(KKAX)

End

I ndi vi dualprocessi ng of

vari ancescal cul ati on

(KKS2)


overheadal l ocati on (KKAX)


producti on ordersettl ement (KO88)



(KKS2)







Product Costi ng - Producti on Order Peri od End Processi ngFi

nanc

e I ndi vi dualorder/massprocessi ng?

Start



End



(KKS2)







(KKS2)








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



Operating Concern

Operating Concern Description

Assignment to Controlling Area

1000 AAA Group 1000 – 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 DeploymentIn 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/ Cost of Sales information presented as

Value Fieldso Lowest level of data need to

be analysed per Profitability Segment (can be a lower level than a GL account)

Revenue/ Cost Elementso Equal to P&L account in the

Operating Chart of Accounts in SAP FI module

Major comparison of Value Fields and Revenue/ Cost Elements:



Value Fields Revenue/ Cost Elements

Level of analysis

o Each ‘Value Field’ is user-definableo Can be lower level of details than GL

accountso Can be same level as GL accounts

(1:1 relationship with accounts in FI)o Can be grouped level of GL accounts

Same level as P&L GL accounts (always 1:1 relationship with accounts in FI)

Quantity capturing/ UOM

Standard ‘Value Field’ in capturing sales quantity/ UOM

Standard field in capturing sales quantity/ UOM

Examples: Example of ‘same level as GL account’o Revenueo Promotional Expenses

Example of ‘lower level of details than GL accounts’

o Cost of Goods Manufactured - Direct Material

o Cost of Goods Manufactured - Indirect Material

o Cost of Goods Manufactured - Direct Labor

o Cost of Goods Manufactured - Indirect Labor

o GL account – Revenueo GL account – Cost of Goods Soldo GL account – Sales Allowanceo GL account – Prod. Price Varianceo GL account – Salesperson salaries o GL account – Promotional Expenseso …o And all other P&L GL accounts

posted to ‘Profitability Segment’

Reasons for adopting Costing-Based COPASAP 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 CO-PA, 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 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 booko 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.

CharacteristicsAAA Term SAP Term [Proposed]CUSTOMER TYPE Distribution Channel

[Sales Organisation]RECORDNO 1. Sales Order

2. Item No.[Sales Order Header/ Item level]

CUSTOMER_PO Customer PO number[Sales Order header level]

INVOICE NO Billing Doc No.[Billing Doc. Header level]

CUSTNMBR Customer No.[Sales Order/ Billing Doc.]

CUSTOMER SUMMARY NAME Group Key[Customer Master]

CUSTOMER NAME Customer no. Attribute[Customer Master]

SALES PERSON Sales Employee[Customised Partner]

OPERATING UNIT Company Code[BURKS]

RESPONSIBLE BRANCH Sales Office [Customer Master]

REGION Region [Customer Master - General]



CharacteristicsAAA Term SAP Term [Proposed]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]

SALES PRODUCT CODE Product Hierarchy-level 2 and 3 [5, 8 digits]

Assortment Code Material No.[Material Master]

MODEL First segment of Material Master[1st to 6th digits]

MODEL TYPE Division' in Material Master[MARA-SPART]

FILM TYPE TBC from MM/PP TeamFLIM SPEED TBC from MM/PP TeamFLASH TYPE TBC from MM/PP TeamMOTOR TYPE TBC from MM/PP TeamZOOM TYPE TBC from MM/PP TeamPower Zoom TBC from MM/PP TeamFOCUS TYPE TBC from MM/PP TeamDISPLAY TYPE TBC from MM/PP TeamSENSOR TYPE TBC from MM/PP TeamRESOLUTION (MP) TBC from MM/PP TeamPACKAGE CODE Fourth segment of Material Master

[14th to 18th digits]SILKSCREEN CODE Third segment of Material Master

[9th to 13th digits]Default Package Code N/A in SAPDefault Silkscreen Code N/A in SAPLOYALTY PROGRAM Field to be customised in Sales Order Item level

BRAND NAME TBC from MM Team [Material Master]PRODUCT LABEL TBC from MM Team [Material Master]Set Type TBC from SD TeamSet Usage TBC from SD TeamFree Goods TBC from SD TeamSHIP MODE Field TBD from Sales Order header levelThird Party Customer TBC from DebbieCUSTOMER CLASS ID Customer Gp' Customer Master - Sales View

Customer Territory Sales District' Customer Master Sales Area view

APPROVAL STATUS OF WORLDWIDE ORDER

TBC from SD Team

ITEMNUMBER TBC from SD TeamPRODUCT TYPE TBC from SD TeamSTATUS1 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 FieldsAAA Term SAP Term [Proposed]QUANTITY 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]

OTHER PACKAGE MATERIAL COST

New Value Field [from COPC]

TOTAL MATERIAL COST Calculated Field in COPA Report

SCRAP RATE New Value Field [from COPC]

SPC LABOUR COST New Value Field [from COPC]SILKSCREEN LABOUR COST New Value Field [from COPC]



Value FieldsAAA Term SAP Term [Proposed]PACKAGE LABOUR COST New Value Field [from COPC]TOTAL LABOUR COST Calculated Field in COPA ReportSPC OH COST New Value Field [from COPC]SILKSCREEN OH COST New Value Field [from COPC]PACKAGE OH COST New Value Field [from COPC]TOTAL OH COST Calculated Field in COPA ReportTOTAL GENERAL OH COST Calculated Field in COPA ReportFUJI / DIGITALROYALTY COST New Value FieldMARKETING BRAND ROYALTY New Value Field

TOTAL MANUFACTURING COSTCalculated Field in COPA Report

Freight and Duty Cost New Value FieldCOST OF GOODS SOLD PER UNIT

Calculated Field in COPA Report

GROSS PROFIT PER UNIT Calculated Field in COPA Report

CONTRIBUTION MARGIN DIG CAM T SUPP


CONTRIBUTION MARGIN REP COMM US


GROSS SALES TOTAL Calculated Field in COPA ReportNET SALES TOTAL Calculated Field in COPA ReportTotal FOB Commission Calculated Field in COPA ReportTOTAL COST OF GOOD SOLD Calculated Field in COPA ReportTOTAL GROSS PROFIT Calculated Field in COPA ReportTRANSACTIONUNITCOST TBC from SD Team

TRANSACTIONTOTALCOST TBC from SD Team

CURRENTLANDEDCOST TBC from SD Team

3.10.5. Actual Value Flow into COPAFor 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).

3.10.6. Special Treatments on ‘Responsible Branch’In AAA, there are sales deals that are recorded in CCHK’s 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: ASales Office: CCUK

Customer: BSales Office: CCHK

Sales transactions of both Customer A and B are booked in CCHK’s book. This impacts the FI-GL. 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:CCUSCCCACCUKCCGECCFRCCJP*

* 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. Sale Allowances/ Provisions HandlingFor 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. ‘Partner Functions’ of Customer MasterFor 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.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)

Definitions Usage in SAP

Sold-to-Party o A person or company that o SD: Generate Sales Order



places an order for goods or services.

o Contains data on sales, such as the assignment to a sales office or a valid price list

o 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

Ship-to Party o A person or company that receives goods.

o The ship-to party may not necessarily be the sold-to party, the bill-to party, or the payer.

o Contains data for shipping, such as unloading point and goods receiving hours

o SD: Generate Delivery

Bill-to Party o A person or company that receives the invoice for a delivery or service

o The bill-to party may not necessarily be the payer of the bill.

o Contains the address and data on document printing and electronic communication

o SD: Generate Billing

Pay-to Party o The payer may not be the bill-to party.

o A person or company that pays the bill.

o Contains data on billing schedules and bank details

o FI: Accounting Posting of the SD Billing document will be updated with ‘Pay-to Party’ no. Therefore it is this number which will impact FI.

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



3.11. Budgeting/Planning

Annual Budgeting

Acco

unt D

ept

(Corp

orate)

<Fun

ction

>Ac

coun

t Dep

t (H

K)Re

portin

g Unit

s(&

Resp

ective

De

pt)Su

pply

Chain 1.Sales Forecast

Result for coming year As a CO Plan

version A

2. Copy as a basis for Annual

Budgeting

3. Review Budgeting

Data4. Error Exist?

5.Inform Sales Dept to Fix Error

7. Inform other Dept for Annual

Bud

11.Prepare Data for

freight/ duty budget

12. Input freight / duty budget in

COPC

13.Budget COGS based on Sales Qty automatically in

COPAAND

8.Prepare Data for Std. Cost

Estimate9.Perform Std Cost Estimate

in COPC

10.Inform Corporate of

Budget Completed

14.Budget on Departmental cost in CCA

15.Allocation in COPA Needed?

17. Perform Budgeting Analysis vs Actual Analysis in CCA

18. Budget on Selling Expense

16.A

19. Allocation in C.C. Needed?

6.Adjust Data in SAP

21.Perform Budget vs.

Actual Analysis

20. A

YES

NO

YES

NO

YES

NO

23.B




Annual Budget (Cont')

FINAN

CE

APerform Allocation from

Cost Center to Profit Segment (COPA)

If necessrary

Perform Top Down Distribution in COPA

If necessrary

END


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

3.11.1. SAP R/3 modules deployed for Annual BudgetingFor 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 CO-OM 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 EC-CS for the Budgeting purpose. Plan versus Actual analysis on Consolidated Balance Sheet will be performed in EC-CS as well.

3.11.2. Plan VersionThe 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:

Version Descriptions Usage AAA Business Processes

Type of Costs Captured

0 Master Version -Store Actual/ Plan values

Actual postings Actual/ Plan



-Used for reporting-Required by SAP

050 Sales Forecast -Weekly Sales Forecast by Supply Chain

Sales Forecast Plan

100 Annual Budget – from Sales Forecast

-Data copied from version 050

Annual Budgeting

Plan

110 Annual Budget - Departmental Cost v1

-Data input based on version 100

Annual Budgeting

Plan

120 Annual Budget - Departmental Cost v2

-Data input/ amendment based on version 110

Annual Budgeting

Plan

200 Annual Budget – Corporate Review

-Amendment on version 120 and finalize amount for the year

Annual Budgeting

Plan

210 Annual Budget 1st Qtr– Corporate Review

-Data copied from version 200

Annual Budgeting

Plan

220 Annual Budget 2nd Qtr– Corporate Review

-Data copied from version 210, with adjustments for 1st Qtr.

Annual Budgeting

Plan

230 Annual Budget 3rd Qtr– Corporate Review

-Data copied from version 220, with adjustments for 2nd Qtr.

Annual Budgeting

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 LayoutThis 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:

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)



3.12. Cash Management

Figure 3.12a Cash Management Overview


MM Transactions

Purchase Req

Purchase Order

MM Transactions

Purchase Req

Purchase Order

SD Transactions

Sales Orders

SD Transactions

Sales Orders Cash Position

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

+ 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/P


A/R


A/R


Bank Accounts Confirmed cash

account Bank clearing

accounts

Bank Accounts Confirmed cash

account Bank clearing

accounts

A/R


A/R


Incoming Payments

Incoming Payments

A/P


A/P


Confirmed Cash Bank Accounts

Postings

Confirmed Cash Bank Accounts

PostingsPayment Clearing Accounts Postings

Check

Wire

Deposit Clearing AccountsPostings

Outgoing Payments

Check Wire

Outgoing Payments

Check Wire

Bank Statement

Bank Statement

1000

Out Chk Clearing

Out Wire Clearing

Deposit Clearing

Deposit Clearing

Confirmed Cash B

A/R

A/P

10001000

1000 1000 1000

5000

3000

Confirmed Cash A

5000 5000

20003000

Out Chk Clearing Out Wire Clearing

20003000

A/P

5000

2000

A/R

1000


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.



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

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

3.12.3. Cash PositionThe 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 PositionAfter 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 transactionsOnly 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 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.

Currency Display in Cash Position ReportSpecific 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 ForecastThe 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 subsidiary’s 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 ForecastAs 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 modulesAssignment of ‘Planning group’ in the master record of Customers/ Vendors (Company-Code Specific segment) is required in order for the system to transfer data between the customer/vendor accounts and the liquidity forecast.

3.12.5. Integration with Special GL transactions (FI-GL)

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

3.12.7. Cash ConcentrationCash 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 ManagementIn 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 interface between SAP and the bank for the Lockbox function upon Release 1 of the SAP implementation.



3.13. Consolidation Procedures

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



Corp.

SAP Code 4100


Corp.

SAP Code 4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100

Concord Camera GMBH

SAP Code 3400

Concord Camera GMBH

SAP Code 3400

Concord Camera HK

Limited

SAP Code 5100

Concord Camera HK

Limited

SAP Code 5100SAP Code 3300SAP Code 3300


(France) (Germany) (HK)

Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord Camera

Hungary

SAP Code 3500

Concord Camera

Hungary

SAP Code 3500

(Hungary)

ConsolidationConsolidationUnit/ Unit/ CompanyCompany(Country)(Country)[Ownership [Ownership Percentage]Percentage]


SAP Code 4400


SAP Code 4400


SAP Code 4300


SAP Code 4300

(US) (Latin America)


Corp.

SAP Code 4100


Corp.

SAP Code 4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100

Concord Camera

SAP Code 3400

Concord Camera

SAP Code 3300

Concord Camera HK

Limited

SAP Code 5100

Concord Camera HK

Limited

SAP Code 5100

Concord Camera France S.AR.L

SAP Code 3300SAP Code 3400



Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord Camera

Hungary

SAP Code 3500

Concord Camera

Hungary

SAP Code 3500

(Hungary)



SAP Code 4400


SAP Code 4400


SAP Code 4300


SAP Code 4300



Factory


HenggangElectronics

Factory

SAP Code 5200


SAP Code 5300


SAP Code 5300

(PRC) (PRC)


SAP Code3200

(UK and NorthernIreland)

Data CollectionData Collection

Validation of Data Validation of Data

Currency Translation Currency Translation

Inter-Unit EliminationInter-Unit Elimination

Consolidation of InvestmentsConsolidation of Investments






CC Consolidated Financial Statements

ConsolidationProcedures













Peter Bauser

SAP Code 3600

Concord

SAP Code 5300

Concord CameraAustralia

SAP Code 6100

(Australia)


Corp.

SAP Code 4100


Corp.

SAP Code 4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100

Concord Camera GMBH

SAP Code 3400

Concord Camera GMBH

SAP Code 3400

Concord Camera HK

Limited

SAP Code 5100

Concord Camera HK

Limited

SAP Code 5100SAP Code 3300SAP Code 3300



Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord Camera

Hungary

SAP Code 3500

Concord Camera

Hungary

SAP Code 3500

(Hungary)



SAP Code 4400


SAP Code 4400


SAP Code 4300


SAP Code 4300



Corp.

SAP Code 4100


Corp.

SAP Code 4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100

Concord Camera

SAP Code 3400

Concord Camera

SAP Code 3300

Concord Camera HK

Limited

SAP Code 5100

Concord Camera HK

Limited

SAP Code 5100





Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord Camera

Hungary

SAP Code 3500

Concord Camera

Hungary

SAP Code 3500

(Hungary)

ConsolidationConsolidationUnit/ Unit/ CompanyCompany


SAP Code 4300


SAP Code 4300



Corp.

SAP Code 4100


Corp.

SAP Code 4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100

Concord Camera

SAP Code 3400

Concord Camera

SAP Code 3300

Concord Camera HK

Limited

SAP Code 5100

Concord Camera HK

Limited

SAP Code 5100





Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord Camera

Hungary

SAP Code 3500

Concord Camera

Hungary

SAP Code 3500

(Hungary)



SAP Code 4400


SAP Code 4400


SAP Code 4300


SAP Code 4300



Factory


HenggangElectronics

Factory

SAP Code 5200


SAP Code 5300


SAP Code 5300

(PRC) (PRC)


SAP Code3200

(UK and NorthernIreland)

























Peter Bauser

SAP Code 3600

Concord

SAP Code 5300

Concord CameraAustralia

SAP Code 6100

(Australia)


‘Elim company’ postings will be done through SAP’s 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 Parent in group/ subgroup

CG1000 AAA Bbb Group 1000 AAA Corporate US Yes4200 AAA Bbb Canada4500 Starprint Corp3400 AAA Bbb France3500 AAA Bbb Hungary

6300 AAA AustraliaCG5100 CCHK Cons SubgroupCG3000 CC Europe Cons

Subgroup (UK)CG3300 CC GMBH Cons

SubgroupCG4100 CC Cons Subgroup for

Keystone SalesCG5100 CCHK Cons Subgroup 5100 AAA Bbb HK Ltd Yes

5200 AAA Henggang 5300 AAA Shenzhen

CG3000 CC Europe Cons Subgroup (UK)

3100 AAA Bbb (Europe) Ltd (UK)

Yes

3200 Goldline (Europe) LtdCG3300 CC Europe Cons

Subgroup (GmBH)3300 AAA Bbb (CC

GMBH)Yes

3600 Peter BauserCG4100 CC Cons Subgroup for

Keystone Sales4100 AAA Keystone Sales Yes

4300 AAA Latin America4400 AAA Keystone



Cons group / subgroup

Cons group desc Cons unit Cons unit desc Parent in group/ subgroup

Graphics

Note: The consolidation groups are not final due to design issues with the European consolidation and AAA Australia’s 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 HighlightsKeys 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 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 ProcessGenerally 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 ForwardThis 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 TranslationWithin 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 Current exchange rate1002 Average exchange rate1003 Historical exchange rate1004 Current exchange rate prior year

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 revaluatedCr./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 ProcessConsolidation 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/PWith 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 :



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.


Elimination posting in Consolidation

CC Group

CCHK (5100)

Item Amt T. Partner A / R 20 5100 . . . . . . A / P - 60 5100

Item Amt T. Partner A / R 60 4100 . . . . . . A / P - 20 4100

CCUS (4100)

Elimination posting in Consolidation

Item Unit P Unit Amt A / R 4100 5100 - 20 A / P 4100 5100 60 A / R 5100 4100 - 60 A / P 5100 4100 20


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 consolidationCalculation and posting of minority interest for subsidiaries that are not wholly ownedAutomatic postings for subsequent change in investment for join ventureAmortization 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 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.



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

Report Name Description

20 All Branches

Global Vendor Aging Report Global Vendor Aging Report shown in group currency

21 All Branches

Global Customer Aging Report

Global Customer Aging Report shown in group currency

TBD All Branches

Global Credit Report Global Credit Report for common legal entity customers across all Reporting Units

22 All Branches

AR Aging Report with Reason codes

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

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.

4 CCHK, CCSZ, CCWK

Net Billing Report Cost summary report with layout and presentation specific Net Billing

5 CC Corp Consolidated Reconciliation Report with CO-PA

Report to reconcile Consolidated Financial Statements with applicable consolidated PA reports by customer and by product.

6 CCHK, CCSZ, CCWK

Breakdown of mark-up cost and inventory cost for intercompany inventory transfers

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

61 CCHK, CCSZ, CCWK

Product cost estimate internal summary report

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

3 CCHK, CCSZ, CCWK

Product cost estimate with special scrap rates

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.

108 CCHK Production usage of tooling and moulding asset

A report of production usage frequency and components produced of tooling and moulding asset (linkage



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 moduleb) Cash paid for interest expense and income taxes, and Product group summary on a consolidated

basis of gross sales, SRA’s and COGS have been added to the Report Inventory under FICOc) 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 Inventorye) Provision of high risk / obsolete / discontinued product inventory as well as ending inventory

projection per month / quarter or per any specific month-end closingf) Estimation of labour overhead absorption per month / quarter or any specific month-end closing

for the projected ending inventoryg) 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 reportj) Age gross receivables, allowances and rebates, etc., returns provisions and

calculated net receivablesk) Freight in expense analysis report



5. List of CustomisationsThe following items may be customised and the priority needs to be confirmed:

Ref.

Reporting Units

Customization Type

Priority Description Purpose

7 CCSZ, CCWK

Enhancement Essential

Variable field move exit in special purpose ledger

Enhancement (user exit) in special purpose ledger to update the country specific G/L account numbers for CCSZ for calendar year financial reporting.

8 CCFR Enhancement Essential

Validation exit for posting in FI-GL

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 AAA’s new fiscal year.

64 CCUS, CCHK, CCFR, CCGmbHCCUK


Flat file with electronic payment data –multiple formats depending on country requirements

Output of Electronic file from Auto Payment run.


Form Essential

Check Layouts For check printing to pay vendors


Form Essential

Customer Statements

Correspondence to customers on financial status and payments due

12 All Form Essential

Financial Statements (7 versions)

Statutory and local GAAP financial reports

1 CCSZ,CCWK,


Customization in quantity overhead allocation in product costing

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

14 CCFR, CCUK, CCGmbH

Form Essential

INTRASTAT Reports

To report to the government sales amount, units sold, and weight by customer

TBD All Branche

Enhancement High Gross & Net Receivable

To create a report on gross receivables, estimated



Ref.

Reporting Units

Customization Type

Priority Description Purpose

s Customer Analysis

allowances, returns and bad debt, and net receivables by customer

13 CCUS Form High 1099 Tax Reports

Required tax report to US government on payment to independent contractors

TBD All Form Low Dunning Letters Correspondence to customers to remind them of outstanding payments

9 CCHK Enhancement Low Automatic creation of Debit Note once vendor goods have been rejected

To notify vendors quickly of rejected goods so that they will pick them up promptly

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



6. List of InterfacesThe following items may be customised and the priority needs to be confirmed:

Ref. Priority

Customization Description

15 High Outgoing electronic payments to Hexagon system at HSBC17 High Sending Positive Pay File to Bank to confirm checks from vendors (interface with

HSBC Hexagon system)62 High Payroll from ADP to SAP for CCUS63 High Payroll from in-house program to SAP for CCHK and CCWK16 High Incoming Bank Statements for reconciliation with SAP bank accounts (interface

with HSBC Hexagon system)18 Medium D&B Credit Interface to SAP for customer credit history information19 Low 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.



7. Outstanding Items/ DecisionsThe following section lists the major outstanding Finance issues where resolutions are being discussed and finalized.

Ref.

XRef. /Comm. Log

Issue Description Action Item

1 N/A Finalization of Global Operating Chart of Accounts

Brian is working with Larry and the Controllers to close this item by the end of January 2004

2 HK000950

Finalization of the Group Chart of Accounts for Consolidation

Brian and Stanley are working with Larry and the Controllers to close this item by the end of January 2004

3 N/A Finalization of characteristics and values for Profitability Analysis

Brian is working with the Business Warehouse team and Business Representatives to close this item by the first week of January 2004.

4 HK000751

Configuration of Peter Bauser Decision on whether all configuration for active companies should be set up for Peter Bauser. This will be addressed again during the Implementation Phase.

5 HK000739

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.

Janet, Brian and Larry are working with the SD team to review these bookings in SAP. The target date for closure January 23rd.

Requires system customization. The project team successfully populated the G/L AR reserves line items with the customer number. Investigations will continue to determine the effort required to create a customized report to meet the requirements.

6 HK000752HK000951

Explanation on frequency of entering manual entries against the Consolidation Ledger as a substitute for entering manual entries in an Elim Consolidation Unit

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 the historical balances that exist in the Elim company to avoid monthly manual entry.

7 N/A(See #10)

Internal order usage explanation.

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 demonstration, Paul requested more details on the functionality of tracking capital and operating expenses in the Investment Management module.

8 HK000992HK000463

Proposed solution for showing breakdown costs of Assortments

The SD team is continuing to work out the solution for intercompany sales. A partial resolution has been defined for assortments to world-wide customers. The target closure date is TBD.

9 HK00030 Proposed solution for booking The SD team is continuing to resolve the final details



Ref.

XRef. /Comm. Log

Issue Description Action Item

8 returned goods of the proposed solution to use the World Wide Code 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 code and serial numbering. The bar code will be applied at 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.

10 HK001115

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

Stanley and Janet to communicate and discuss response with Larry and Rick the advantages of using Internal Orders vs. Investment Management to meet these requirements. The target date for discussion/communication is Wed. Dec. 3rd.Two meetings were held to discuss above. Accenture is seeking an IM expert to demonstrate the detailed functionality of IM to meet these requirements.

11 HK001123

Consolidated FI Statement for all of Europe

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

12 HK000638

Mapping of freight activity codes to accounting

David Wand, Patrick Lee and Nancy Ling are working out the details of these requirements. Any applicable G/L freight accounts will be added as needed.

13 HK001084

Add Latin America as an active company code

FICO team will work with the Supply Chain team to ensure that all SAP organizational structures are set up appropriately for Latin America.

14 HK000757

Finalize whether AAA Bbb Aust. (Regional) Pty. Ltd is a subsidiary of CC Corp or CC HK

Closed: E-mail from Harlan Press confirmed that CC Aust. is a subsidiary of CC HK.



8. Annexes

8.1. Annex 1: Cost Center Hierarchical Structure

LegendFunctional Sub Group Number GroupAdministration Admin & Human Resources 99

Administration 99Executives 91Finance 96Human Resources 99Information Technology 95Legal 94Public Company 93

Engineering Design Engineering 10US Design 11US Production Design 12Project Management 20Quality Engineering 40Production Engineering 30

Production Production Line 4XSupporting Service 49

Sales Marketing 20Sales 10Sales Personnel 00

Supply Chain Bonded Warehouse 32Customer Service 44Material Control 49Order Fulfillment 50Packaging & Repacks 52Planning 11Purchasing 20Return Processing & Warranty 51Shipping 40Store 31SZ Export 45Warehouse/Storage 33WK Export 46Customs Service 48Supply Chain 30Shipping Export unplanned 41Shipping Import unplanned 42



CCC AdministrationAdmin & Human Resources 110-79900

Executives Non-Officers 10-79101 Officers 10-79102 Executives 10-79100 Finance Accounting 10-79601 Financial Planning & Analysis 10-79602 Tax 10-79604 Treasury 10-79605 Finance 10-79600 Information Technology Network Spt 10-79501 SAP 10-79502 Information Technology 10-79500 Legal 110-79400 Public Company 110-79300 Administration 110-79901 Engineering Design Engineering 110-61000 US Design Photo Evaluation 10-61101 Software 10-61102 Systems 10-61103 US Design 10-61100 Sales Marketing 110-52000 Sales 110-51000 Sales Personnel 110-50009 Supply Chain Supply Chain 110-33000

CCCAAdministrationAdmin & Human Resources 142-79900

Finance 142-79600 Information Technology 142-79500 Administration 142-79901 Sales Marketing 142-52000 Sales 142-51000 Sales Personnel 142-50009 Supply Chain Customer Service 142-34400 Order Fulfillment 142-35000 Packaging & Repacks 142-35200 Planning 142-31100

Return Processing & Warranty 142-35100

Supply Chain 142-33000 Warehouse/Storage 142-33300



CCFRAdministrationAdmin & Human Resources 134-79900



Supply Chain 134-33000 Warehouse/Storage 134-33300CCGMBH Administration

Admin & Human Resources 133-79900



Supply Chain 133-33000 Warehouse/Storage 133-33300CCHK Administration Executives Non-Officers 51-79101 Officers 51-79102 Executives 51-79100 Finance Accounting 51-79601 FPA 51-79603 Finance 51-79600 Human Resources 151-79902 Information Technology 151-79500 Administration 151-79901 Engineering Design Engineering Electrical 51-61002 Mechanical 51-61003



Optical Engineering 51-61004 Design Engineering 51-61000 Production Engineering Production Engineering 51-63002 Tooling Engineer 51-63003 Project Management Art 51-62000 Packing 51-62002 Project Management 51-62003 Quality Engineering Quality Assurance 51-64002 Quality Engineering 51-64003 US Production Design Photo Evaluation 51-61201 Software 51-61202 Systems 51-61203 US Production Design 51-61200 Production Production Line Plastic 51-41101 Production Line 51-48809 Supporting Service Pilot Assembly 51-49100 Supporting Services 51-49800 Sales Marketing 151-52000 Sales 151-51000 Sales Personnel 151-50009 Supply Chain Purchasing 151-32000 Shipping 151-34000 Shipping Export unplanned 151-34100 Shipping Import unplanned 151-34200 Supply Chain 151-33000 Warehouse/Storage 151-33300CCSZ Administration Finance 153-79600 Human Resources 153-79902 Information Technology 153-79500 Administration 153-79901 Engineering Design Engineering Industrial Engineering 53-61001 Design Engineering 53-61000 Production Engineering Equip Autom 53-63000 Production Engineering 53-63002 Quality Engineering Digital QA 53-64000 Quality Engineering 53-64003 Single Used Bbb QA 53-64004 Production Production Line Digital Assembly 53-46204 Plastic 53-41101 Printed Circuit Board Assembly 53-42303 Single Used Bbb Assembly 53-43100 Stamping 53-41400 Production Line 53-48809



Supporting Service Cleaning 53-49002 Discipline 53-49005 Facility 53-49105 Security 53-49003 Supporting Services 53-49809 Sales Sales 153-51000 Sales Personnel 153-50009 Supply Chain Material Control 153-34900 Order Fulfillment 153-35000 Planning 153-31100 Purchasing 153-32000 Shipping 153-34000 Store 153-33100 Supply Chain 153-33000 SZ Export 153-34500CCUK Administration




Supply Chain 131-33000 Warehouse/Storage 131-33300CCUS Administration


Finance 141-79600 Information Technology 141-79500 Administration 141-79901 Sales Marketing 141-52000 Sales 141-51000 Sales Personnel 141-50009 Supply Chain Customer Service 141-34400 Order Fulfillment 141-35000 Packaging & Repacks 141-35200 Planning 141-31100 Return Processing & 141-35100



Warranty Supply Chain 141-33000 Warehouse/Storage CA Warehouse 41-33301 FL Warehouse 41-33302 Warehouse/Storage 41-33300CCWK Administration Finance 152-79600 Human Resources 152-79902 Information Technology 152-79500 Administration 152-79901 Engineering Design Engineering Industrial Engineering 52-61001 Design Engineering 52-61000 Production Engineering Equip Autom 52-63000 Model Shop 52-63001 Production Engineering 52-63002 Project Management Art 52-62000 Packaging 52-62001 Project Management 52-62003 Quality Engineering Digital QA 52-64000 QA Lab 52-64001 Quality Engineering 52-64003 Single Usued Bbb QA 52-64005 Traditional QA 52-64006 Production Production Line Blister 52-41600 Bonding 52-42302 Digital Assembly 52-46204 Lathe 52-41500 Lens Assembly 52-41201 Lens Molding 52-41200 Mould Shop 52-41102 Packing 52-43300 Painting 52-41700 Plastic 52-41101 Printed Circuit Board Assembly 52-42303

Printed Circuit Board Manufacturing 52-42300

Single Used Bbb Assembly 52-43100 Stamping 52-41400 Surface Mount Technology 52-42301 Traditional Assembly 52-44100 Production Line 52-48809 Supporting Service Canteen 52-49001 Cleaning 52-49002 Discipline 52-49005



Dormitory 52-49004 E-Shop 52-49102 Facility 52-49105 Factory Management 52-49103 Machine Shop 52-49104 Pilot Assembly 52-49100 Security 52-49003 Supporting Services 52-49809 Supply Chain Bonded Warehouse 152-33200 Customs Service 152-34800 Material Control 152-34900 Order Fulfillment 152-35000 Planning 152-31100 Purchasing 152-32000 Shipping 152-34000 Store 152-33100 Supply Chain 152-33000 WK Export 152-34600



8.2. Finance RequirementsAccounts Payable

Ref # Requirement Must Have

Nice to

Have

Not Important

Requirement Comments

Requirements Addressed in the Current Design?

AP-1 Ability to add new vendors real time. X due to HK volume AP-2 Provide a real-time interface with the Purchasing system. X Not used today Not in Phase 1 scopeAP-3 Provide a real-time interface with the Inventory system. X Not used today Not in Phase 1 scopeAP-4 Share the vendor file with Purchasing and Inventory. X Not used today Not in Phase 1 scopeAP-5 Allow for the identification of tax exempt items. X YesAP-6 System automatically assigns a vendor number. X YesAP-7 Vendor lookup by name, address or vendor number. X Yes

AP-8On-line access to vendor information (e.g. balance due information. X Yes

AP-9 Ability to view purchase orders on-line. X YesAP-10 Ability to view open and paid items on-line. X YesAP-11 Ability to view current and YTD activity on-line by account. X Yes

AP-12Provide inter-company, inter-divisional processing and transferring. X Yes

AP-13 Support user defined posting cycles. X Yes

AP-14Provide automated 3-way matches of the invoice, purchase order/requisition and receiving report. X Not used Yes

AP-15Produce a discrepancy report to identify unmatched receiving reports, purchase orders or invoices. X Yes

AP-16 Display historical vendor payments in chronological order. X Yes

AP-17 Provide features to facilitate off-site check printing. X

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

AP-18 Post G/L either in detail or summary. X Yes

AP-19Allow transactions to be posted to a subsequent period before the current period has been closed. X Yes

AP-20Ability to auto-assign a vendor, customer, and voucher number. X Yes

AP-21 Ability to combine a user-defined batch of invoices into a X Yesdocument.doc Printed on: 5/3/2023 1:44 AM Page 144 of 164


Accounts Payable


Nice to

Have

Not Important



single check for a vendor.

AP-22Provide a voucher printout generated for each invoice as an audit trail. X

Yes** SAPScript form needs to be customised

AP-23 Support off-site input of vouchers. X

Yes** Customisation on offline data input and upload program is needed to fulfill this requirment

AP-24Integrate with Payroll for payment of deductions to a third party, i.e. garnishments, charities, etc. X

Using ADP today, and do not plan to change

Integration with Payroll is through a customized interface

AP-25 Produce checks from multiple bank accounts. X Yes

AP-26Provide the flexibility to support both batch and interactive processes. X Batch only

SAP standard support both batch input and online data input in AP. Please refer to AP-23 for details

AP-27 Allow user designed check formats. X Yes

AP-28Support the ability to produce laser printed checks with MICR coding on blank paper stock. X

Not important to HK

Customization of standard SAP check form required

AP-29Allow payment information to be accessed by invoice number, check number and vendor name. X Yes

AP-30 Ability to view all reports on-line. X Yes

AP-31 Update all files, including history, if a check is voided. X

Dynamics updates all but history Yes

AP-32 Allow for manual checks. X Yes

AP-33Ability to generate checks by vendor, due date, and discount date. X Yes

AP-34Ability to produce checks in order to maximize discount opportunities. X Yes

AP-35 Account aging information to be provided both on-line and in X Yesdocument.doc Printed on: 5/3/2023 1:44 AM Page 145 of 164


Accounts Payable


Nice to

Have

Not Important



report format.

AP-36Support automatic check reconciliation by receiving a data file from the bank with canceled check information. X

Not used today. Dynamics requires third-party add-on Yes

AP-37Ability to automatically generate monthly and year end accrual calculations. X

Yes* *Using SAP FI Accural functions, pre-defined accrual entried can be generated per period

AP-38Produce an open liability report for year end and period end accruals. X Yes

AP-39 Provide cash requirements forecasting. X YesAP-40 Create recurring vouchers. X YesAP-41 Provide ad-hoc reporting capabilities. X YesAP-42 Allow for one time vendors. X YesAP-43 Support document imaging. X Not in Phase 1 scope

AP-44Produce 'joint checks' - a check made payable to two parties. X

Excluded from current design

AP-45 Allow for user defined fields. X YesAP-46 Support accrual detail report. X YesAP-47 Support vendor approval process setup. X Yes

AP-48Provide a proof report listing all entered vouchers prior to posting. X Yes

AP-49Allow voucher entry from multiple companies in the same session. X Yes

AP-50Support a single vendor master file for use across all companies. X Yes

AP-51Support supplier account inquiry across companies. (Invoice search without knowing company name) X Yes

AP-52Allow the allocation of a single voucher to multiple companies. X

Will be addressed in Detail Design Stage

AP-53Support inquiry capabilities on check number. (Listing related invoices, drill down capabilities) X Yes



Accounts Payable


Nice to

Have

Not Important



AP-54Ability to create electronic check registers for transmission to the bank after check runs. (Positive Pay) X

Dynamics needs third-party software to do thisYes

AP-55 Allow supplier account inquiries based on date ranges. X YesAP-56 Support multiple remit-to addresses. X YesAP-57 Support payment by electronic funds transfer. X Not 'user friendly' Yes

AP-58Support default descriptions and account numbers for suppliers. X

Depends on vendor whether this would be used Yes

AP-59 Handle special check routing instructions. (Hold, Route to other employees)

X

Yes*Park Document can be used to filfill this requirment.

AP-60Support image enabled storage of invoices. (Scanning vs. Paper) X Not in Phase 1 scope

AP-61Allow payment of invoices from multiple companies on the same check. X

Provided intercompany account processes are followed


AP-62 Support intercompany accounts payables transactions. X work-arounds are needed Yes

AP-63Ability to prevent entry of the same invoice for payment by multiple companies. X Yes

AP-64 Handle reimbursements for items such as gift certificates. X Can enter gift certificates as a special voucher type

AP-65 Ability to transmit 1099's electronically. X YesAP-66 Provide 1099 processing. X YesAP-67 Support 1099 vendor coding. (Rents, Misc.) X YesAP-68 Support single vendors as both 1099 and trade vendors. X Yes

AP-69 Support VAT requirements. X For both China and Europe Yes

AP-70 Ability to interface with project costing. X Not in Phase 1 scopeAP-71 Ability to interface with fixed assets. X Yes

AP-72Ability to support on-line vendor and customer inquires (i.e. self service). X Not in Phase 1 scope



Accounts Receivable & Billing

Ref # Requirement Must HaveNice toHave

Not Import

antRequirement Comments

AR-1Support either detail or summary posting of transaction detail to G/L. X Yes

AR-2 Allow payments to be applied to specific invoices. X YesAR-3 Allow unallocated customer payments to a customer account. X YesAR-4 Provide a cash receipt summary report by bank. X YesAR-5 Allow miscellaneous adjustments to a customer's account. X YesAR-6 Allow reason codes for adjustments. X Yes

AR-7Ability to access customer A/R account information by either customer number or customer name. X Yes

AR-8Provide real-time update of customer A/R balances based on billings and collections. X

Batching is used today Yes

AR-9Provide customer A/R account information history shown in chronological order. X

Not being done today Yes

AR-10Show payments with their associated invoices in the customer A/R account information history. X Yes

AR-11Ability to post transactions to a subsequent month before the previous month has been closed. X Yes

AR-12Allow multiple agings by corporation (i.e. one aging per division and/or location). X Yes

AR-13 Ability to automatically generate invoice numbers. X Yes

AR-14 Ability to allow users to add customers real-time. X

Would like the new system to provide approval controls over adding new customers Yes

AR-15 Allow the user to define custom invoice formats. X

Requires customization of standard SAP voucher form

AR-16 Ability to print invoices individually on request. X YesAR-17 Ability to compute and separately track VAT. X Not used today YesAR-18 Ability to reprint invoices. X YesAR-19 Allow input of non A/R cash, i.e. payment via a notes receivable. X YesAR-20 Accept payment of cash in excess of amount due. X YesAR-21 Ability to write off small amounts at cash application time. X Yes



AR-22 Ability to print a bank deposit slip. X

Bank Deposit slips should be printed by Bank and not by AAA Bbb. This is not addressed in current design.

AR-23 Prevent posting with errors and warnings. X

Dynamics needs much stronger controls Yes

AR-24Support automated matching and exception reporting. (Credit cards, cash application) X

Not important due to the low volume of receipts Yes

AR-25 Track the resolution and collection process for chargebacks. X

Could be a growing problem as activity with Wal-Mart, etc. expands More information needed

AR-26 Allow reason codes for chargebacks. X Yes

AR-27Provide information regarding the actual/original dates of chargebacks. (the items that caused the chargebacks) X Yes

AR-28 Support centralized accounts receivable. X YesAR-29 Support intercompany receivables. X Yes

AR-30Prevent duplicate processing of the same record. (cash application) X Yes

AR-31 Allow for posting a payment to a suspense account. X Yes

AR-32Ability to interface with bank files to allow customer payment by transfer of funds. X Yes

AR-33 Provide a sales data report containing the last invoice date. X Yes

AR-34Provide a sales data report containing sales and gross profit YTD, prior period. X Yes

AR-35Provide a sales data report containing YTD/prior period sales by period. X Yes

AR-36 Provide an aged trial balance report for the current period. X

Needs comment space to note collection efforts Yes

AR-37 Provide an aged trial balance report as of any date. X YesAR-38 Provide an aged trial balance report with summary or detail data. X Yes

AR-39Provide an aged trial balance report for age on invoice date or due date. X Yes

AR-40 Provide an aged trial balance report for past due customers only. X YesAR-41 Provide a report with customer statistics. X Yes



AR-42 Provide a report with invoice description on customer statement. X

Requires customization of standard SAP customer statement form

AR-43 Provide a report with the automatic charge journal. X

Yes*By FI Document Type

AR-44 Provide a report with the finance charge journal. X No auto finance chg journal Yes

AR-45 Provide a report for a cash application worksheet. X

All reports will be addressed after Conceptual Deisgn Signoff

AR-46 Provide a report with the transaction register. X


AR-47 Provide a report containing cash flow due. X For a single company only


AR-48 Provide a sales tax report for jurisdiction. X


AR-49 Provide a sales tax report for gross sales. X


AR-50 Provide a sales tax report for amount due. X


AR-51 Provide a G/L distribution report. X


AR-52 Provide a customer master file list. X

All reports will be addressed after Conceptual Deisgn



Signoff

AR-53 Provide a report that recaps customer transactions for a period. X


AR-54 Provide a report that recaps customer transactions for YTD. X


AR-55Provide a report that recaps customer transactions for user defined range of dates to include multi-year. X


AR-56Support A/R trade statements, follow-up statements, tracking receipts. X


AR-57 Support a daily aging report. X


AR-58 Upload aging reports to the intranet. X Not in Phase 1 scope

AR-59 Support aging reports, edit reports, cash receipts registers. X


AR-60Support credit card reconciliation between third party clearing houses and bank accounts. X

Requirement is no longer essential -- not in the current design

AR-61 Produce a closing bank statement. X YesAR-62 Provide an automated bank reconciliation. X Yes

AR-63

Ability to have the system interface with the bank system to create externally generated transactions. (Bank fees)

X Yes**Electronic Bank Recon with Hexagon-HSBC

AR-64Provide VAT functionality that calculates taxes at the time of invoicing. X Yes

AR-65 Provide the ability to print/view reports based on a date range in X Yes



the past.

AR-66 Allow all reports to be viewed on line. X

Need option to see both posted and unposted records Yes

AR-67 Allow the user to create custom lookup views. X Yes

AR-68Ability to print on the sales invoice the brand, color, film and batteries. X

Requires customization on standard SAP invoice form

AR-69 Ability to account for Net sales adjustments on an order by order basis based on a Net sales allocation table which can provide the flexibility to make several type of adjustments based on Model type , responsible branch, specific customers and specific sales product codes.

X Yes** Details should refer to SAP-SD design document

AR-70Ability to add Sales comment and the customer part number to the invoice detail. X Yes

AR-71 Ability to support vendor and customer inquires. X Yes

Financial Management


Not Import


General Ledger

FM-1Provide easy addition and deletion of account numbers within the chart of accounts. X Yes

FM-2 Provide statistical data in the chart of accounts. X Yes

FM-3Provide drill-down capabilities of summary information to access detailed information stored in multiple modules. X Not using today Yes

FM-4 Provide automatic journal entries with an audit trail. X Yes

FM-5Perform automatic recurring journal entries and reversals of monthly accruals. X Yes

FM-6 Automatically assign journal entry numbers. X Yes

FM-7 Allow posting to multiple years and periods at one time. X

Yes, in multiple transactions. You are restricted to one period/year per transaction

FM-8 Ability to print a detailed ledger after year end close. X Yes



FM-9 Provide for user defined closes. X Yes

FM-10Provide audit controls for statistical information on J/Es - J/E identifier by user. X

Statistical information on J/EsJ/E identifier by user Yes

FM-11 Support separate fiscal calendars by company. X YesFM-12 Ability to edit journal batches prior to posting. X YesFM-13 Allow user defined journal descriptions. X YesFM-14 Provide on-line reports with an option to print. X Yes

FM-15Provide the ability to scroll up/down when reviewing on-line reports. X Yes

FM-16Provide the ability to generate a combined trial balance for all accounts. X

Combined for all companies Yes

FM-17Ability to have import/export capabilities to communicate with other software packages. X Yes

FM-18 Ability to support foreign currency conversion. X YesFM-19 Ability to support international formats for dates. X YesFM-20 Ability to support tracking of exchange rate gains/losses. X YesFM-21 Ability to track different rates for the same currency. X YesFM-22 Ability to track different currencies for different companies. X YesFM-23 Ability to support auto conversion of foreign currency amounts. X Yes

FM-24Ability to support consolidation of companies with different currencies. X Yes

FM-25 Allow viewing of reports through an intranet. X Portals Not in Phase 1 scopeFM-26 Allow for on-line updates via the intranet. (budget process, etc.) X Not in Phase 1 scopeFM-27 Ability to create allocations based on statistical information. X Yes

FM-28Ability to flag exceptions for accounts that deviate from user defined criteria. X


FM-29 Allow system interface with sales tax reporting system. X Yes

FM-30Allow each CC location to have the ability to view accounting data. X Yes

FM-31 Support 4-4-5 accounting. X YesFM-32 Support off-site voucher entry and check writing capabilities. X Yes

FM-33Support model journal entries. (same accounts, but varying amounts each month) X

Need ability to edit amounts Yes

FM-34Provide capability to download/upload information in spreadsheets. X

Not currently used to full advantage Yes



FM-35 Ability to summarize/purge historical data. X Not in Phase 1 scopeFM-36 Ability to report performance of actuals to budgets. X Yes

FM-37Provide drill down capabilities to scanned documents. (electronic storage) X

Would like to investigate using this technology in the future Not in Phase 1 scope

FM-38Automatically create intercompany journal entries. (postings to intercompany accounts) X

Yes. Automatic intercompany entries for sales and purchases enabled by EDI

FM-39Provide drill down capabilities from on-line versions of the financial statements. X Yes

FM-40

Support complex allocations utilizing user defined cost pools, variable and fixed percentage allocation as well as stepped or layered methodologies. X Yes

Budgeting FM-41 Provide exception reporting for significant variances between

one budget version and historical information or with redefined criteria.

X Yes** Standard function on exception reporting exist in BW

FM-42 Store budget data by month with the ability to summarize for different periods.

X Not currently using Dynamics for budgeting

Yes

FM-43 Allow multiple versions of a plan or budget. X YesFM-44 Provide ranking and comparison features to judge the multiple

versions of a plan or budget.X Will be

addressed in Detail Design Stage

FM-45 Allow for flexible, user-maintained, account roll-ups. X Yes** By means of Cost Element Groups

FM-46 Ability to restrict user access to the budget update function. X Yes** SAP provide different control points for budgeting, e.g. by transaction or



by limit by Plan Version

FM-47 Provide automatic consolidation of the budget numbers, which were prepared at the divisional and/or departmental level.

X Yes** Consolidated budget values here only means by simple addition of all divisional/ departmental values. No real integration with Consolidation module in SAP

FM-48 Allow the user to autocopy same account data to all periods. X Yes*By copy function

FM-49 Allow actuals be used to generate new budgets. X Yes*By copy function

FM-50 Allow new budgets to be automatically generated by increasing prior year budgets by a flat % or formula.

X Yes

FM-51 Support the use of units/formulas to compute budget data. X Yes*Simple formula can be catered by R/3 CO planning function. For more advance formula, separate SAP product, SEM-BCS should be implemented

FM-52 Allow for what-if analysis during the budgeting process. X Yes** Workaround solution:User might use different Plan Version and input different data for simple scenario



analysis. For more advance what if analysis, separate SAP product, SEM-BCS should be implemented

FM-53 Create recurring journal entries based on approved budgets. X No. Standard SAP do not support recurring FI entries be generated from budget data. Manual work has to be done by users

FM-54 Allow recurring journal entries spread annual amounts evenly and unevenly across monthly periods

X Dynamics only allows set amounts

Yes** This utilitises FI-GL standard function. No integration with SAP Planning functions

FM-55 Allow users to view on-line comparisons of budget and actual data.

X Yes

FM-56 Support the use of the intranet/internet during the budget process.

X Not in Phase 1 scope

Financial Reporting FM-57 Integrate with user friendly, third party report writers (e.g.

spreadsheet downloads and queries that can be used by non-technical individuals).

X Yes

FM-58 Ability to produce an income statement for any division/department or other entity.

X Yes

FM-59 Ability to easily produce consolidated financial statements. X YesFM-60 Ability for financial reports to be generated for any single period

or any range of periods.X Corporate now

using Excel to generate financial

Yes



statementsFM-61 Provide predefined reports that can be used as modifiable

templates rather than having to create all new custom reports. X Yes

FM-62 Ability to print to any available network device. (i.e. printer/CD writer)

X Yes** As long as the network device is set up and supported as SAP output device

FM-63 Support the consolidation of unlike chart of accounts. X Not being done today

Yes** However, this will not be the case for AAA after SAP implementation

FM-64 Ability to print P and L YTD vs. PYTD. X Corporate now using Excel to generate financial statements

Yes

FM-65 Ability to print P and L current period vs. same period last year. X " " YesFM-66 Ability to print P and L period data across columns. X " " YesFM-67 Ability to print P and L department data across columns. X " " YesFM-68 Ability to print P and L 5 year data, with a 5 year average. X " " YesFM-69 Ability to print Balance Sheet current period vs. prior period. X " " YesFM-70 Ability to print Balance Sheet 5 year data, with a 5 year average. X " " YesFM-71 Ability to print Statement of cash flows current period, last year. X " " YesFM-72 Ability to print Statement of cash flows YTD, this year. X " " YesFM-73 Ability to print Statement of cash flows YTD, last year. X " " YesFM-74 Ability to print Statement of cash flows 5 year data, with a 5 year

average.X " " Yes

FM-75 Ability to print Budget data current period actual, variance. X YesFM-76 Ability to print Budget data YTD actual, variance. X " " YesFM-77 Ability to print Budget data flash reporting (actual + remaining

budget).X " " Yes

FM-78 Ability to print Budget data cash projection/management data. X " " YesFM-79 Ability to include unposted journals on financial reports. X No. This is

already clarified as a GAP in the FICO workshop.



This is not a standard functionality of SAP

FM-80 Ability of the report writer to mask a part of the account number. X Not using today Will be addressed in Detail Design Stage

FM-81 Ability of the report writer to mask a part of the account number. X Will be addressed in Detail Design Stage

FM-82 Ability of the report writer to support flexible definition of column and row data.

X Yes

FM-83 Ability of the report writer to support flexible user defined calculations, such as column computations.

X Yes

FM-84 Ability of the report writer to support flexible user defined calculations, such as ratios.

X Yes

FM-85 Ability of the report writer to support flexible user defined calculations, such as user defined subtotals

X Yes

FM-86 Ability of the report writer to support the preparation of graphs/charts.

X Yes

FM-87 Ability of the report writer to print footers on financial statements. X YesFM-88 Ability of the report writer to have security relating to report

creation and generation.X Yes

FM-89 Provide online query capabilities to mask a part of the account number.

X Will be addressed in Detail Design Stage

FM-90 Provide online query capabilities to lookup account data by range of periods.

X Yes

FM-91 Provide online query capabilities to lookup account data by range of accounts.

X Yes

FM-92 Provide online query capabilities to lookup account data by user defined screen views.

X Will be addressed in Detail Design Stage

FM-93 Provide online query capabilities to display totals. X YesFM-94 Provide online query capabilities to obtain a graphical analysis. X Yes



FM-57 Provide online query capabilities for prior period data. X YesConsolidations FM-95 Provide summarization of accounts. (roll-up capabilities) X Not using

consolidation feature today

Yes

FM-96 Support intercompany accounting. X YesFM-97 Allow for user defined roll-up structures. (Ability to change

structure easily)X Yes

Treasury FM-98 Support calculation of expected cash resources (sales, AR, field

service, miscellaneous cash). X Yes*

* Cash Mgmt module covers SO/ PO/ AR, AP invoices/ GL Bank postings. All other expected cash inflow/ outflow are input manually in form of Memo Record

FM-99 Support calculation of expected cash uses (purchasing, AP miscellaneous cash).

X Yes

FM-100 Track forecast effects of cash resources and uses on cash availability.

X Yes

FM-101 Provide cash projection reporting. X YesFM-102 Provide cash projections by entity, bank, expected date, terms,

customer payment history. X Yes*

* Only on bank, expected date, payment terms. Not based on Customer Payment History.

FM-103 Provide cash projections by currency (for hedging currencies). X YesFM-104 Provide cash book inflow and outflow by bank, year, statement

code. X Yes

FM-105 Support recording of cash payments and receipts from bank statements.

X Yes

FM-106 Support statement discrepancy exception flagging and reporting. X Yes



FM-107 Ability to record miscellaneous charges and deposits. X YesFM-108 Process cancelled AP checks. X YesFM-109 Provide recording of GL journal entries to cash. X YesFM-110 Print statement of accounts. X YesFM-111 Record cash receipts automatically from bank . X Yes; however the

current design is that cash receipts wil be applied manually

Asset Management


Not Import


FA-1Ability to track "additions" by P.O. number, voucher number, asset number, or vendor number for a specific range of periods. X

Not using Dynamics today. Assets are tracked in Excel. Yes

FA-2Ability to designate division, department, and location for each asset. X Yes

FA-3Ability to transfer assets between divisions, departments or locations. X Yes

FA-4 Track user defined fields for each asset purchased. X YesFA-5 Track the original cost and history of sales taxes paid on assets. X Yes

FA-6Track items that are not recorded as fixed assets, such as third party rentals. X Yes

FA-7 Capture Equipment Number information. X

No. Needs to be accomplished with SAP Plant Maintenance

FA-8 Capture Equipment Type information. X


FA-9 Capture Make information. X


FA-10 Capture Model Number information. X

No. Needs to be accomplished with SAP Plant Maintenance.

FA-11 Capture Serial Number information. X Yes



FA-12 Capture Division information. X YesFA-13 Capture Physical Location information. X YesFA-14 Capture State information. X YesFA-15 Track Sold To name for each asset sold. X YesFA-16 Track Gain or loss for each asset sold. X YesFA-17 Track Type or reason for disposal for each asset sold. X YesFA-18 Track Amount of sales tax paid for each asset sold. X Yes

FA-19

Support all depreciation methods and conventions including straight line, sum of years, double declining balance, MACRS, ACRS, and ADS. X Straight line Yes

FA-20 Support different book and tax basis. X Yes

FA-21Ability to forecast depreciation by changing an asset's useful life, depreciation method, and/or acquisition date. X

Yes for existing/current assets only; Forecast depreciation for future assets can be set up in IM

FA-22 Provide a complete audit trail of transactions. X YesFA-23 Interface with accounts payable. X YesFA-24 Interface with the general ledger. X YesFA-25 Provide a retirement register by month/asset by Division. X YesFA-26 Provide a retirement register by month/asset by Department. X YesFA-27 Provide a retirement register by month/asset by Master account. X YesFA-28 Provide a retirement register by month/asset by Sub-account. X YesFA-29 Provide a retirement register by month/asset by Product code. X YesFA-30 Provide a retirement register by month/asset by Retirement type. X YesFA-31 Provide monthly and YTD activity reports for Transfers. X YesFA-32 Provide monthly and YTD activity reports for Acquisitions. X YesFA-33 Provide monthly and YTD activity reports for Sales. X YesFA-34 Provide monthly and YTD activity reports for Disposals. X YesFA-35 Ability to track vehicle licenses. X YesFA-36 Support foreign currency. Which ones? X YesFA-37 Track leasing info. X YesFA-38 Track assets by location, state and division for state tax purposes. X YesFA-39 Ability to indicate tax exempt status. X YesFA-40 Provide asset retirement options, such as Fully retire. X YesFA-41 Provide asset retirement options, such as Partially retire. X YesFA-42 Provide asset retirement options, such as Retire by units. X YesFA-43 Provide asset retirement options, such as Retire by cost. X YesFA-44 Provide asset retirement options, such as Reinstate retired assets. X Yes



FA-45Provide asset retirement options, such as Current and prior period retire. in the same period. X Yes

FA-46

Ability to provide unique reporting requirements, such as Capital budgeting and forecasting features as well as correct net book value for a past period. X

Capital budgeting and forecasting features. To be able to correct net book value for a past period

Yes, correct net book value for a past period but capital budgeting is managed in the Investments Management module

FA-47Ability to print a report showing accumulated depreciation by a user specified date. X Yes

FA-48 Ability to support property tax registers. X YesFA-49 Ability to support physical count process. X Yes

Cost Management & Accounting


Not Import


Product Costing

PC-1Support any/all of the following cost types: Standard, Actual, Average, Simulated, or User-defined. X

Note: Product costing is currently being supported by CIS4 Yes

PC-2 Ability to store frozen, current and/or pending standard costs. X YesPC-3 Support regenerative and selective cost generation modes. X Need more informationPC-4 Support inclusion of scrap, yield, and shrinkage in cost calculations. X Yes

PC-5 Support yield calculations specified by batch and/or process. X

No. Need clarification on the meaning of yield calculation.

PC-6 Support cost rollup selectable by cost type or part number. X YesPC-7 Support cost rollover selectable by cost type. X YesPC-8 Provide the capability to store actual costs. X YesPC-9 Support cost updates by all items, single items, or item class. X Yes

PC-10Ability to calculate freight, overhead, carrying cost, etc. in actual and standard cost. X Yes

PC-11Ability to include freight, overhead, carrying cost, etc. in actual and standard cost. X Yes

PC-12 Provide standard cost for labor. X YesPC-13 Capture actual cost for labor. X Yes



PC-14 Provide labor variance reporting. X YesPC-15 Provide downtime reporting by reason code.

X No. Need more information.

Cost Reporting PC-16 Provide reports for Costed single level BOM. X YesPC-17 Provide reports for Costed multi-level BOM. X YesPC-18 Provide reports for Cost summary. X Yes

PC-19 Provide reports for Cost comparisons. X


PC-20 Provide reports for Product Cost sheet. X


PC-21 Provide reports for Cost change report. X


PC-22 Provide reports for Cost analysis exception report. X


PC-23 Provide reports for Cost generation exceptions report. X


PC-24 Provide reports for Item cost reporting. X


PC-25 Provide reports for Cost comparisons. X


PC-26 Provide reports for Product Cost sheet. X


Variance Reports PC-27 Support variance types, such as Material usage. X YesPC-28 Support variance types, such as Material substitution. X YesPC-29 Support variance types, such as Purchase price. X Yes

PC-30 Support variance types, such as Shrinkage. X Will be addressed in Detailed Design Stage

PC-31 Support variance types, such as Yield by work order. X Will be addressed in Detailed Design Stage



PC-32 Support variance types, such as Component scrap. X Yes

PC-33 Support variance types, such as Parent cost adjustment. X Will be addressed in Detailed Design Stage

PC-34 Support variance types, such as Component cost adjustment. X Will be addressed in Detailed Design Stage

PC-35 Support variance types, such as Closed work order. X NoPC-36 Support variance types, such as Future variance projections. X NoCost Management PC-37 Support transaction register encoding. X YesPC-38 Support inventory reevaluation. X YesPC-39 Support work order closing procedures. X Yes

PC-40Support labor distribution reporting to assign labor costs to products. X Yes

PC-41 Support activity based costing. X PC-42 Allow all reports to be viewed on line. X YesPC-43 Allow the user to create custom lookup views. X Yes

PC-44Ability to segment, track and monitor the Standard Landed cost for Budgeting & Product Costing reasons. X Yes

PC-45Need to use USD as the sales currency for the UK export customers. X Yes

PC-46Ability to automatically generate a journal entry to transfer indirect materials between departments. X

Yes. For indirect materials have been expensed to a cost center, no further value movement will be kept by SAP

PC-47 Ability to classify standards by department for machine and labor. X Yes
