conceptual design of fico[1]

8/8/2019 Conceptual Design of FICO[1]

http://slidepdf.com/reader/full/conceptual-design-of-fico1 1/147

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

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

This is with the understanding that the Program team has maintained, in good faith, a high level of integrity acrossall 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 inmore detail across all conceptual design documents. The Finance & Controlling Program team will beresponsible for working with the Business Representatives and Supply Chain Program team to resolve all openitems/issues identified and recorded in this Finance & Controlling design document.

Signed:




Table of Contents

1. INTRODUCTION ..................................................................................................................................6

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

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

2.1. COMPANY CODE STRUCTURE.................................................................................................................. 92.2. E NTERPRISE CONSOLIDATION (EC–CS) ORGANIZATION STRUCTURE ................................................................................................................................................................ 102.3. CHART OF ACCOUNTS STRUCTURE ................................................................................................................................................................ 112.4. ASSET ACCOUNTING STRUCTURE ................................................................................................................................................................ 122.5. CONTROLLING ORGANIZATIONAL STRUCTURE

................................................................................................................................................................ 132.6. COST CENTER STRUCTURE.................................................................................................................... 14

3. FINANCE & CONTROLLING PROCESS DESIGN CONCEPTS

.................................................................................................................................................................... 18

3.1. FINANCIAL ACCOUNTING GLOBAL SETTINGS........................................................................................... 193.1.1. FI Document Type/ Number Range .........................................................................................19

3.1.2. Currency .................................................................................................................................. 22

3.1.3. Exchange Rates ....................................................................................................................... 233.1.4. Fiscal Year Variant ................................................................................................................. 26

3.1.5. Opening and Closing Posting Periods .................................................................................... 26

3.2. GENERAL LEDGER ............................................................................................................................... 28




3.4.2. Document Type ........................................................................................................................52 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.............................................................. 52

3.4.3. Trade Vendor Master Data Maintenance ................................................................................523.4.4. Non-Trade/ Sundry Vendor Master Data Maintenance .......................................................... 52

3.4.5. Payment Terms ........................................................................................................................ 52

3.4.6. Accounts Payable Transaction Posting ........................................................................................................................................................... 53

3.4.7. Blocked Invoices ......................................................................................................................613.4.8. Accounts Payable Period Processing ......................................................................................61

3.5. I NTERCOMPANY AP / AR (FINANCE ONLY) ................................................................................... 623.5.1. Authorisation ........................................................................................................................... 63

3.6. ASSET ACCOUNTING............................................................................................................................ 633.6.1. Chart of Depreciation: ............................................................................................................ 633.6.2. Depreciation Area: ..................................................................................................................64

3.6.3. Asset Class: ............................................................................................................................. 65

3.6.4. Asset Number Range: .............................................................................................................. 653.6.5. Asset Depreciation Methods: .................................................................................................. 66

3.6.6. Asset Master Maintenance: ..................................................................................................... 70

3.6.7. Asset Transactions ...................................................................................................................72

3.7. COST CENTER ACCOUNTING................................................................................................................. 773.7.1. Cost Center Structure .............................................................................................................. 78

3.7.2. Statistical Key Figures ............................................................................................................ 79

3.7.3. Overhead Allocation ................................................................................................................803.7.4. Re-posting of cost .................................................................................................................... 80

3.7.5. Period End-Closing ................................................................................................................. 80

3.8. I NTERNAL ORDER ................................................................................................................................ 813 8 1 O d M t D t C ti 81




3.10.1. Organisation Unit in COPA ................................................................................................ 1023.10.2. COPA Method Deployment ................................................................................................. 103

3.10.3. COPA Structure - Characteristics ....................................................................................... 105

3.10.4. COPA Structure – Value Fields .......................................................................................... 107 3.10.5. Actual Value Flow into COPA ............................................................................................ 108

3.10.6. Special Treatments on ‘Responsible Branch’ ......................................................................109

3.10.7. Sale Allowances/ Provisions Handling ............................................................................... 1093.10.8. ‘Partner Functions’ of Customer Master ............................................................................ 109

3.11. BUDGETING/PLANNING..................................................................................................................... 1113.11.1. SAP R/3 modules deployed for Annual Budgeting .............................................................. 114

3.11.2. Plan Version ........................................................................................................................ 1143.11.3. Planning Layout .................................................................................................................. 115

3.12. CASH MANAGEMENT....................................................................................................................... 1173.12.1. Common information and differences between Cash Position and Liquidity Forecast .... ..1193.12.2. Memo Records ..................................................................................................................... 119

3.12.3. Cash Position .......................................................................................................................120

3.12.4. Liquidity Forecast ............................................................................................................... 1223.12.5. Integration with Special GL transactions (FI-GL) ..............................................................122

3.12.6. Electronic Bank Reconciliation ........................................................................................... 123

3.12.7. Cash Concentration ............................................................................................................. 124

3.12.8. Lockbox in Cash Management ............................................................................................ 124

3.13. CONSOLIDATION PROCEDURES........................................................................................................... 1263.13.1. Consolidation Units ............................................................................................................. 126

3.13.2. Consolidation Groups ......................................................................................................... 127 3.13.3. Consolidation Chart of Accounts and Financial Statement Items ...................................... 128

3.13.4. Design Highlights ................................................................................................................ 128

3.13.5. Data Collection Process ...................................................................................................... 1293 13 6 C lid ti P 130




1. Introduction

This document describes the major design concepts for the Finance and Controlling OrganizationalStructure and all financial transactions/configuration related to the General Ledger, Accounts Payable,Accounts Receivable, Asset Accounting, Product Costing, Cash Management, and ConsolidatingFinancial 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. Thislevel 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 theFinancial modules being implemented are:

• Financial Accounting:o General Ledger,

o Accounts Receivable

o Accounts Payable

o Asset Accounting

• Controlling:

o Overhead Cost Controllingo Product Costing

o Profitability Analysis

• Treasury Cash Management




Figure 1.1

Product Cost

Controlling

Product Cost

Controlling

Profitability Analysis Profitability Analysis

C on s o

l i d a t i on

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 AssetAccounting

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 thefoundation for how all financial transactions will be reported. These organizational structuresreflect the legal and managerial organizations that support external and internal financialreporting. 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 externalfinancial statements such as Balance Sheet and Operating Income Statement reports. EachCompany 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 AAAKeystone Graphics are divisions that belong to the legal entity AAA Keystone Sales Corp. AAAHenggang represents the factory that belongs to AAA Shenzhen




Figure 2.1

2.2. Enterprise Consolidation (EC–CS) Organization Structure

The Enterprise Consolidation structure facilitates the procedures that create ConsolidatedFinancial Statement reports for all AAA Reporting Units. The Consolidation structure isarranged to allow consolidated financial reports for Global AAA Bbb Corp all European

Finance Organizational StructureSAP Company Codes

ConcordCamera Corp.

SAP Code 1000

ConcordCamera Corp.

SAP Code 1000

ConcordKeystone Sales

Corp.

SAP Code4100


Corp.

SAP Code4100

ConcordCamera Canada

SAP Code 4200


SAP Code 4200

ConcordCamera(Europe)

Limited

SAP Code 3100


Limited

SAP Code 3100

ConcordCamera France

S.A.R.L

SAP Code3400


S.A.R.L

SAP Code3400

ConcordCamera HK

Limited

SAP Code 5100

ConcordCamera HK

Limited

SAP Code 5100

ConcordHenggangElectronics

Factory

SAP Code 5200


Factory

SAP Code 5200

ConcordShenzhenLimited

SAP Code 5300


SAP Code 5300

ConcordCamera GmbH

SAP Code 3300

ConcordCamera GmbH

SAP Code 3300

(US)

(US) (Canada) (UK and NorthernIreland)

(Germany) (France) (HK)

(PRC) (PRC)

ConcordKeystoneGraphics

SAP Code 4400


SAP Code 4400

Concord LatinAmerica

SAP Code 4300


SAP Code 4300

StarprintCorp.

SAP Code 4500

StarprintCorp.

SAP Code 4500

(US) (US) (Latin America)

ConcordCameraHungary

SAP Code 3500


SAP Code 3500

(Hungary)

Legend: Grey highlighted box represents a dormant company

Goldline(Europe)Limited

SAP Code3200

(UK and NorthernIreland)


SAP Code3200


Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Brauser

SAP Code3500

(Germany)

Peter Bauser

SAP Code3500

(Germany)

Concord L atinAmerica

SAP Code 4300

Concord

SAP Code 6100

(Australia)

Australia

Finance Organizational StructureSAP Company Codes

ConcordCamera Corp.

SAP Code 1000

ConcordCamera Corp.

SAP Code 1000


Corp.

SAP Code4100


Corp.

SAP Code4100


SAP Code 4200


SAP Code 4200


Limited

SAP Code 3100


Limited

SAP Code 3100


S.A.R.L

SAP Code3400


S.A.R.L

SAP Code3400

ConcordCamera HK

Limited

SAP Code 5100

ConcordCamera HK

Limited

SAP Code 5100


Factory

SAP Code 5200


Factory

SAP Code 5200


SAP Code 5300


SAP Code 5300

ConcordCamera GmbH

SAP Code 3300

ConcordCamera GmbH

SAP Code 3300

(US)


(Germany) (France) (HK)

(PRC) (PRC)


SAP Code 4400


SAP Code 4400


SAP Code 4300


SAP Code 4300

StarprintCorp.

SAP Code 4500

StarprintCorp.

SAP Code 4500

(US) (US) (Latin America)


SAP Code 3500


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)

Concord L atinAmerica

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 USconsolidation 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

Concord

CameraCorp.

SAP Code1000

[100%]

ConcordKeystone

Sales Corp.

SAPCode4100

[100%]

ConcordCamera

Canada

SAP Code 4200

[100%]

ConsolidateSubgroup

CCEurope

SAPCodeCG3000

[100%]

ConsolidateSubgroup

(CCGMBH)

SAP CodeCG3300

[100%]

Concord CameraFrance S.R.R.L

SAP Code3400

[100%]

ConsolidateSubgroup

(CCHK)

SAP CodeCG5100

[100%]

StarprintCorp.

SAP Code4500

[100%]

ConcordCamera

Hungary

SAPCode3500

[100%]

ConcordKeystone

Graphics

SAP Code4400

[100%]

ConcordLatin

America

SAP Code4300

[100%] [100%]

ConcordAustralia

SAP Code6300

(US)

(US) (Canada )

Concord Camera(Europe) Limited

SAP Code 3100

[100%]

(UK and

Nothern

Ireland)


SAP Code 3200

[100%]

(UK and

NothernIreland)

Concord Camera(CCGMBH)

SAP Code3300

[100%]

(Germany)

Peter Bauser

SAP Code3600

[100%]

(Germany)

(Europe) (Germany) (France)

Concord CameraHK Limited

SAP Code5100

[100%]

Concord

HenggangElectronics

Factory

SAP Code 5200

[100%]


SAPCode 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[OwnershipPercentage]Percentage]

ConsolidationUnit/

Company(Country)OwnershipPercentage

Concord

CameraCorp.

SAP Code1000

[100%]

ConcordKeystone

Sales Corp.

SAPCode4100

[100%]

ConcordCamera

Canada

SAP Code 4200

[100%]

ConsolidateSubgroup

CCEurope

SAPCodeCG3000

[100%]

ConsolidateSubgroup

(CCGMBH)

SAP CodeCG3300

[100%]

Concord CameraFrance S.R.R.L

SAP Code3400

[100%]

ConsolidateSubgroup

(CCHK)

SAP CodeCG5100

[100%]

StarprintCorp.

SAP Code4500

[100%]

ConcordCamera

Hungary

SAPCode3500

[100%]

ConcordKeystone

Graphics

SAP Code4400

[100%]

ConcordLatin

America

SAP Code4300

[100%] [100%]

ConcordAustralia

SAP Code6300

(US)

(US) (Canada )

Concord Camera(Europe) Limited

SAP Code 3100

[100%]

(UK and

Nothern

Ireland)


SAP Code 3200

[100%]

(UK and

NothernIreland)

Concord Camera(CCGMBH)

SAP Code3300

[100%]

(Germany)

Peter Bauser

SAP Code3600

[100%]

(Germany)

(Europe) (Germany) (France)

Concord CameraHK Limited

SAP Code5100

[100%]

Concord

HenggangElectronics

Factory

SAP Code 5200

[100%]


SAPCode 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[OwnershipPercentage]Percentage]

ConsolidationUnit/

Company(Country)OwnershipPercentage




June will not post beyond AAA’s fiscal year end. If the fiscal year ends in early July, then the postings inJuly will be backdated to June 30 th.

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 pricingrequirements. 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 onthe Account structures are in Section 3.1 on General Ledger.

AAA Chart of Account Relationships:

[SAP[SAP Enterprise ConsolidaEnterprise Consolida




(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 depreciationmethods have been defined in the Tax Depreciation Area for all Reporting Units with specific taxdepreciation 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.

Companycode(s)

Chart of depreciation

Depreciationarea: Book

Depreciationarea: Tax

Depreciationarea:

Group

A t Cl




Level 4: Cost Centers and Cost Center Groups. The Cost Centers represent departments withinmajor department categories (Level 3 Cost Center Groups). The Cost Center Groups are other department categories that are further sub-divided into more specific departments. Examples of Level 4 Cost Centers are Marketing, Finance and Production Line under Sales, Administrativeand Production Cost Center Groups respectively. Examples of Level 4 Cost Center Groups areDesign Engineering and Quality Engineering.

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

In addition to the standard cost center hierarchy described above, alternate hierarchies can bedefined specifically for reporting or allocation purposes. The European head office will be set upas an alternate hierarchy where European head office cost centers from each European companycode 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. Thedetailed cost center information is documented in Appendix 8.1 The naming convention for CostCenter Groups and Cost Centers will be described in more detail in Section 3.7 on Cost Center Accounting.

AAA BBB COST CENTER GROUPS:




Level 1 Description Level2 Description Level 3 Description Level 4 Description

CCGAAA BbbGrp 1000 CCC 1000-3 Supply Chain

1000-5 Sales

1000-6 Engineering 1000-611US Design

1000-7 Administration 1000-791Executives1000-795Information Technology

1000-796Finance

3100 CCUK 3100-3 Supply Chain

3100-5 Sales

3100-7 Administration

3300 CCGMBH 3300-3 Supply Chain

3300-5 Sales3300-7 Administration

3400 CCFR 3400-3 Supply Chain

3400-5 Sales


4100 CCUS 4100-3 Supply Chain 4100-333Warehouse/Storage

4100-5 Sales


4200 CCCA 4200-3 Supply Chain4200-5 Sales


5100 CCHK 5100 3 Supply Chain




3. Finance & Controlling Process Design Concepts

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

The business financial processes and system settings of the Finance and Controlling modulesare described in the following sections of this document:3.1 Financial Global Settings

3.2 General Ledger 3.3 Accounts Receivable3.4 Accounts Payable

3.5 Intercompany Financial Transactions3.6 Asset Accounting3.7 Cost Center Accounting3.8 Internal Order 3.9 Product Costing3.10 Profitability Analysis3.11 Budgeting / Planning3.12 Cash Management3.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 Range

SAPmodule

FI DocumentTypes

No. Rangeassignment

FI Document TypeDescription

Account Type

ReverseDocumentType

AM AA 01 Asset posting ADKMS AAAM AF 03 Dep. postings AS AF

AP KA 17 Other Vendor document AKMS KA

AP KG 17 Vendor credit memo AKMS KG

AP KR 19 Vendor invoice AKMS KR

AP KZ 15 Vendor payment KS KZ

AP ZP 20 AutoPayment Posting ADKMS ZP

AP ZV 20 Auto Payment clearing ADKMS ZV

AR DA16 Other Customer

document DS DA

AR DG 03 Customer credit memo DS DG

AR DR 18 Customer Invoice ADMS DR

AR DZ 14 Customer payment DS DZ

GL SA 01 G/L account document ADKMS SA

MM PR 48 Price change MS

MM RE 51 Invoice receipt AKMS REMM RI 52 Invoice receipt-Interco. AKMS RI

MM WA 49 Goods issue AMS WA

MM WE 50 Goods receipt AMS WE




•

AP - Accounts Payable (Financial Accounting)• AR - Accounts Receivable (Financial Accounting)

• GL – General Ledger (Financial Accounting)

• MM- Material Management (Logistics)

• SD – Sales and Distribution (Logistics)

• CM – Cash Management (Treasury)

MM related Document Types:

* Note that Purchase Order does not have accounting impact and hence no FI document type needs to be

mapped to PO document types.

‘PR’ – Price Change

Postings on Inventory Revaluation from MM (transaction MR21). ‘Price Change’ refers to the

change in Standard Price of the material, not the price difference between PO and Invoice that is

booked at the time of invoicing. Note this type of transaction does not have Reversal FIDocument Type. If the price changed need to be adjusted, a new transaction is posted, rather than

reverse the original posting.

‘RE’ – Invoice Receipt

Postings on Invoice Receipt transactions from MM (transactions MIRO/ MRRL)

‘RI’ – Invoice Receipt-Interco.

Postings on Invoice Receipt transactions for Invoice Verification triggered from IntercompanySales. The Invoice Verification step for intercompany sales are triggered by SAP in form of a batch generated automatically. For details, please refer to MM Conceptual Design Document.

‘WA’ – Goods Issue

Postings on Goods Issues or MM Transfer Postings. For detail definitions on Goods Issues/




Postings of Intercompany Invoice from SD transactions. A Stock Transport Order (STO) anddelivery 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 Return

Postings of Credit Memo from SD transactions as arose from Return. A Return Order (a specialSales Order Type) and return delivery need to be completed before Credit Memo for Return iscreated in SD.

‘RS’ – SD Rebate Credit MemoPostings of Rebate Credit Memo from SD transactions. A Credit Memo Request (a special SalesOrder 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 ininterpreting 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




Number Range Document no. from Document no. to

01 0000100001 0000199999

03 0000300001 0000399999

14 1400000000 1499999999

15 1500000000 1599999999

16 1600000000 1699999999

17 1700000000 1799999999

18 1800000000 1899999999

19 1900000000 199999999920 2000000000 2099999999

47 4700000000 4799999999

48 4800000000 4899999999

49 4900000000 4999999999

50 5000000000 5099999999

51 5100000000 5199999999

52 5200000000 5299999999

81 8100000000 819999999982 8200000000 8299999999

83 8300000000 8399999999

85 8500000000 8509999999

86 8600000000 8699999999

88 8800000000 8899999999

3.1.2. Currency




• During posting, the amounts are also saved in the parallel currencies. The amounts are translatedautomatically using Average Rate (M Rate for majority cases, EURX Rate for EU currenciestranslation 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 FIdocument 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 manuallyentered 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




• 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 toolsyou 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 exchangerate 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 arecarried 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 ReferenceCurrency. 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 participatingcountries in the EMU are to be used. This only applies to Average Rate conversion.

Example:




Exchange Rate Type Business Usage SAP configuration settings

Code Description Summary Details ReferenceCurrency

*Indicator:Calculationallowedwithinvertedexchangerate?

**EuropeanMonetaryUnion statutoryguidelinesmet?

EURX EMU -Conversionmethod notparticipant

Act asAverage ratefor alltranslationwith EUR

- Used for alltranslations withEUR- Direct Quoteshould be used

EUR N Y

M Average For Day-toDay postingand clearing,

the systemuses thisexchangerate type

- This exchangerate type mustbe entered in the

system and youmust also enter the exchangerates for this type

N/A Y N

C Closing Rate Period endforeigncurrencyvaluation

- This rateapplies to allcurrencies(including EUR)

N/A Y N

1001 HistoricalExchangeRate

Consolidation- ForeignCurr Translation

- Can be appliedper specific setof accounts inGroup COA

N/A Y N




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 arewithin the same document including entries of both companies, the exchange rate used will be the samefor both entities in this case.For period-end, Foreign currency valuations, Exchange Rates stated in Exchange Rate Type ‘C – ClosingRate’ will be used (for all currencies in this case, including EU currencies) for revaluating open itemsheld in foreign currencies (i.e. different from Company Code currency). For detail mechanism onForeign 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 4special 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 willb t ll d t ll




‘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 periodas well per account type.




3.2. General Ledger

GL/FI Posting

F I N A N C

E

Required

FI DocumentHeader

FI document Line Items

EnterHeaderDetail

- Company Code

- Posting/ Document Date- Reference no.

- Currency/ rate

Enter FI Line Item

Is it a B/Sitem?

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

Enter- G/L Account

- AmountText(if needed)

YES

Which CO objectto assign?

Enter another FILine item

END

Cost Center

FI Posting Only Integration to

CO(Controlling Only

P&LItem

Balance Sheet Item

COPA ProfitSegment

StatisticalInternalOrder

Optional

B

A

C

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

Real InternalOrder

Or

NO




• Balance sheet / profit and loss evaluations

The SAP General Ledger module provides the following function for all AAA companies acrossthe 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 toit.

3.2.1. GL Master Data

In SAP, the G/L account master records control the posting of accounting transactions to G/Laccounts and the processing of the posting data. Before you can make postings to a G/Laccount, 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 samechart of accounts can use the same G/L accounts.




Illustration on SAP COA Relationships:

[SAP[SAP Enterprise ConsolidatiEnterprise Consolidati(EC(EC --CS) module]CS) module]-- --

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 COA Group COA Country Specific COA

Business Usage

AAA Usage Day to Day Operation Consolidation Support governmentspecific format FinancialStatement generation




Operating COA Group COA Country Specific COA

Type of FinancialStatements(FS) generated

All individual AAACompany FS

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

Government specificformat FS

Example of AAA unitsdeployed

CCUS, CCUK, CCHK,etc.

Sub-group – HK, UK,Germany, etc.

Group – AAACorporate

CCSZ, CCFR

SAP specific information

SAP module FI-GL

(Financial Accounting – General Ledger)

EC-CS

(EnterpriseControlling –Consolidation)

FI-GL

(Financial Accounting –General Ledger)

Master Data Exist as a completeGL master data (COAsegment andCompany Codespecific segment)

Financial StatementItem (GroupAccount – accounton the Group COA)

Only exist as COAsegment of GL Master (account no. anddescription)

Linkage to FI-GL

Exist as a GL master data (COA segmentand Company Codespecific segment)

Linked to FI-GL by‘Group Account’field in ‘COAsegment’ of GLMaster

Linked to FI-GL by‘Alternate Account’field in ‘Company Codespecific segment’ of GLMaster

DocumentCreationFrequency

FI documents areposted real-time uponday-to-day businesstransactions in SAP

ECCS (consolidation)document are postedupon all postingsfrom FI-GL, online

No document will beposted. Reports willdraw values posted onFI-GL




The Global Operating COA will be presented in SAP as COA segment of GL Master. GroupCOA for AAA: CONC is set up for consolidation purpose. For details, please refer toSection 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 beenconfirmed. 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 toadditions/ 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 singleGlobal 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 GLtransactions.

• 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 financialreporting needs.

Since France and China government need the generation of financial statements (Balance




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 intodesired format. This financial statement format will satisfy French statutory reportingrequirements.

3.2.4. Special Purpose Ledger for CCSZ

For CCSZ, in addition to Country-Specific GL, a Special Purpose Ledger (FI-SL, separatefrom 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 willfollow 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 correctaccounting posting periods with Country-Specific GL no. for rendering of China specificBalance Sheets and P&L accounts.

Here is the summarized treatment on CCSZ’s financial books:

CCSZ’s day-to daypostings

China governmentspecific postings

COA Operating COA Country-Specific COASAP Module General Ledger (FI-GL) Special Purpose Ledger

(FI-SL)

Fiscal Year June 4-4-5 based Calendar year




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 Figure3.1.1 below.

General Ledger Master Data Maintenance

F I N A N C E

Disapprove

CCC reviewsrequest

A

Concord CameraSubsidiary submitsrequest for New GLaccount to CCC for

approval

Create new GLaccount forsubsidiary(FS00)




Figure 3.1.1 General Ledger Master Data Maintenance

General Ledger Master Data Maintenance

F I N A N C E NO

YESCreate Cost

Element

(FS00)

Create G/L Account

centrally in COA leveland 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

ElementDetail(FS00)

Enter G/L Account#and Company

Code[Create w/

Template]

Is this a P&Laccount?

Define G/LAccount

Details

A

Save AccountMaster Data

End




6200 Cost of Sales 6200 0000-6299 9999

6600 Selling Expenses (Var) 6600 0000-6699 99996700 Selling Expenses (Fix) 6700 0000-6799 9999

7000 General & Administrative Expenses 7000 0000-7099 9999

7100 Interest & Finance Charges 7100 0000-7199 9999

7200 Interest Income 7200 0000-7299 9999

7300 Intercompany Income/ Expense 7300 0000-7399 9999

7400 Other Income / Expense 7400 0000-7499 9999

7500 Income Tax Expense 7500 0000-7599 9999

8000 GAAP Reporting/Statutory

Adjustments

8000 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 (bycorporate)

• Account Group 9000 is reserved for creation of Secondary Cost Element in SAPControlling (CO) modules. This range will not be created as GL Master in FI. Due to theintegration nature of the FI/CO, Secondary Cost Elements share the same number rangeas FI, therefore a specific range is reserved. These are for cost allocations that are basedon secondary cost elements like statistical figures, for example, footage, number of heads per unit, etc.




Integration with Country-Specific COA

For CCFR and CCSZ, ‘Alternate Account’ field are set as required field. This ensures usersrequired to enter the Country-Specific GL for all GL creation in the Company-code specificsegment. 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 and3.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 segmentof 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 Specificsegment of GL Master. With this indicator, the GL account can only be posted viarespective 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 GLaccounts are set as ‘Automatically Post Only’, which ensures the value always in sync



Block A[OperatingCOA]

12345

6....

Block B

[Adjustment

GL]

Block C[Adjustment

FI-GLGL accounts

1. Day to Day

Operation

USGAAP

R e p o

r t s

AA

2. Local

GAAP

B

Concord Finance Multiple Reporting Views

3. Global TaxPlanning

R e p or t s

C

A+

B+C

D

Consolida-tion COA

R e p

or t s

INFO

from

FI

GROUP G/L123456.

.E...

All adjustment

GL fromFI

map todummy Group

Account in

EC-CS

[ ff i

E

Mgmt

Report

(COPA)

R e p or t s

INFO

from

FI

ValueFieldse.g.

*Gross Sales*SalesDeduction*COGS*Selling

Expenses*G&A

...

Block A[OperatingCOA]

12345

6....

Block B

[Adjustment

GL]

Block C[Adjustment

FI-GLGL accounts

1. Day to Day

Operation

USGAAP

R e p o

r t s

AA

2. Local

GAAP

B

Concord Finance Multiple Reporting Views

3. Global TaxPlanning

R e p or t s

C

A+

B+C

D

Consolida-tion COA

R e p

or t s

INFO

from

FI

GROUP G/L123456.

.E...

All adjustment

GL fromFI

map todummy Group

Account in

EC-CS

[ ff i

E

Mgmt

Report

(COPA)

R e p or t s

INFO

from

FI

ValueFieldse.g.

*Gross Sales*SalesDeduction*COGS*Selling

Expenses*G&A

...


3.2.6. Multiple Reporting Views for AAA

This section describes the approach in SAP to cater the AAA requirement of handlingmultiple accounting books for individual company. The following are summarizedrequirements:




3.3. Accounts Receivables

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

3.3.1. Customer Master Maintenance

Customer master records contain data that control how transaction data is posted and processed. This includes all of the information about a customer that you need to beable to conduct business with them. At AAA, customer master records will bemaintained by each Reporting Unit.

The master record is used in Sales and Distribution as well as Financial Accounting. Thereare two methods of creation for customers’ master data:

a. Create Centrally In Financial Accounting or Sales and Distribution module b. Create either in Accounting or SD module only

Customer Master Data are divided into 3 areas:

a. General data b. Accounting Datac. Sales Area Data




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 Range

DG Customer credit memo 1600000000-1699999999

DZ Customer payment 1400000000-1499999999

DR Customer invoice 1800000000-1899999999

All FI document types are listed in Section 3.1. A document type for a FI customer debit memos has

been added to the list.

SD debit memos are booked in FI as document type RD. SD customer returns are document type RR.Additional document types can be defined according to AAA’s requirements.

3.3.3. Trade Customer Master DataMaintenance

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

3 3 4 Non Trade/ Sundry Customer




Term

Code

Description Term Code Description

Cash On delivery Cash On delivery

5 Days Credit 5 Days Credit



One Month Credit One Month Credit


Two Month Credit Two Month Credit

The FI/CO Design team will continue to collect any outstanding payment terms from theFI/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 willneed to be catered for as well.

Payment receipt dates are calculated based on Base Line Dates in invoices. The Base LineDate is derived from the Document Date (same as invoice date) that is manually entered.




3.3.6. Accounts Receivable TransactionPosting

Figure 3.2.5.1 Billing/Invoicing from SD Module

Account Receivable - Create Invoice

F I N A N C E

S a l e

s &

D i s t r i

b u t i o n

Enter CustomerLine Item

(AR)

Simulate Posting

ServiceProvided toCustomer

AR Document Posted

Enter RevenueLine Item

(G/L)

Enter AR Invoice(Header Detail)

Sales OrderProcess

SD BillingDocument




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

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 invoicescreated in FI that need to apply sales tax, users have to manually select the correctrate before posting in to SAP




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




Incoming (Customer) payment

Account Receivable - Partial

Payment

F I N A

N C E

Incoming

Payment &

Remittance

AdviceReceived from

Customer

Full

Payment?

Partial

Payment

(FB-28)NO

YES

Selected Invoice onCustomer Account w/

info from Remittance

Advice

(FB28)

Payment

Posted

(FB-28)

View

Customer

Account

(FB-03)

Select Invoicefrom

Customer

Account

(FB-28)

Partial

Payment

Posted

(FB-28)

View

Customer

Account

(FB-03)

Small Difference will go into small

difference account




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 notyet been cleared are available in the system. Only after every open item in a document iscleared 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 acceptingany 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 fullamount 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 lineitem and document with the unpaid amount to replace the original invoice.

Both functions are available in the current system. However, the decision on whichfunction 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 AAABbb.

Full Payment

F f ll b ili h h d ill d l h




Generate Customer Statement

AAABbbThere will be two types of customer statement in AAA Bbb. Oneinternally 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 endrate. 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 Valuationmethod. 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 foreigncurrency balance sheet accounts are automatically posted to specific accountsassigned during the configuration. The amounts can be either a gain or loss, andare, therefore, posted to either a revenue or expense account stored under a specialkey.

The unrealized gain or loss is the difference between the exchange rate posted atthe time of booking the invoice and the current month end exchange rate. Areversal of this booking will be automatically created for next month to eliminate




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 Directors

6 Employees




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 areentered 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 thevendor 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

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.1for document type details.

3 4 3 Trade Vendor Master Data

Document type Description Number Range

KZ Vendor payment 1500000000-1599999999

KG Vendor credit memo 1700000000-1799999999

KR Vendor invoice 1500000000-1599999999




Customers Vendors

TermCode

Description Term Code Description

Cash On delivery Cash On delivery




One Month Credit One Month Credit


Two Month Credit Two Month Credit14 days 2%, 30 net 14 days 2%, 30 net14 days 3%, 30 net 14 days 3%, 30 net14 days 5%, 31 net105 days 3%, 120 net60 days net 60 days net55 days net30 days 3%, 45 days

net25. Of overnextmonth = between 56and 85 days/ 3%10. Of next month /3%45 days 3%, 60 net15. Of next month /

3%




Figure 3.3.2.1 Three-Way Matching Invoice Verification

Process Invoice Verification

F i n a n c e

P u r c h a s e

SAPPurchase

Order

SAP GoodsReceipt

Document

Save

Document(MIRO)

InvoiceVerificationDocument

Price & Qty within

tolerance allowed(3-way matching)?

BlockInvoice for

Payment

YES

Simulate

Posting(MIRO)

A

NO

Receive &Approve

Vendor Invoice

Enter

Invoice

3 Ways Matching:

Match Invoice with

POPrice & GR Qty

- Invoice auto-blocked by system

- Can be manually blocked

- Invoice can be parked until further investigation completed

Account Payable- Automated Payment

A

Invoice

VerificationDocuments

Execute

Payment Run

(F-110)

Payment Method:1.Cheque (+ Positive Pay File)

Release

Blocked

Invoices ready

forpayment




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 FinancialAccounting, Controlling, and Asset Accounting components.

Account Payable - Automated Payment (Cont’d)

B

Print Checks

Create Transfer File

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

Cr. Vendor 1

During the invoice matching, the invoice received from vendors (either on spot or after the purchase) will be matched against the purchase order and goods receipts given byPurchase 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 valuatedwith 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 bemaintained in the Reference field at the document header. The system will check thisfield 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 tocontinue with the same reference number. Relevant payment methods will default fromthe 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 processand the account posting is as follows:

Dr Expenses / Balance Sheet account




As in normal circumstances, debit notes are only required for scenario C where theinvoices 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.0

0.0

V0V1V3V4

V5

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

Subcontracting within EUCCGermany 0.0

16.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.0

V0V1

Exempt from input VATInput VAT




0.0

6.0

U0

U1

Exempt from A/P use tax

A/P use taxCCHK 0.0 V0 Tax exempt

CCWK 0.00.0

J0J1

Exempt from input taxInput tax

CCSZ 0.017.0

J0J1

Exempt from input taxInput tax

Each Branch will use one G/L tax account to record tax. Invoices for EU and nonEU purchases will contain the vendor VAT registration number and the ReportingUnit 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 intothe transactions. This will allow VAT reporting to meet statutory requirements.

Further analysis of the various purchase tax applications will occur duringDetailed Design.

Outgoing (Vendor) Payment

Full Payment

Various payments types such as cheques, wire transfer, and cash payment will bemaintained in the SAP system.

Payment

Method

Description Payment Medium Comments




Bank is needed

Payments are done either automatically or manually. Automatic payment processstarts with the auto-payment run on vendors’ invoices. System will propose thevendors’ 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 SAPsystem based on the payment types. For wire transfer the system will generateonly 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 thesummary 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 lineitems, 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 usingforeign 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 isi il t th ti f d t i d f th t F d




PaymentDifference for Vendor /Customer Based on Local Currency

Amount Percentage

Branch Currency Gain Loss Gain Loss

UK GBP 5 5 1 1

Germany EUR 5 5 1 1

Keystone USD 0 0 0 0

Corp USD 0 0 0 0

HK HKD 0 0 0 0

WK RMB 0 0 0 0

SZ RMB 0 0 0 0

France 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 asfollows:

a. Partial payment will keep the original invoice line item openuntil 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 newline item and document with the unpaid amount to replace the originalinvoice.

Both functions are available in the current system. However, the decision on




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 codenumber links individual documents together. The system generates line items automatically (receivablesand payables arising between company codes) in order to balance the debits and credits in each document.

Intercompany Invoice/ Payment - Create non-trade Invoice

F I N A N C E

ApprovedIntercompany

Transaction

Create GLPosting

(Enter Header

Detail)

Enter Transaction

Details in Co. 1

Line Item 1

Enter Transaction

Details in Co. 2

Line Item 2

Simulate

Posting

Review auto-generated

Intercompany

Payables/

Receivables

P tFI

FI document +Cross Company




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. Thecompany 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 andshould perform the posting in SAP'. AAA Corporate should impose future policy for IntercompanyPosting 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 whencreating the journal entries will be used if supervisors need to check the entries are correct before posting.

3.6. Asset Accounting

The Asset Accounting System (FI-AA) in SAP R/3 is used for managing andsupervising all the existing fixed assets in your enterprise. It also serves as asubsidiary 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




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 oneCompany Codes could be assigned to a single Chart of Depreciation. Each chart of depreciation alsoincludes the tax book.

Chart of Depreciation is a 3-character code that supports alpha-numeric format. As it is generally countryspecific, 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 5100

ZUS US Chart of Depreciation for AAA 1000, 4100

ZCA Canada Chart of Depreciation for AAA 4200

ZCN China Chart of Depreciation for AAA 5200*

ZUK UK Chart of Depreciation for AAA 3100

ZDE German Chart of Depreciation for AAA 3300

ZFR France Chart of Depreciation for AAA 3400

*Remarks : It is confirmed that no fixed asset management is needed in company code 5300 (CCWK) asall 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 indepreciation area level. One single Chart of Depreciation could have more than one Depreciation Area.




ZUS 01 Book depreciation Yes

15 Tax depreciation No30 Group currency depreciation No

ZCA 01 Book depreciation Yes

15 Tax depreciation No

30 Group currency depreciation No

ZCN 01 Book depreciation Yes



ZUK 01 Book depreciation Yes15 Tax depreciation No


ZDE 01 Book depreciation Yes



ZFR 01 Book depreciation Yes



3.6.3. Asset Class:

Asset Classes are used to classify fixed assets into different categories according to their natures and G/Laccount postings. The asset class catalog is relevant in all company codes in a client. That meansdifferent companies are sharing the same set of Asset Classes in the system. However, asset classes thatare 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 theunwanted Asset Classes.

An asset class could be defined as an 8-character code or less in SAP R/3 system. Since the assets are




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 avoidduplication 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 asa means for asset class identification. This setting is inline with the current numbering system of assetrecords 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 7digits are sequential running numbers. The asset classes and the corresponding number ranges are shownin the following table:

Asset

Class

Asset Class Descriptions Asset No. Range

(From)

Asset No. Range

(To)

10010 Automobile/Truck 101 0000000 101 9999999

10020 Plant & Machinery 102 0000000 102 9999999

10030 Computer Hardware 103 0000000 103 9999999

10040 Computer Software 104 0000000 104 999999910050 Furniture & Fixture 105 0000000 105 9999999

10060 Fax and Copy Machine 106 0000000 106 9999999

10070 Office Equipment 107 0000000 107 9999999

10080 Leasehold Improvement 108 0000000 108 9999999

10090 Warehouse Equipment 109 0000000 109 9999999

10110 Building 111 0000000 111 9999999

10120 Mould & Tools 112 0000000 112 9999999

10130 Building Improvements 113 0000000 113 999999910140 Land Usage Right 114 0000000 114 9999999

10150 Capitalised R&D Cost After AFS (will bei d)

115 0000000 115 9999999




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

method

Fax and Copy Machine 12 Straight line Double declining ½ year




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

scrap valueOffice 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 valueMould & 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

life (month)

Book depreciation Tax depreciation

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

life (month)

Book depreciation Tax depreciation




3.6.6. Asset Master Maintenance:

An asset master record is a record for an individual asset that contains all the relevant information andcontrol parameters for an asset in Asset Accounting. An asset master record has to be created before anytransaction of an asset could be done. Normally, the first transaction to be done for a fixed asset is thefirst acquisition posting. Asset Accounting in SAP R/3 is integrated with the MM module in such a waythat 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. Purchasesare 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 Data

General 1. Contains general information of the asset such asdescriptions, quantity, serial number and inventorynumber which could be printed out from on a barcodelabel2. Contains posting information such as the date of capitalization posting and the date of retirement posting. These dates are updated by the systemautomatically by the relevant transaction you posted in

the systemTime-dependent Time-dependent allocation of cost center of which the

depreciation expense will post to. The same asset mayb i d t diff t t t i diff t




be defaulted by the system according to individual

asset classes. The depreciation start date will bedetermined 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)

Asset

PRT Master

Routin

g

Production Order

Asset

PRT

Routin

g




3.6.7. Asset Transactions

Figure 3.5.8 Asset Transactions

Asset Transactions Document Types :

Standard document types available for the asset transactions are :

Asset Accounting- Asset LifecycleTransaction

F I N A N C E

Enter DepreciationDetail(AFAB)

SaveDocument(AFAB)

ExecuteDepreciation Test Run(AFAB)

Display Log(AFBP)

Intercompany Asset Lifecycle

Defi ne TransferDetail .(eg. Companyto Company; AssetDetails)(ABT1N)

SaveDocument(ABT1N)

Asset Retirement

DefineAssetRetirement

SaveDocumentMonth-EndAsset

TransactionsCompleted?

Post missingAsset

Transactions

NO

YES

Can RetireAssetA) WithRevenue(F-92)B)Without RevenueC)By scrapping(ABVAN)




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 assetaccounting document will also be generated to store the detailed information of the transaction in assetaccounting. Besides, the posting date of the document will be copied into the asset master as the

Asset Accounting- Post Asset External Acquisition

P U R C H A S E

F I N A N C E

CreateAssetMasterAS01

PurchaseOrderApproved?

GoodsReceipt tomatchPurchaseOrder

Pending forFurther Adviceupondiscussion

NO

AssetRequest

Approved

CreatePurchaseOrder YES

InvoiceReceipt tomatchPurchaseOrder/Post Asset External

Acquisition




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 modulesin SAP.

In AAA, “what if”analysis is required to provide a simulation on the depreciation changes if the depreciationmethod or the expected useful life is changed. However such changes made in the asset master records aregenerally the “actual” changes which will have actual posting impact in G/L. To provide a workaround solutionfor the “what if” analysis, it is suggested that an additional depreciation area (i.e, depreciation book) will be addedto capture the changes and provide the depreciation amount after the changes. This additional book will bedefined 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 transactioncan be posted in Asset Accounting. A customer master record in SAP is needed before this transactioncould be done.

Information that is required to be input for this transaction is the asset being sold, customer master, thesales proceed amount and the revenue G/L account of the transaction. The system will automaticallygenerate 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 acustomer 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 100




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 bymeans of settlement of other CO objects. In the case of R&D development, the costsincurred in the development will still be posted into an Internal Order (which is a costobject 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 inInternal Order.

3.6.7.1.2. Settlement of AUC

When the asset under construction has come to a stage where depreciation should start, asettlement should be done to that AUC record in order to settle the amount captured inthe 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 (usuallymonth end) processing, settlement of AUC is not part of a month end processing that hasto be done every month. The settlement of AUC actually is done on an ad hoc basis or atany 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 isreached.

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.




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 inCO. However, the detailed depreciation amount of each asset will also be stored in AssetAccounting such that each unique asset master record will also have its unique posteddepreciation amount. Besides, after each depreciation run, the system will issue a reportwhich list out the depreciation posting amount of each individual assets as a record. Thisis 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 AssetAccounting. The year end closing is (i.e. fiscal year change) is just to open the next fiscalyear 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 isadvised that the job should be done in a background mode and the system will convert allthe 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 withinorganizational units of a company. At AAA, these units are represented by departments withineach Reporting Unit. SAP cost centers have been arranged in a hierarchy to reflect AAA’sdepartment structure that facilitates internal reporting and accountability. Each cost center

generally represents a department or unit that is the responsibility of a manager. Managers canthen monitor the performance of their departments by accessing reports on their cost centers.




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 tothe G/L in the FI module

GL/FIPosting

F I N A N C E

Required

FI DocumentHeader

FI document Line Items

EnterHeaderDetail

- CompanyCode

- Posting/ Document Date

- Referenceno.- Currency/ rate

Enter FI Line Item

Is it a B/Sitem?

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

Enter- G/L Account

- Amount- Text (if needed)

YES

Which CO objectto assign?

Enter anotherLine item

NO

END

Cost Center

FI Posting Only Integration toCO(Controlling Only

P&LItem

Balance Sheet Item

COPA ProfitSegment

StatisticalInternalOrder

Optional

B

A

C

D

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

Real InternalOrder

Or




Sales, being 6

Supply Chain being 3, Production being 4

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

The last 2 digits represent a sequential number 51-79100

Cost Center Grouping Number Convection

The first 4 digits represent the Company Code 5100-791

The next digit represent the 5 major functional grouping which areAdministration being 7Engineering, being 6Sales being 5Supply Chain being 3Production being 4

5100-791

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

In addition the European cost centers will be added after the Design Document stage. These costcenters will be included in France, UK and Germany’s Administration, Sales and Supply Chainfunctional groups

3.7.2. Statistical Key Figures

Statistical key figures serve as a basis for internal allocations and as references in the key figure




• 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 monitoringof 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 bemonitored continuously. The overhead costs assigned to the overhead cost orders are settled (infull) 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 firmand cases for AAA Bbb Corporation.

The order type determines the following:

The Order Category




For each order type, you must specify whether you want to use commitments

management (contractual or scheduled commitment that is not yet reflected in FinancialAccounting but will lead to actual expenditures in the future).

For example when entering into contract such as a Purchase Order, the commitment costof this PO can be reflected in the internal order and this amount will be reduced everytime a goods receipt is done based on this PO. This allows scheduled costs that have notimpacted 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 canactivate integrated planning as a default value. When required, you can change theindicator in the order master data.

Status Management

An order can pass through many statuses. The status controls, for example, which businesstransactions are allowed on the order. For example, the system will not allow any posting into anorder 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 inthe detailed design phase.

3.8.2. Order Actual Transaction Posting




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 capitalizedexpenses 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 allcosts 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

SettlingCosts inanInternal Order -- R&DScenario

F I N A N C E

R&D

Goods Receipt/Invoice

Receipt (wi thI/Oassigned)

FI DocumentProcessing(with I/ Oassigned)

ExpenseValue Posted

to InternalOrder

Enter AUCnumber

as receiver i n

settlement rule

MonthEndSettlement

to AUC

Afterfi rst

Shipment

Settlementtoa real

Assets

NO

YES




3.9. Product Costing

3.9.1. Logistics Master Data

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

Logistics Master data Major Usage

Material master (MRPviews)

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 rawmaterials and the consumption G/L account (throughaccount determination valuation class)

Material master (Costingview)

Provide costing calculation control parameters such as overheadgroup, 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 costcalculation when the inventory price is not yet available in thematerial master

Purchasing info record of subcontracting

Provide subcontracting labour cost for subcontracting materials




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 calculatethe 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 anadditional dimension to sub-divide or classify raw materials into different categories for reporting and analysis purposes in product costing.

Gl b l S l i h O d b i i




Overhead group

Overhead group is another parameter that is being entered into the costing view in thematerial 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 separatecategories according to the need of production royalty calculation. One group represents

production royalty is needed and the other group represents production royalty is notrequired. 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 finishedgoods 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 todifferent 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



Gl b l SAP I l t ti P Ph O P d b Fi D i T




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

Activity price Standard activity rates for the year Planningversion 0

Subcontracting cost

Effective price from subcontracting purchasing inforecord

Generaloverhead

allocation

Percentage overhead keys and quantity overheadkeys for royalty

Pricing control of costing variant for Net Billing:


control

Material cost 1. Inventory valuation price from accounting view

of material master 2. Effective price taken from purchasing inforecord(Th b i j li i

Global SAP Implementation Program Phase One Prepared b Finance Design Team




Pricing control of costing variant for RFQ:


control

Material cost 1. Plan price 1 from material master (this price is to be maintained manually by users on selectivematerials)2. Inventory valuation price from accounting view of material master 3. Effective price taken from purchasing info record

Activity price Standard activity rates for the year Planningversion 0

Subcontracting cost

Effective price from subcontracting purchasing inforecord

Generaloverheadallocation

Percentage overhead keys and quantity overheadkeys 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 CostApproaches

Finished Goods Inventory in Production Plant 5100

Global SAP Implementation Program Phase One Prepared by: Finance Design Team




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 planning

The activity type prices in AAA are the standard labour and overhead rates which will be appliedto 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





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 couldenter a monthly or yearly percentage rate by maintaining different validity period.

This activity has to be done before you can calculate the correct product cost estimate.

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

This activity has to be done before you can calculate the correct product cost estimate.





3.9.7. Cost Estimate Calculation

This is the process for calculating a product cost of a product. You will have to calculate a costestimate of a product in the following major scenarios:

1. Calculation of the standard production cost estimate of a new product and use thestandard cost estimate as the standard price for future inventory valuation2. Calculation of the new standard cost estimate of an old product if you want to

revaluate that inventory valuation price of that product3. Calculation of a new standard cost estimate of a product for purposes other thaninventory valuation (such as for Net Billing and other quotation reference or other

)

Product Costi ng - Process OverheadRate, Acti vity Rate for t henext peri od

< F u n c t i o n >

Run activi typri ces

cal culati on

Activi ty pricescalculated by

thesystem

Calculatestandard

cost

B

Enter budgetedcosts of the costelements of the

acti vity types inCost Center

Planning

Enter budgetedquantity of the

activi ti es in CostCenter Planning

Enter producti onoverhead rates into

the system

Global SAP Implementation Program – Phase One Prepared by: Finance Design Team




different planning version

Consumption of VAT for testing batteries

Fixed amount per unit of product Fixed amount based on quantityoverhead. This item does not existin inventory valuation

Consumption of VAT for testingfilm

Fixed amount per unit of product Fixed amount based on quantityoverhead. This item does not existin inventory valuation

All part costs Summation of BOM item part costs A specific set of exchange rates is being used to convert the part pricesinto USD

The calculation logic for all other cost items will be the same as the inventory valuationcalculation

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 costingcalculation for selective materials only.

3.9.8. Standard Price Update fromStandard 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. Thatmeans the steps are only required for inventory standard price update. Cost estimates that areused 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 thestandard cost estimate has been marked and released to the material master. That means even if

h l l d d d i i d i f ld d h ld





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 NewProducts

In AAA, the development of a new product consist of many different phases. At the early stage,a material number may not be available for the new product. But AAA finance still needs to

come up with an early estimation of product cost of the new product. In SAP, this process could be done via Reference and Simulation Costing.

The detailed requirements and the solution of this issue will be defined in the detailed design phase.

Product Costing - Process Standard Cost Estimates for the next period

F I N

A N C E

Individual

Costing run

Yes

No

No

Current month

Error in cost

calculation?

Beginning of the nextmonth

End

Sent error messages to

production/MISdepartment for

corrections

Individual

material/mass

processing?

FromB

Calculate

standard cost

estimates

individually(CK11N)

Mark standard

cost estimates

individually(CK24)

Download

standard cost

ti t ith

Releasestandard cost

estimates

individually

(CK24)




Global SAP Implementation Program Phase One Prepared by: Finance Design TeamConceptual Design Document – Finance & Controlling Approved by: XXXXXXX

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 postingwill 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 allocation

In addition to raw material consumption, the production time consumed in the productionorder 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) usingsecondary 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 beingcharged from the production cost center to the production order.





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 fromthe 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 alsoincluded the absorption of the standard labour cost, the standard overhead cost and thegeneral 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 rawmaterial 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 asfollows :

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





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 FIgeneral ledger is just an accrual posting for the costs that have not yet been absorbed bygoods 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, theremaining 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 postedand 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 usageof 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) WIP ill b d d h i ill b f ll





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 forFinished Goods

Production order of finished goods are used to manage the production of the finished products. In most cases, this present the final packing process in AAA. But actually thewhole production order execution process will be exactly the same as the orders for semi-finished goods

Raw material consumption at backflushing

Materials used for final production of finished goods and the required semi-finishedgoods 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 goodsare 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 productionorder




p g p y gConceptual Design Document – Finance & Controlling Approved by: XXXXXXX

Absorption of Production Cost to Inventory at Goods Receipt

The production costs in the finished goods production order will be capitalised intofinished goods inventory during goods receipt (i.e. backflushing). But the productionorder cost estimate (i.e. the plan cost of the production order) will be used (instead of thestandard 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 standardlabour 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 asfollows :

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 rawmaterial cost have been posted and general overhead rate is 10%. That means the generaloverhead being allocated to the production order will be $10.00. The posting will be asfollows :

Dr. General overhead cost (to production order) 10

Cr. General overhead cost absorption (from cost center) 10-





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 outputqty), 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 bereversed 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 productionvariance 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 totalactual cost incurred in the production order.





Product Costing- Producti onOrder PeriodEndProcessing

F i n a n c e Individual

order/mass

processing?

Start

Individual

processingof WIPcalculation

(KKAX)

End

Individualprocessingof

variancescalculation

(KKS2)

Individual

processingof overhead

allocati on(KKAX)

Individual

processingof productionordersettlement (KO88)



(KKS2)

Individual


allocati on(KKAX)


productionordersettlement (KO88)

Individualprocessingof WIP

calculation(KKAX)

Product Costing- Producti onOrder PeriodEndProcessing

F i n a n c e Individual

order/mass

processing?

Start

Individual

processingof WIPcalculation

(KKAX)

End



(KKS2)

Individual


allocati on(KKAX)

Individual

processingof productionordersettlement (KO88)



(KKS2)

Individual


allocati on(KKAX)


productionordersettlement (KO88)

Individualprocessingof WIP

calculation(KKAX)




Conceptual Design Document – Finance & Controlling Approved by: XXXXXXX

3.10. Profitability Analysis

This is the highest organisation level in the Controlling (CO) module (for Cost Accounting

purposes), in which the profitability of the company can be viewed and analysed in multiple

dimensions, like plant, product characteristics, sales organisations, distribution channels, etc.

These dimensions are termed as ‘Characteristics’ in the SAP CO-PA module.

The aim of the module is to provide your sales, marketing, product management and corporate

planning departments with information to support internal accounting and decision-making.

CO-PA lets you evaluate market segments, classified according to various characteristics such as

products, customers, or strategic business units such as company codes, etc. with respect to your

company's profit or contribution margin.

In AAA, CO-PA will serve both analysis needs from Finance and Supply Chain users. Due to the

integration nature of SAP, necessary Sales/ Profit data are centralised in COPA for differentanalysis 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:

Th COPA ti i th d i d t l fl t th i iti l i f ti th i d





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 Deployment

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

• Costing-Based COPA

• Accounting-Based COPA

During the design phase, white paper has been issued on the comparison on different COPA

method. AAA Management has confirmed that Costing-based Profitability Analysis will be

deployed by AAA. This section highlights some of the major comparison and will focus on the

rational why Costing-based COPA is the preferred method for AAA.

Common Structure – ‘Profitability Segments’

Both methods store Cost of Sales information in different ‘Profitability Segments’. Each

unique combination of Characteristics forms a specific ‘Profitability Segment’.Examples of Characteristics: Product No., Product Gp, Plant, Company Code, Customer

No., Sales Area, Distribution Channel, Region, etc.





Value Fields Revenue/ Cost Elements

Level of

analysis

t Each ‘Value Field’ is user-definable

t Can be lower level of details than GL

accounts

t Can be same level as GL accounts

(1:1 relationship with accounts in FI)

t 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’

t Revenue

t Promotional Expenses

Example of ‘lower level of details

than GL accounts’

t Cost of Goods Manufactured - Direct

Material

t Cost of Goods Manufactured -

Indirect Material

t Cost of Goods Manufactured - Direct

Labor

t Cost of Goods Manufactured -

Indirect Labor

t GL account – Revenue

t GL account – Cost of Goods Sold

t GL account – Sales Allowance

t GL account – Prod. Price Variance

t GL account – Salesperson salaries

t GL account – Promotional Expenses

t …

t And all other P&L GL accounts

posted to ‘Profitability Segment’

Reasons for adopting Costing-Based COPA

Global SAP Implementation Program – Phase One Prepared by: Finance Design Teaml i i lli d b




o Accruals: It is possible that accrued values are posted in COPA (might be triggered

by program in Sales Order conditions), without any posting in FI legal book

o 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 tieto 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 youanalyze 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 businessrequirement.

As a result of the COPA/BW warehouse, this will be finalized early Jan.

Characteristics

AAA Term SAP Term [Proposed]CUSTOMER TYPE Distribution Channel

[Sales Organisation]

Global SAP Implementation Program – Phase One Prepared by: Finance Design TeamC t l D i D t Fi & C t lli A d b XXXXXXX




Characteristics

AAA 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 ModelCode'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 Team

FLIM SPEED TBC from MM/PP Team

FLASH TYPE TBC from MM/PP Team

MOTOR TYPE TBC from MM/PP Team

ZOOM TYPE TBC from MM/PP Team

Power Zoom TBC from MM/PP Team

FOCUS TYPE TBC from MM/PP Team

DISPLAY TYPE TBC from MM/PP Team

SENSOR TYPE TBC from MM/PP Team

RESOLUTION (MP) TBC from MM/PP Team

PACKAGE 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 SAP





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 youcan analyze quantities, revenues, sales deductions, and costs for profitability segments inprofitability analysis or contribution margin accounting. You are able to define the revenues andcosts 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 businessrequirement.

Value Fields


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 ReportNET SELLING PRICE Calculated Field in COPA Report





Value Fields


SPC LABOUR COST New Value Field [from COPC]

SILKSCREEN LABOUR COST New Value Field [from COPC]

PACKAGE LABOUR COST New Value Field [from COPC]

TOTAL LABOUR COST Calculated Field in COPA Report

SPC 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 Report

TOTAL GENERAL OH COST Calculated Field in COPA Report

FUJI / DIGITALROYALTY COST New Value Field

MARKETING BRAND ROYALTY New Value Field

TOTAL MANUFACTURING COSTCalculated Field in COPA Report

Freight and Duty Cost New Value Field

COST OF GOODS SOLD PERUNIT

Calculated Field in COPA Report

GROSS PROFIT PER UNIT Calculated Field in COPA Report

CONTRIBUTION MARGIN DIGCAM T SUPP


CONTRIBUTION MARGIN REPCOMM US


GROSS SALES TOTAL Calculated Field in COPA Report

NET SALES TOTAL Calculated Field in COPA Report

Total FOB Commission Calculated Field in COPA Report

TOTAL COST OF GOOD SOLD Calculated Field in COPA Report

TOTAL GROSS PROFIT Calculated Field in COPA Report

TRANSACTIONUNITCOST TBC from SD Team

TRANSACTIONTOTALCOST TBC from SD Team

Global SAP Implementation Program – Phase One Prepared by: Finance Design TeamConceptual Design Document Finance & Controlling Approved by: XXXXXXX




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 thesales relationship with the Customer. Each Customer will therefore has a unique ‘ResponsibleBranch’. 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 thisinformation. 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 toCCUK. Respective Sales Revenue, COGS, Allowances will all be presented as if the salestriggered 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:CCUSCCCACCUK

CCGECCFR CCJP*





For AAA, there are a number of Parnter Functions defined per each Customer:

Partner Functions(Customer Related)

Definitions Usage in SAP

Sold-to-Party t A person or company thatplaces an order for goods or services.

t Contains data on sales, such asthe assignment to a sales officeor a valid price list

t SD: Generate Sales Order t COPA: Primary data in

updating COPACharacteristics. Every lineitem ‘Customer no.’ field ispopulated with ‘Sold-to Party’

no. Other characteristics arederived from it

Ship-to Party t A person or company thatreceives goods.

t The ship-to party may notnecessarily be the sold-to party,the bill-to party, or the payer.

t Contains data for shipping,

such as unloading point andgoods receiving hours

t SD: Generate Delivery

Bill-to Party t A person or company thatreceives the invoice for adelivery or service

t The bill-to party may notnecessarily be the payer of thebill.

t Contains the address and dataon document printing andelectronic communication

t SD: Generate Billing

Pay-to Party t The payer may not be the bill-toparty

t FI: Accounting Posting of theSD Billing document will be





3.11. Budgeting/Planning

Annual Budgeting

A c c o u n t D e p t

( C o r p o r a t e )


( H K )

R e p o r t i n g U n i t s

( & R e s p e c t i v e

D e p

t )

S u p p l y C h a i n

1.Sales ForecastResult for

coming yearAs a CO Plan

version A

2. Copy as abasis forAnnual

Budgeting

3. ReviewBudgeting

Data

4. ErrorExist?

5.InformSales Deptto Fix Error

7. Informother Deptfor Annual

Bud

11.PrepareData for

freight/ dutybudget

12. Input freight /duty budget in

COPC

13.Budget COGSbased on Sales Qtyautomatically in

COPAAND

8.Prepare Datafor Std. Cost

Estimate

9.Perform StdCost Estimate

in COPC

10.InformCorporate of

Budget Completed

14.Budget on

Departmentalcost in CCA

15.Allocation inCOPA Needed?

17. Perform Budgeting

Analysis vs ActualAnalysis in CCA

16.A

YES

NO

YES

NO

23.





Annual Budget (Cont')

F I N A N C E

APerformAllocation from

Cost Center to ProfitSegment (COPA)

If necessrary

PerformTop DownDistribution in COPA

If necessrary

END





Annual Budgeting (Page 3)


( C o r p o r a t e )

Approved

No

Submit reviewed budget

Consolidate P&L

Budget

AdjustConsolidated

P&L Budget

END

B

Review bySenior

Management




Conceptual Design Document Finance & Controlling Approved by: XXXXXXX

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 EnterpriseControlling – Consolidation (EC-CS) module directly. A specific Plan Version will be

defined in EC CS for the B dgeting p rpose Plan ers s Act al anal sis on





Version Descriptions Usage AAA BusinessProcesses

Type of CostsCaptured

0 Master Version -Store Actual/ Planvalues-Used for reporting-Required by SAP

Actual postings Actual/ Plan

050 Sales Forecast -Weekly Sales Forecastby Supply Chain

Sales Forecast Plan

100 Annual Budget – fromSales Forecast

-Data copied fromversion 050

AnnualBudgeting

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 onversion 110

AnnualBudgeting

Plan

200 Annual Budget –Corporate Review

-Amendment on version120 and finalize amountfor the year

AnnualBudgeting

Plan

210 Annual Budget 1st Qtr–Corporate Review

-Data copied fromversion 200

AnnualBudgeting

Plan

220 Annual Budget 2nd

Qtr–Corporate Review

-Data copied fromversion 210, withadjustments for 1st Qtr.

AnnualBudgeting

Plan

230 Annual Budget 3rd Qtr–Corporate Review

-Data copied fromversion 220, withadjustments for 2nd Qtr.

AnnualBudgeting

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 companiescan always refer to value of this version when performing the necessary analysis (e.g.measurement on departmental/ reporting unit performance). This avoids the unnecessary

f i th t i ht h d b t Pl V i d i th t





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 planningdata input.

SAP Embedded Excel

• MS Excel template is embedded into SAP Graphic User Interface (GUI). Major SAPfunction can be used. Users can have the function of Excel during planning as well. Data aresaved directly into SAP database upon completion.

MS Excel upload

• MS Excel used as an offline tool. This enable decentralised Budgeting for AAA. Userscan 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 thisphase of SAP implementation, Internet Planning is not an available option for AAA at themoment.

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. SAPPlanning modules involved:

• CO-OM (Controlling – Overhead Cost Controlling)

• CO-PC (Controlling – Product Costing)

• CO-PA (Controlling – Profitability Analysis)





3.12. Cash Management

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, cashbalance on a given date)

+

Cash Liquidity Forecast(Future cash inflows & outflows)

+

Cash Concentration(Sweeping account balances of several bank accounts to onetarget bank account)

A/P

Open invoiceswith due date

A/P


A/R


A/R


Bank Accounts

Confirmed cashaccount

Bank clearingaccounts

Bank Accounts

Confirmed cashaccount

Bank clearingaccounts

A/R


A/R


IncomingPayments

IncomingPayments

Confirmed CashBank Accounts

Postings

Confirmed CashBank Accounts

PostingsPayment ClearingAccounts Postings

Deposit ClearingAccountsPostings

1000

Deposit Clearing

Deposit ClearingA/R

10001000

1000 1000 1000

Confirmed Cash A

O t Chk Cl i O t Wi Cl i

A/R

1000




p g g pp y

Cash Management

m i t m e n t

y

F I N A N C E

1-week Projection CashReport with:- Cash Receipts- Cash Disbursements- Intercompany transfer (wire)

Cash Reports include:

- Cash Position- Cash Liquidity Forecast- Cash Concentration- Weekly variances/projections

Data in Bank ClearingAccounts from A/P, A/Rtransactions reconciledwith Bank Accounts

Bank Statementreceivedelectronically

Send ApprovedCash

Disbursements

Approve

Receive BankStatement

Corporate

collectsBranches?cash

data

CreateConsolidated

Cash ReportsReconcile CashAccounts withBank Statement

ApproveIntercompany Transfers




p g g pp y

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 Records

Memo records will be used by AAA to include additional liquidity information (e.g. anticipated

incoming and outgoing payments) in short-term planning which does not trigger actual bank

transactions, AR/AP subledger postings

Cash management memo records can be created as individual entries or using fast entry.

The entry is split into three parts:1. Planning data (date, account - cash management account name, expiration date if required)

2 Amount data (including currency exchange rate)




p g g pp y

3.12.3. Cash Position

The cash position is the result of the entry, by value date, of all the payments in a given, shorttime 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, sinceSAP Treasury modules like Loan Management, Market Risk Management are not in-scope

for Release One of the SAP Implementation in AAA

Cash Management Groupings for Cash Position

After the bank statements are posted in FI, the account transactions can be displayed in

the cash position. The balances in the bank accounts, which you can display using the

cash position, form the basis for planning decisions. Cash Management Groupings areneeded 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 eachcase, a clearing account, on a lower level and per processing type. Clearing accounts are

defined to meet specific business needs.




g g y

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 levelAll 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




Currency Display in Cash Position Report

Specific currency can be specified in the Display field. You can use the currency fields todisplay the foreign exchange risk. On the one hand, you can show the cash position split

by currency. You can also display the extent of your currency exposure from the cash

position. The average rate is usually used for the translation from planning currency to

display currency. If you want to use a different rate for the translation, make the

appropriate specification in the rate type field.

3.12.4. Liquidity Forecast

The cash management module is integrated with both MM and SD modules such that thecommitment information can be directly obtained through these modules.

Liquidity Forecast enables AAA (both subsidiary’s Accounting Dept or Corporate) obtainmedium to long term commitment and subledger information. All the Purchase order and salesorder information will be directly extracted and place into the liquidity forecast for analysis. Thevalue date for both purchase orders and sales orders will be based on the delivery date added tothe payment term. All the vendors and customers can be categorized to different groupings toenhance their “visibility” in the liquidity forecast position.

Memo records are used to supplement any additional information which cannot directly obtainedfrom 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)




Line items resulting from special transactions are transferred to a special level. Use Planning

Levels that begin with "F" as these are FI postings. SAP suggests using the special G/L indicator

as the second letter: Example: FF for down payment requests/ FC for LC payments.

3.12.6. Electronic Bank Reconciliation

The electronic bank statement is used to automatically assign incoming and outgoing payments to

house bank accounts when they relate to items already posted in the system to

customer/vendor/clearing accounts and, where appropriate, the clearing of them.Each uploaded electronic bank statement will be assigned with a unique no. in SAP and can be

printed retrospectively.

Steps in Electronic Bank Reconciliation:

1. Electronic Bank Statement file (in SWIFT MT940 format) is extracted from HSBC

Hexagon

2. Data (SWIFT MT940 for HSBC Hexagon) is imported into a temporary dataset in

SAP

3. Batch input sessions are generated (per bank statement: one session for G/L

Accounting and one for Subledgers- AR/ AP). Bank accounting and subledger

accounting batch session can be executed separately or jointly

4. Posting rules and account determination are defined in TR-CM customization

5. As an electronic bank statement is being imported, the system identifies thetransactions in it and determines how they are posted.

6. The note-to-payee fields in the electronic bank statement contain various information




3.12.7. Cash Concentration

Cash concentration involves moving the balances from various bank accounts to one targetaccount, 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 companycode, 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



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

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Camera Canada

SAP Code 4200

Concord

Camera Canada

SAP Code 4200

Concord

Camera(Europe)

Limited

SAP Code 3100

Concord

Camera(Europe)

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)

ConsolidationConsolidation

Unit/Unit/

CompanyCompany(Country)(Country)

[Ownership[Ownership

Percentage]Percentage]

Concord

Keystone

Graphics

SAP Code 4400

Concord

Keystone

Graphics

SAP Code 4400

Concord Latin

America

SAP Code 4300

Concord Latin

America

SAP Code 4300

(US) (Latin America)

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Camera Canada

SAP Code 4200

Concord

Camera Canada

SAP Code 4200

Concord

Camera(Europe)

Limited

SAP Code 3100

Concord

Camera(Europe)

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)


Unit/Unit/




Concord

Keystone

Graphics

SAP Code 4400

Concord

Keystone

Graphics

SAP Code 4400

Concord Latin

America

SAP Code 4300

Concord Latin

America

SAP Code 4300


Concord

Henggang

Electronics

Factory

SAP Code 5200

Concord

Henggang

Electronics

Factory

SAP Code 5200

Concord

Shenzhen

Limited

SAP Code 5300

Concord

Shenzhen

Limited

SAP Code 5300

(PRC) (PRC)

Goldline

(Europe)

Limited

SAP Code3200

(UK and Northern

Ireland)

Data CollectionData Collection

Validation of DataValidation of Data

Currency TranslationCurrency Translation

Inter-Unit EliminationInter-Unit Elimination

Consolidation of InvestmentsConsolidation of Investments






CC ConsolidatedFinancial Statements

Consolidation

Procedures












Consolidation

Procedures

Peter Bauser

SAP Code 3600

Concord

SAP Code 5300

Concord

Camera

Australia

SAP Code 6100

(Australia)

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Camera Canada

SAP Code 4200

Concord

Camera Canada

SAP Code 4200

Concord

Camera(Europe)

Limited

SAP Code 3100

Concord

Camera(Europe)

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)


Unit/Unit/




Concord

Keystone

Graphics

SAP Code 4400

Concord

Keystone

Graphics

SAP Code 4400

Concord Latin

America

SAP Code 4300

Concord Latin

America

SAP Code 4300


Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Camera Canada

SAP Code 4200

Concord

Camera Canada

SAP Code 4200

Concord

Camera(Europe)

Limited

SAP Code 3100

Concord

Camera(Europe)

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




Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord

Camera

Hungary

SAP Code 3500

Concord

Camera

Hungary

SAP Code 3500

(Hungary)


Unit/Unit/

CompanyCompanyConcord Latin

America

SAP Code 4300

Concord Latin

America

SAP Code 4300


Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Keystone Sales

Corp.

SAP Code 4100

Concord

Camera Canada

SAP Code 4200

Concord

Camera Canada

SAP Code 4200

Concord

Camera(Europe)

Limited

SAP Code 3100

Concord

Camera(Europe)

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




Starprint Corp.

SAP Code 4500

Starprint Corp.

SAP Code 4500

(US)

Concord

Camera

Hungary

SAP Code 3500

Concord

Camera

Hungary

SAP Code 3500

(Hungary)


Unit/Unit/




Concord

Keystone

Graphics

SAP Code 4400

Concord

Keystone

Graphics

SAP Code 4400

Concord Latin

America

SAP Code 4300

Concord Latin

America

SAP Code 4300


Concord

Henggang

Electronics

Factory

SAP Code 5200

Concord

Henggang

Electronics

Factory

SAP Code 5200

Concord

Shenzhen

Limited

SAP Code 5300

Concord

Shenzhen

Limited

SAP Code 5300

(PRC) (PRC)

Goldline

(Europe)

Limited

SAP Code3200

(UK and Northern

Ireland)












Consolidation

Procedures












Consolidation

Procedures

Peter Bauser

SAP Code 3600

Concord

SAP Code 5300

Concord

Camera

Australia

SAP Code 6100

(Australia)




‘Elim company’ postings will be done through SAP’s consolidation procedures and manualadjustments 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 ingroup/

subgroup

CG1000 AAA Bbb Group 1000 AAA Corporate US Yes

4200 AAA Bbb Canada

4500 Starprint Corp

3400 AAA Bbb France

3500 AAA Bbb Hungary

6300 AAA Australia

CG5100 CCHK Cons Subgroup




Cons group /

subgroup

Cons group desc Cons unit Cons unit desc Parent in

group/

subgroup

4400 AAA KeystoneGraphics

Note: The consolidation groups are not final due to design issues with the European consolidationand AAA Australia’s change to be a subsidiary of CCHK.

3.13.3. Consolidation Chart of Accountsand Financial Statement Items

A consolidation chart of accounts consists of a set of financial statement items which correspondto the G/L accounts in the consolidated book. The operating chart of accounts in FI generalledger has to be assigned to the consolidation chart of accounts to ensure integration between FIand Consolidation. Since a single operating chart of accounts will be used for the whole AAAGroup, 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/Laccounts in the operating chart of accounts must be assigned to a corresponding group of accountto ensure full integration between FI and EC (Enterprise Controlling). When consolidation isactive, users are forced to assign a group of account every time when they want to create a newG/L Thi i f d i d i i b h i COA d




• Supports data upload for planned versions of budgeting

3.13.5. Data Collection Process

Generally speaking, data collection process in Consolidation is the process for collectionof financial data reported by individual consolidation units. This function can be donewithin a single tool called Data Monitor.

Retained Earning Carried Forward

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

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

separately for each individual units

Currency Translation

Within AAA Group, each of the reporting units will have their own local ledger currencies. For example in CCHK, the ledger currency is HKD while in CCUK will bein GBP. For the company codes that are not using USD as the local currency, the parallelledger 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. Withthe help of the integration with FI all the USD amount local general ledger balances will




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/Laccounts.

3.13.6. Consolidation Process

Consolidation process refers to all possible elimination and adjustment postings done in

the consolidation to come up with the consolidated financial statements. The standardSAP system offers automatic eliminations to most of the intercompany transactions. InAAA, 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 consolidationledger. You can do all the consolidation postings in a single tool called ConsolidationMonitor. Eliminations will be done in USD currency.

Elimination of Intercompany A/R and A/P

With the help of a parameter called Trading Partner, the elimination of intercompany A/R and A/P is a feature of automatic elimination in consolidation.

In AAA Group, intercompany transactions are being posted to intercompany vendor andcustomer master record. A trading partner is a key which is defined to represent eachcompany codes within the AAA Group. The trading partners will be assigned to all

intercompany vendors and customers master records and hence all the transactionsassociated 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




Elimination of Intercompany Profit/Loss in Transferred Inventory

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 - 20A / P 4100 5100 60A / R 5100 4100 - 60A / 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 anmanual 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 themajor 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 theinvestee at the time of acquisition have to be entered manually into the system inData Monitor

• Once the data is entered, it will be stored for future postings and nofurther entry is needed.

• The elimination posting will be automatically generated by executing the

posting run in Consolidation Monitor




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 nothave 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 bevaried 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 developmenttools in both FI and CO modules.

The detailed requirements and layouts of the consolidated financial statements will bedefined 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 havebeen specifically identified to cover gaps in the functionality of SAP to meet designrequirements. 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 AllBranches

Global Vendor Aging Report Global Vendor Aging Report shown in groupcurrency

21 AllBranches

Global Customer AgingReport

Global Customer Aging Report shown in groupcurrency

TBD AllBranches

Global Credit Report Global Credit Report for common legal entitycustomers across all Reporting Units

22 AllBranches

AR Aging Report with Reasoncodes

AR Aging Report with Reason shown in local andgroup currency

TBD CCFR,CCUK,CCGmbH

VAT Report for EU andnon-EU Countries

Required tax reports to government to showVAT charged or paid for EU and non-EUcountries.

23 CCHK,CCSZ,CCWK

Remaining useful life of moulds and tools

Quarterly report to analyse remaining useful lifeof moulds & tools based on the projecteddemands for products produced by the moulds.

4 CCHK,CCSZ,CCWK

Net Billing Report Cost summary report with layout andpresentation specific Net Billing




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

a) Sales Statistics Reports has been added to the Report Inventory under the SD module b) Cash paid for interest expense and income taxes, and Product group summary on a consolidated

basis of gross sales, 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 ReportInventory

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 closing

f) Estimation of labour overhead absorption per month / quarter or any specific month-end closingfor the projected ending inventory

g) Standard cost LOH absorption calculation per production, per shipment and per ending inventory based on actual performance and comparing to the budget and last year actual.

h) Material variance analysis – by product, by customer, by product group, and include thedimensions of actual, forecast, budget.

i) Selling, G&A and freight out expenses report j) Age gross receivables, allowances and rebates, etc., returns provisions and

calculated net receivables

k) Freight in expense analysis report




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

Ref .

ReportingUnits

Customization Type

Priority Description Purpose

7 CCSZ,CCWK

Enhancement Essential

Variable fieldmove exit inspecial purpose

ledger

Enhancement (user exit) inspecial purpose ledger toupdate the country specific

G/L account numbers forCCSZ for calendar yearfinancial reporting.

8 CCFR Enhancement Essential

Validation exitfor posting in FI-GL

Enhancement (user exit) ingeneral ledger to set up avalidation in CC France toensure that financial postingat the end of June are notposted in AAA’s new fiscal

year.64 CCUS,

CCHK,CCFR,CCGmbHCCUK

Enhancement Essential

Flat file withelectronicpayment data –multiple formatsdepending oncountryrequirements

Output of Electronic file fromAuto Payment run.

10 CCUS,

CCHK,CCFR,CCGmbH

Form Essentia

l

Check Layouts For check printing to pay

vendors




Ref .

Reporting

Units

Customization Type

Priority Description Purpose

s CustomerAnalysis

allowances, returns and baddebt, and net receivables bycustomer

13 CCUS Form High 1099 TaxReports

Required tax report to USgovernment on payment toindependent contractors

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

payments9 CCHK Enhancement Low Automatic

creation of DebitNote oncevendor goodshave beenrejected

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

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 discussedand 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 20042 HK00095

0Finalization of the Group Chartof Accounts for Consolidation

Brian and Stanley are working with Larry and theControllers to close this item by the end of January2004

3 N/A Finalization of characteristicsand values for ProfitabilityAnalysis

Brian is working with the Business Warehouse teaand Business Representatives to close this item bythe first week of January 2004.

4 HK000751

Configuration of Peter Bauser Decision on whether all configuration for activecompanies should be set up for Peter Bauser. This

will be addressed again during the ImplementationPhase.

5 HK000739

Methodology for recording andanalyzing , allowances (andrebates, price protectionallowances, discounts, etc.),returns, cogs, and the relatedbalance sheet items of grossreceivables, allowances,

provisions, and inventory, atthe customer and productlevel, as applicable.

Janet, Brian and Larry are working with the SD teato review these bookings in SAP. The target date foclosure January 23rd.

Requires system customization. The project teamsuccessfully populated the G/L AR reserves line itewith the customer number. Investigations will

continue to determine the effort required to createcustomized report to meet the requirements.




Ref .

XRef./Comm.

Log

Issue Description Action Item

8 returned goods of the proposed solution to use the World Wide Coto determine the inventory value for returned good

The current proposal is to use bar-code technologythat will have the intelligence for the world wide coand serial numbering. The bar code will be appliedthe batch level to track the inventory. Value addeservice expenses will be booked separately from threturned product cost in a cost center. This is to b

confirmed.10 HK00111

5Depreciation simulation forfuture assets & collection of capitalized costs vs. expensesin a project

Stanley and Janet to communicate and discussresponse with Larry and Rick the advantages of using Internal Orders vs. Investment Managementmeet these requirements. The target date fordiscussion/communication is Wed. Dec. 3rd.

Two meetings were held to discuss above. Accentis seeking an IM expert to demonstrate the detailefunctionality of IM to meet these requirements.

11 HK001123 Consolidated FI Statement forall of Europe Stanley and Janet to communicate and discussresponse with Larry and Rick for closure by January28th.

Janet/Stanley are investigating the details of anytechnical limitations on creating the requested rep

12 HK000638

Mapping of freight activitycodes to accounting

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

13 HK00108

4

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 seup appropriately for Latin America.14 HK00075 Finalize whether AAA Bbb Aust. Closed: E-mail from Harlan Press confirmed that C




8. Annexes

8.1. Annex 1: Cost Center Hierarchical Structure

Legend

Functional Sub Group Number Group

Administration Admin & Human Resources 99Administration 99

Executives 91

Finance 96

Human Resources 99

Information Technology 95

Legal 94

Public Company 93

Engineering Design Engineering 10US Design 11

US Production Design 12

Project Management 20

Quality Engineering 40

Production Engineering 30

Production Production Line 4X

Supporting Service 49

Sales Marketing 20

Sales 10Sales Personnel 00

S l Ch i B d d W h 32




CCC Administration Admin & 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-79600Information 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-61101Software 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-33000CCCA Administration Admin & Human Resources 142-79900

Finance 142 79600




8.2. Finance Requirements

42091003.doc

Printed on: 10/16/2010 9:02 a10/p10 of 147


Accounts Payable



Ref # Requirement Must Have

Niceto

Have

NotImpor tant

RequirementComments

Requirements Addressedin 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 scope

AP-4 Share the vendor file with Purchasing and Inventory. X Not used today Not in Phase 1 scope

AP-5 Allow for the identification of tax exempt items. X Yes

AP-6 System automatically assigns a vendor number. X Yes

AP-7 Vendor lookup by name, address or vendor number. X Yes

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

AP-9 Ability to view purchase orders on-line. X Yes

AP-10 Ability to view open and paid items on-line. X Yes

AP-11 Ability to view current and YTD activity on-line by account. X Yes

AP-12

Provide inter-company, inter-divisional processing and

transferring. X YesAP-13 Support user defined posting cycles. X Yes

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

AP-15Produce a discrepancy report to identify unmatchedreceiving 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 informationas 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 periodbefore the current period has been closed. X Yes

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

AP-21Ability to combine a user-defined batch of invoices into asingle check for a vendor. X Yes

Yes** SAPScript form needs to

42091003.doc

Printed on: 10/16/2010 9:02 a10/p10 of 147
