telecom solution scope (3)

SAP ECC 6.00

November 2007

English

SAP Best Practices for Telecommunications

SAP AGDietmar-Hopp-Allee 1669190 WalldorfGermany

Specification Document

SAP Best Practices Telecommunications US V1.600: Solution Scope

Copyright

© Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.


Icons

Icon Meaning

Caution

Example

Note or Tip

Recommendation

Syntax

Typographic Conventions

Type Style Description

Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.

Cross-references to other documentation.

Example text Emphasized words or phrases in body text, titles of graphics and tables.

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, source code, names of variables and parameters as well as names of installation, upgrade and database tools.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or the ENTER key.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.


ContentsSAP Best Practices Telecommunications : Solution Scope 7

1 Purpose 7

2 Functional Scope – Supported Business Processes or Scenarios 7

2.1 Order to Cash 7

2.1.1 Sales: Order Process Business-to-Consumer (U61) 8

2.1.2 Sale of Mobile Device with Return (U62) 9

2.1.3 Sale of GSM Base Station (U63) 9

2.1.4 Optional: Sales Order Processing B2C for Telecommunications in CRM E-Commerce (U65) 9

2.1.5 Credit Management (V4A/V4L) 10

2.1.6 Free of Charge Delivery (V4E) 11

2.1.7 Create Credit Memo (V4C) 11

2.1.8 Create Debit Memo (V4D) 11

2.2 Procure to Pay 11

2.2.1 Quotation for Procurement (U64) 12

2.2.2 Quality Management in Procurement of Stock (U64) 12

2.2.3 Return to Vendor without QM Inspection (V3I) 13

2.2.4 Inventory Disposition from Return (V3C/V3D) 13

2.2.5 Consumable Purchasing (V3H) 13

2.3 Manufacturing 14

2.3.1 Logistic Planning (V5A) 14

2.3.2 Make to Stock - Discrete (V5B) 14

2.4 Customer Financial Management (RM-CA) 15

2.4.1 Payment Processing (U60) 15

2.4.1.1 Cash Desk Payments 15

2.4.1.2 Batch Payments 16

2.4.1.3 Batch Correction 16

2.4.1.4 Direct Debit Transactions 16

2.4.2 Return Checks (U60) 16

2.4.3 Security Deposit Management (U60) 17

2.4.4 Refunds (U60) 17

2.4.5 Dunning (U60) 17

2.4.6 External Collection Agencies (U60) 18

2.4.7 Calculating Customer Creditworthiness (U60) 19


2.4.8 Miscellaneous Document Posting (U60) 19

2.4.9 Write-offs (U60) 20

2.4.10 Reconciliation and Closing (U60) 20

2.5 Financial 21

2.5.1 Financial Accounting AR - Customer Down Payment (V1E) 21

2.5.2 Financial Accounting - AR - Incoming Payment /Lock Box (V1D) 21

2.5.3 Financial Accounting - Customer Statement: Dunning (V1F) 21

2.5.4 Financial Accounting - Vendor down Payment (V1B) 22

2.5.5 Financial Accounting - AP -Outgoing Payment (V1C) 22

2.5.6 Financial Accounting - AP -Manual Invoice/Credit Memo (V1A) 22

2.5.7 Asset acquisition through direct capitalization (V2A) 22

2.5.8 Asset transactions – Retirements (with / without revenue) (V2B) 23

2.5.9 Asset acquisition for constructed assets (V2C) 23

2.5.10 Financial Accounting - GL - Period End (plant) (V1I) 23

2.5.11 Financial Accounting - GL - Period End (Central) (V1J) 23

2.5.12 Financial Accounting - GL - Year End (V1K) 25

2.5.13 Electronic Bank Statement (V1G) 26

2.5.14 Financial Accounting – Internal Projects (V1H) 26

2.6 Controlling 26

2.6.1 AOP - Sales Quantity Budget and Transfer to SOP (V6A) 26

2.6.2 AOP - SOP through Long-Term Planning Transfer to LIS/PIS/Capacity (V6B) 27

2.6.3 AOP - Purchased Material Price Planning (V6C) 27

2.6.4 AOP - General Cost Center Planning (V6D) 27

2.6.5 AOP- Manufacturing Cost Center Planning (V6E) 28

2.6.6 AOP - Research and Development Order and Cost Center Planning (V6F) 28

2.6.7 Quarterly Plan – Sales Quantity Forecast (V6I) 28

2.6.8 AOP- Standard Cost Calculation (V6G) 28

2.6.9 AOP- Revenue Cost of Sales Transfer (V6H) 29

3 Functional Scope 29

3.1 Building Block B32: Best Practices ECC Installation 30

3.2 Building Block J02: Organizational Structure 30

3.3 Building Block V03: Financial Accounting 33

3.4 Building Block V08: Basic Controlling 35

3.5 Building Block V05: Materials Management 35

3.6 Building Block V04: Sales & Distribution 36

3.7 Building Block V06: Production Planning and Control 37


3.8 Building Block J10: Asset Accounting 37

3.9 Building Block V18: Product Cost Planning 37

3.10 Building Block V17: Profitability Analysis 38

3.11 Building Block V64: PP - MTS Basic Data 39

3.12 Building Block V66: PP MTO Basic Data 39

3.13 Building Block V49: PP - ETO Basic Data 40

3.14 Building Block V4E: Free of Charge Delivery 40

3.15 Building Block V4F: SD Configuration; Returns and Complaints 40

3.16 Building Block V4I: SD Config ETO Scenario 41

3.17 Building Block V4J: SD Config MTO Scenario 41

3.18 Building Block U50: Telecommunications Delta Configuration 41

3.19 Building Block U51: RM-CA Customizing 41

3.20 Building Block U53: Configuration for VC Scenario 42

3.21 Building Block U59: Master Data 42

3.22 Building Block U54: Quality Management in Procurement 44


SAP Best Practices Telecommunications: Solution Scope

1 PurposeThis solution scope provides an overview of the processes and functions covered by SAP Best Telecommunications. It enables a quick start implementation by pre-configuring some basic business processes used in the telecommunication industry. At a general level, we are covering Order to Cash, Customer Receivables Management, Financials and Procure to Pay.

Under Functional Scope – Supported Business Processes or Scenarios, you will find a scenario-based view of the functions. Under Functional Scope – Functions, you will find a view arranged according to groups of functions.

The solution scope does not provide technical explanations of how to use the functions. For further information on this topic, see the business process procedure documents.

2 Functional Scope – Supported Business Processes or Scenarios

2.1 Order to Cash

PurposeThe SAP Best Practices for Telecommunications equips your sales organization with tools to maximize productivity for meeting customer demands. The Order to Cash scenario encompasses sales product configuration, sales-order processing, delivery, billing, and payment. The scenario enables fast and efficient execution of customer sales orders. Distribution executes delivery to efficiently support and control the actual fulfillment of any device or any other delivery related items.

The scenarios encompass several different types of typical sales processes for Telecommunications including the sale of a bundled product offering of a device and service. The processes also include credit management limit setting and checks, creation of credit or debit memos, and the delivery of goods.

Scenarios include:

Sales of configured package with variant pricing

Sale with customer return

Sale of a project assembled order (GTS Base Station)

Customer down payment

Credit management and credit limit setting

Credit and Debit Memos

CRM – Internet Sales: Order Process Business-to-Consumer (Optional * Requires Installation of CRM Best Practices)


Business Process Procedures

2.1.1 Sales: Order Process Business-to-Consumer (U61)This process involves the sale of a mobile package. Variant Configuration is used to select a phone, service and charge an activation fee based upon the customer’s order. When entering a configurable package via a sales order, the system automatically requests information needed to fulfill the order such as:

Market

Distribution Channel

Order Type

Rate Plan Category

Rate Plans

Device

Product Selection

The above characteristics are also linked to additional lower level characteristics that control product offerings. For example; if you select a rate plan category of “pooling plan” (shared minutes plan), the system will propose you select 2 devices and propose valid plans for the category.

Selection Validation

The model is also capable of checking the validity of various product combinations and whether they are allowed. For example Market “SEA” does not offer a “NW1500” plan so the system does not accept the combination as entered.

Cross Selling

Once a device is selected, additional applicable services and accessories can be shown and selected. The sales rep would have to select the options and the items could be added to the existing sales order.

Variant Pricing/Discounting

Based on selected product combinations, the model proposes appropriate fees (activation) and/or discounts.

It is a customary practice to offer phone discounts to customers who purchase a new plan. When a device is purchased in conjunction with a rate plan a discount is automatically triggered and is reflected in the sales order. Otherwise if only a phone is purchased without a plan, no discount is applied.


2.1.2 Sale of Mobile Device with Return (U62)This scenario describes sales order returns processing. After the placement and shipment of a customer sales order, the process starts with a customer request for authorization to return materials to the plant for credit, referred to as RMA-(Return Material Authorization). The request is approved, and subsequently a Return Sales Order is created with reference to the original invoice for the goods. An RMA document is printed, and forwarded to the customer to be attached to the incoming goods. The goods are shipped back, a return delivery is created with reference to the RMA, and the material is received into return stock. The return stock location is set to be non-MRP relevant. The goods are inspected, resulting in a disposition to either return them to stock, or scrap. A credit memo is created from the billing run, and posted to the customers account.

2.1.3 Sale of GSM Base Station (U63)This scenario describes the process sequence for an “Assemble/Engineer-to-Order” sales process with a customer. There are telecommunications businesses that sell, build and assemble complex cellular telephone network equipment such as base transceivers stations and GSM base stations. This business process encompasses all steps from creating an order to the clearing of a customer account after payment is received.

The process starts with the creation of a customer's standard sales order and continues with the automatic creation of a project and network. The equipment build requires precise planning of the many activities involved. A clear project structure is the basis for successful project planning, monitoring and control. This scenario describes an agreement with a customer for a project that requires a down payment and billing based on performance of defined milestones.

A project structure is created which triggers the procurement of materials, manufacturing requirements, invoicing plans, and determines the confirmation date to the customer. The project is structured by work breakdown structures (WBS) and network activities. Once the project has been released, results analysis can be performed at each milestone to show planned costs, revenues, and accruals for periodic reserves. Both the project and associated sales orders result in financial and management account postings either through execution or billing and/or period end.

Finally steps such the posting of invoices, preparation and printing of customer statements, and recording and clearing of incoming payments are done.

2.1.4 Optional: Sales Order Processing B2C for Telecommunications in CRM E-Commerce (U65)

This scenario involves a business-to-consumer e-selling scenario. In order to enable this optional scenario, you must also install the Best Practices Cross-Industry Packages for Customer Relationship Management V2.5 in conjunction with the Telecommunications V1.600 package.

After having installed the master data building block U59 in your ERP system, continue with the CRM installation as documented in the BPIA during activation.


The following functions are provided to support the Internet Sales: Order Process Business-to-Consumer scenario contained in the Best Practices Cross-Industry Packages for Customer Relationship Management V2.5:

Accessing the Web shop

Viewing Current Product Recommendations (Bestseller List)

Logon and Registration

Creating the Customer Profile

Viewing Personalized Product Recommendations

Searching for Products

Adding Products to the Shopping Basket

Maintaining the Shopping Basket

Availability Check in the R/3 system

Ordering Products

Checking the Order Status

Processing Orders in the CRM and R/3 System

2.1.5 Credit Management (V4A/V4L) A credit limit check can be carried out when sales documents are created or changed. The check is carried out within one credit control area. When changing a document, the check is repeated, if changes regarding quantity or value are made. A credit control area consists of one or more company codes. A sales document belongs to one credit control area depending on the allocation of the sales organization to a company code. The SAP System checks the credit limit that was granted to the customer in this credit control area. The credit control areas and the credit limit of a customer are defined in financial accounting and entered in the customer master record. During the check, the SAP System totals the receivables, the open items, and the net value of the sales order for every item of a sales document. The open items take into account obligations bound by contract which are not recorded for accounting purposes but which involve expenses through diverse business transactions. The total is compared with the credit limit. If the limit is exceeded, the system responds in the way defined by you in the configuration menu.

We are using ‘simple’ credit limit check in this solution. During the simple credit limit check, you can only configure one system reaction ('A' warning, 'B' error, 'C' delivery block) when the credit limit is exceeded, we have chosen to use option ‘C’ (delivery block). (Most items are not delivery relevant – probably should use B) – need to check

The system provides a transaction to list all of the sales documents that have been blocked for delivery, with information about what has caused the block. The Customer’s current credit situation is manually reviewed by credit department, and when the sales order is approved, the delivery block is removed from the sales order. You go directly from the list to an individual sales document by placing the cursor on the relevant document and choosing Edit sales doc.


2.1.6 Free of Charge Delivery (V4E) This scenario describes the process of providing goods to a customer at no cost. A unique sales order type is created that is non-billing relevant, but is expensed to a specified cost center that is determined from the order reason (free of charge sample) assigned to the sales order. The order is confirmed based on the availability of goods. A delivery is then created; the goods are subsequently picked, confirmed, and delivered to the customer.

2.1.7 Create Credit Memo (V4C)The Credit Memo process is used for applying a credit to a customer account once a determination has been made that a customer has been overcharged as a result of a pricing or sales tax rate error. A Credit Memo Request is then created with the amount to be credited, and placed on a billing block for review. It must then be released to become billing relevant, and appear on the billing due list. Periodic billing process creates a credit memo to be sent to the customer, and posts an accounting document.

2.1.8 Create Debit Memo (V4D)The Debit Memo process is used for applying a debit to a customer account once a determination has been made that a customer has been undercharged as a result of a pricing or sales tax rate error. A Debit Memo Request is then created with the amount to be Debited, and placed on a billing block for review. It must then be released to become billing relevant, and appear on the billing due list. Periodic billing process creates a Debit memo to be sent to the customer, and posts an accounting document.

2.2 Procure to Pay

PurposeThe SAP Best Practices for Telecommunications delivers configuration that supports the entire Procure to Pay scenario, enabling the efficient handling and execution of purchase orders. The scenario covers the request for quotation, comparison and selection of vendors. Purchases can then be sourced manually or can be automatically assigned to suppliers using info records. The goods receipt function updates the general ledger and inventory (for stock items). Received materials can be inspected and results recorded in order to track vendor performance and ensure quality. In subsequent processing, invoices are matched against the agreed purchase price and quantities delivered within customer specified tolerances.

The procurement of consumable materials (goods or services) such as office supplies, are entered with no material number but rather a short text description as the main identifiable characteristic. The purchase order is subject to approval based on predefined parameters before being issued to a vendor. For consumable goods, the inventory is received into a location based on parameters defined in the purchase order material line item. The value of the goods is expensed to a cost center.

Scenarios include:

Creating a request for quotation, compare and select vendor

Quality inspection of material purchased

Return to vendor deliveries

Inventory disposition

Procurement of material into stock


Procurement of consumable materials

2.2.1 Quotation for Procurement (U64)The request for quotation (RFQ) process starts with a request for material(s) from a vendor(s). The RFQ process includes offer comparisons to select the best source. The buyer will evaluate the responses from vendors to determine the best source of supply. The accepted quotation will be processed into a Purchase Order and a reject letter is sent to the vendor(s) whose quotations were rejected.

Material specific information including vendor pricing and lead-time from the quotation are captured within SAP master data records.

2.2.2 Quality Management in Procurement of Stock (U64)The purchasing process may start with a Request for Quotation by which a purchasing organization employee requests a quotation for the supply of material(s) from a vendor(s). The RFQ process includes offer comparisons to select the best source. The buyer will evaluate the responses from vendor(s) and determine the best source of supply. The agreed material cost will be captured on the material master and form part of inventory valuation based upon a released standard cost.

Material specific information including vendor pricing and lead-time from the quotation are captured within SAP master data records namely info records and linked to transactional requisitions and purchase orders via an SAP look up called a source lists. Info Records and Source Lists can have one or more vendors associated with the material; however, one vendor is designated as the primary source for the material.

A Purchase Requisition is either generated via the Material Requirements Planning process or manually from a requestor. A Buyer will validate the accuracy of the Purchase Requisition and convert the Purchase Requisition into a Purchase Order. The purchase order is subject to approval based on a predefined dollar amount prior to being issued to a vendor.

Goods are shipped from the vendor and received to the purchase order referenced on the document from the vendor. Inventory is received into a location based on fixed parameters proposed from the material master that can be changed at time of transactional data capture that is Purchase Order creation or goods receipt.

On goods receipt, an inspection lot is generated according to the defined inspection plan. A usage decision is then made as to whether to accept or reject the material, based on the inspection result. Subsequent processes such as quality notification and vendor evaluation can follow.

The inspection scenario focuses on the following activities:

Inspection recording according to various criteria

Usage decision after inspection

Vendor evaluation process

Quality notification creation and completion

Goods return to vendor and return delivery creation

The invoice is received from the vendor. Invoices are entered with reference to a purchase order and item, providing a three way match, purchase order value, goods receipt value and invoice value. If there are any variances between invoice and purchase order value, the invoice will be blocked and forwarded to the buyer for approval. Checks to vendors are generated based on the net term condition reflected on the invoice, defaulted from the vendor master. Variances due to deviations


from standard price are collected in the purchasing cost center and allocated to Product Line level based on a predefined percentage as determined by the business.

2.2.3 Return to Vendor without QM Inspection (V3I)The return to vendor process begins with a requirement to return an item to a vendor. The initial activity is to request a Returns Material Authorization (RMA) from the vendor. This is a manual step and the RMA number will be entered into a text field in the return PO. The Buyer will then create a Return PO in the system. The return PO is similar to a standard PO except for the return flag which sets up the return delivery to enable shipment of the item(s) back to the vendor.

The Return PO confirmation goes to the Vendor and the Return Delivery is sent to the Shipping department where the item(s) are picked and shipped back along with a Delivery Note. When the Shipping department creates the delivery the item(s) are relieved from inventory. A credit memo is generated which relieves the liability to the vendor.

2.2.4 Inventory Disposition from Return (V3C/V3D)Inventory disposition processes differ based upon whether the material is valuated or non-valuated.

Valuated disposition covers two primary goods movements: goods issue to scrap and to a cost center. Goods are issued to scrap when the material being manufactured is directly identifiable with a particular product line. The value of the scrap is reflected directly to a product line in the profitability analysis income statement.

Goods are issued to a cost center when the material is used for non-manufacturing purposes internally in the organization.

Non-Valuated Disposition covers two primary goods movements: goods movements between unrestricted stock and blocked stock and miscellaneous inventory movements within the plant.

These movements do not generate any accounting documents as the goods movements have no financial impact.

2.2.5 Consumable Purchasing (V3H) The consumable – office supply for example - items (goods or services) are entered with no material number but rather a short text description as the main identifiable characteristic. The purchase order is subject to approval based on predefined parameters prior to being issued to a vendor.

For consumable goods, the inventory is received into a location based on parameters defined in the purchase order material line item. The value of the goods is expensed to a cost center.

When the invoices is received from the vendor, they are entered with reference to a purchase order and item, providing a three way match, purchase order value, goods receipt value and invoice value. If there are any variances between invoice and purchase order value, the invoice will be blocked and forwarded to the Buyer for approval. Checks to vendors are generated based on the net term condition reflected on the invoice, defaulted from the vendor master. Variances due to deviations from standard price are collected in the purchasing cost center and allocated to Product Line level based on a predefined percentage.

Procurement for a consumable service follows the same general flow. However, as the consumable service has no goods receipt element within the system, it is paid based on the invoice receipt.


2.3 Manufacturing

PurposeThe SAP Best Practices for Telecommunications delivers configuration that supports the manufacturing functions needed in production scenarios such as make-to-order, make-to-stock, and engineer to order. It supports generating production schedules that take into account real-time material and resource constraints. Manufacturing processes are integrated with the stock, sales, purchasing and accounting solutions to enable a rapid, flexible response to engineering changes and customer requirements.

2.3.1 Logistic Planning (V5A)This scenario covers the transfer of aggregated Production planning based on Sales Quantity Planning to Long Term Planning (LTP). In LTP a planning scenario is created to enable simulation of material requirements which can be based on the production plan. Planned requirements can be reviewed and adjusted as needed. Once the simulated requirements are accepted, the demand (independent requirements) is then transferred to active demand management.

2.3.2 Make to Stock - Discrete (V5B)

The scenario, Production Planning and Discrete Manufacturing, describes a business process which is typical for companies with lot size oriented production. The production scenarios consist of both goods movements (goods issues and receipts) and confirmation of completion of the production order. Furthermore, the scenario is supported by the main cost object controlling functions required, such as preliminary costing and period-end closing.

The typical planning process starts with sales quantity planning. The previous period’s actual sales figures can be used as a basis for future planning. To ensure that production stays in line with sales, you may create the production plan synchronously to sales.

In Sales and Operations Planning, long-term planning takes place with a rolling forecast of at least one year. The planning data is transferred from Sales and Operations Planning to Demand Management. Demand Management generates independent requirements, which are used in the subsequent Material Requirements Planning (MRP) run. In material requirements planning, the bill of materials (BOM) for the top-level material demand gets exploded and production is planned right down to procured component level.

MRP results in planned orders being generated for the material to be produced. If insufficient warehouse stock is available, purchase requisitions are created for the raw materials required.

When the order is created, target costs are calculated for the order lot size (preliminary costing). During the production process, costs incurred are updated on the order, which enables you to keep track of and compare target costs and actual costs at any time.

Period-end-closing activities are applied to the order. This includes Work In Progress calculation and variance calculation. After this, Work in Progress is settled to financial accounting and production variances are settled to management and financial accounting.


2.4 Customer Financial Management (RM-CA)

PurposeThe SAP Best Practices for Telecommunications delivers configuration that supports the RM-CA payment processing. Frequently, actual minutes and usage plan information is provided via an external system. This scenario describes the Contract Accounts Receivable and Payable (RM-CA) functions after this information is received from an external system. It contains financial transactions and processes inherent to a telecommunications company. Revenue Management -Contract Accounting, a sub-ledger accounting system, interfaces with Financial Accounting (FI) to properly record the transactions occurring at the customer (Business partner) level.

FI-CA supports the following financial processes:

Payment Processing

Processing of Returns

Security Deposit Management

Refunds

Dunning

Calculation of Customer Credit Worthiness

Miscellaneous Document Posting

Reconciliation and Closing

Write-off

Reconciliation and Closing

2.4.1 Payment Processing (U60)The payment function provides the ability to process walk-in payments, lock-box payments, batches of payments and direct debit transfers. The payment methods supported include cash, check, money order, and direct debit payments. Direct debit payments represent the contract accounts that allow the utility to directly draft the amount of the utility invoice from a customer selected bank account.

2.4.1.1 Cash Desk PaymentsThe cash desk process provided by the system allows customers to make payments using cash, check, or money order. The payments are applied to the customers account (Contract account) in real time and may be automatically or manually allocated to the customer’s outstanding items. The system prompts the cashier to print a receipt for the payment amount received. The system also displays the amount of change owed to the customer in the case of a cash payment.

The cash desk process requires a reconciliation key be established for balancing receipts accepted each day. This reconciliation key may be shared by multiple cashiers to reduce the number of keys created each day. In addition to the reconciliation key, each cashier must have at least one lot which is uniquely assigned to each respective cashier. Any differences discovered during the balancing process will require debiting or crediting the over/short account directly.


2.4.1.2 Batch PaymentsThe batch payment process is used to process payments received via mail or other processes delivering multiple payments. The process allows the user to key multiple accounts and amounts under one lot (reconciliation key) and post multiple payments in a single batch. The system captures the number of items entered and the total amount to be credited. Posting is prevented if the totals do not match. Any number of batches can be created and each batch can contain as many transactions as is convenient.

2.4.1.3 Batch CorrectionThe batch process does not validate individual contract account numbers as the transactions are entered. This means it is possible for the user to enter invalid contract accounts. Accounts are validated when the batch is posted. If an error is detected, the batch posting screen display as a message indicating that further processing is required to complete the batch. The system moves the effected amount to the clarification process for correction. This process can be accessed directly from the batch posting screen or it can be accessed through a separate transaction path.

2.4.1.4 Direct Debit TransactionsThis feature allows companies to offer customers the convenience of having their bank accounts automatically drafted for the amount of the monthly telecom invoice. This process involves the generation of a file for delivery to the selected house bank of customers who have selected this option. The house bank in turn contacts the customer’s bank to request the invoiced amount to be transferred to the utilities account.

The system has several screens where the customer information is captured in order to produce the standard files required for this transaction. The screens may require some customization to meet the requirements of the selected house bank. The file that is created as a part of the transaction FPY1 and the transaction is scheduled to run three days prior to the past due date of the account.

Customers enroll in the program by providing the utility with their account number and ABA number. In addition, the contract account to be drafted must be cross-referenced to the business partner and have a debit incoming payment method.

2.4.2 Return Checks (U60)The returned check process is similar to the payment lot concept, each house bank that returns items will require its own returned lot. The returned lot is linked to the GL clearing account with a specific bank. Once a returned lot is opened, the individual returned check entries are entered for processing. Based on the house bank and company code, the return reason is proposed, but can be overridden. The return reason contains the applicable charges that may be passed on to the contract partner and update the creditworthiness of the business partner

The returns transaction allows the processing of returned items which have been deposited as part of the incoming payment process. The return function will:

Apply returned payments to the contract account Pass returned fund charges to the contract account Generate returned check notifications to the contract account automatically

Assumptions:

1. The fee charged by the utility for a returned item does not include an individual charge from the bank to the customer i.e. only the service charge from the utility is added to the business partner’s account.


2. All returned items will be handled manually with the bank returning all paper documents to the utility.

2.4.3 Security Deposit Management (U60)Security Deposit Management refers to the processes involved with collecting and tracking security deposits required from contract partners who are a poor credit risk. These processes allow the collecting of security deposits from those customers who represent a risk to the company, and refund the deposit when it is determined that it is no longer required. Upon review of a contract partner’s credit rating, the customer service representative has the option of requesting a security deposit through the front office process. The same security deposit request functionality exists to request a security deposit from a contract partner with an existing contract. In both cases, the request of the security deposit is a manual process.

2.4.4 Refunds (U60)Refund processing exists as outgoing payment to the contract partner. The process involves the identification of credit items which may be candidates for refund to the customer. These amounts are analyzed and coded if the decision is made to make a refund. Credit amounts, which are not to be refunded, are left unchanged to be applied against future invoiced amounts.

The refund process allows the telecom company to remit amounts to customers which arise from;

Refund overpayments

Refund credit from application of deposit

Refund security deposits at the request of the business partner

The refund process enables refund checks to be created and mailed everyday. Employees will be able to initiate the refund process by identifying credit items to process. The system will produce a file of business/contract account items which will be used as an input file for the existing accounts payable system. The check will be produced from the A/P system on a schedule dictated by the accounts payable process.

Identify credit items in the system.

Analyze the identified credits for possible refund.

Code the credit items to be refunded by entering an outgoing payment method for the item.

Initiate the Payment run transaction

2.4.5 Dunning (U60)The dunning process tracks past due open items and initiates collection activities to facilitate the payment of these items. The system uses the dunning program to monitor payment behavior for customers and start the required activities. These activities include:

Create dunning notices

Create disconnection notice

Charge Late fees

Deactivate installment plan

Release items for placement with collection agency


Identify candidates for write-off as uncollectible

The dunning proposal examines the customer’s contract account for open items and applies the rules established by the customer’s dunning procedure to these items. The output of this process is a proposal (a list of accounts with the proposed actions) which identifies the actions which will be enacted by the activity run. This proposal allows the user to review the list of business partners who should not be included in the run and to reverse them out of the proposal.

Each dunning procedure contains levels of activities to be performed against delinquent contracts. Each level and activity contains a credit value multiplied against an internal credit worthiness table to arrive at an overall credit score. The credit scores accumulate month by month and reside at the contract partner record level for internal review and system monitoring. The dunning procedure plus dunning level provide the basis for the appropriate activity to be performed.

Execution of the dunning process evaluates each customer account and, based on account attributes, will generate charges against the account, notices, and may or may not generate a proposal for disconnection. The dunning proposal becomes history when the activities are run. Running the proposed dunning activities affects the contract/contract account/contract partner objects.

2.4.6 External Collection Agencies (U60)If a customer does not pay his receivables, and all measures have been taken to collect the receivables, many telecom companies use collection agencies to prevent losing the receivable. The SAP system allows these managed accounts to be submitted to a collection agency and the exchange of information with those collection agencies.

RM-CA allows items to be handed over to an external collection agency if dunning is unsuccessful, and supports subsequent processes. This involves the following functions:

Release items for delivery to a collection agency. Automatic release can take place from dunning or charge-off processes. You can also release items manually.

Determine additional items to be handed over (for example, hand over all items for a contract, contract account, or business partner).

Flexible determination of the responsible collection agency

Recall items that have been handed over: Recall can take place automatically because of an incoming payment directly from the customer, or it can take place because of items being transferred to another collection agency. Manual recall can take place if items are handed over incorrectly.

Automatic entry of incoming payments from the collection agency: This includes assigning the associated receivables and automatic entry of interest and charges including all relevant postings. If postings are entirely or partially unrecoverable, the corresponding amounts can be written off automatically.

Reports of collection agency payments including interest and charges Since the system lists all processing stages of an item, you have the option of creating detailed evaluations at any stage (so that you can check the efficiency of your collection agency).

2.4.7 Calculating Customer Creditworthiness (U60)

The creditworthiness of a business partner provides information on the business partner’s payment history and influences the selection of activities for dunning and/or returns and also the calculation of charges.


The creditworthiness is updated in the system automatically by various different business transactions returns, dunning notices, and write-offs. Creditworthiness can also be updated manually.

Creditworthiness is defined at the business partner level and changes in the creditworthiness rating will be determined in dunning, returns and write-off activity. The business partner’s payment patterns are reflected in the creditworthiness value. These values are determined by the telecom using individual criteria of their own choosing. The range selected for the system is:

0 – 10 Excellent

11 – 50 Moderate

51 and above poor

The ISU Processes that can automatically update creditworthiness:

1. Dunning

Dunning will be coded in configuration to increase a business partner’s creditworthiness value as a result of dunning activity. Credit worthiness will also be used by dunning to exclude business partners from certain dunning activities. The dunning activity run reads the current creditworthiness of a business partner and selects the dunning activity and dunning charge where the creditworthiness determined is greater or the same as the creditworthiness value defined.

2. Returns

Return activities will be coded in configuration to increase a business partner’s creditworthiness value as a result of return transaction.

3. Write-offs

Write-offs will also effect on a customer's creditworthiness. A business partner’s creditworthiness value will be increased by the value associated with the write-off transaction. This derived value becomes part of the customer’s current calculated creditworthiness value.

4. Manual

Credit worthiness can also be entered manually into the system. The manual creditworthiness is added to the value of the automatically determined creditworthiness, and thus forms the overall creditworthiness of a customer.

2.4.8 Miscellaneous Document Posting (U60)A document is generated for each posting. Postings are usually generated automatically by the corresponding business processes in RM-CA or by invoicing. Documents can also be posted manually. The account determination function can be used to determine G/L accounts automatically and to propose due dates using payment conditions in the contract account. Utilities generally have special miscellaneous transactions, which may be unique to the company. Examples may include a goodwill credit or a special charge for meter tampering. The SAP system allows utilities a simple method for developing these transactions:

Post Miscellaneous Charges

Post Miscellaneous Credits

2.4.9 Write-offs (U60)


It is necessary to write-off items if receivables are irrecoverable or payables cannot be paid because it is not possible to determine the payment recipient. FI-CA supports automation of this process. You can record individual write-off rules (such as amount limits) in the system. RM-CA can also be used to write-off individual items in dialog processing or to write-off partial amounts. The system automatically makes the necessary posting, including tax correction postings required during write-off. Write-off also includes the following functions:

• Items to be written off can also be transferred to a collection agency.

• Items that the collection agency reports to be irrecoverable are written off automatically.

2.4.10 Reconciliation and Closing (U60)

The Contract Accounts Receivable and Payable is a sub-ledger system designed to process a large volume of individual transactions for a large number of customers. The system uses reconciliation keys as a vehicle for transferring summarized transaction data from the sub-ledger to the general ledger. The delivered process must allow

Creation of Reconciliation keys.

Closing of reconciliation keys.

Transfer of financial data from the sub-ledger to the general ledger.

Reporting of transferred amounts and account balances

Assumptions:

The utility will close, post, and reconcile transactions to the general ledger on a daily basis.

This scenario enables the general ledger to be updated periodically with postings from Contract Accounts Receivable and Payable.

The transaction figures are not automatically updated in the general ledger when postings are made in Contract Accounts Receivable and Payable. Instead, the data is summarized and transferred periodically to the general ledger for reasons of system performance and to limit the volume of documents in the general ledger.

The Contract Accounts Receivable and Payable documents are grouped automatically and posting totals are recorded for each group which are later transferred to the general ledger. Each group contains a unique key, the reconciliation key. A reconciliation key can be closed so that no more postings can be made for that particular key. The posting totals recorded can be transferred to the general ledger for each closed reconciliation key.


2.5 Financial

2.5.1 Financial Accounting AR - Customer Down Payment (V1E)Often in business, especially in a make to order environment, customers may be required to pay some amount upfront before delivery of goods. This process is used to create requests for down payment, record of the receipt of the down payment, create final invoice after deduction of down payment received and receive of the final amount due on the invoice.

The process makes use of the billing plan functionality in the Sales and Distribution module of SAP. The integrated process allows for a proper document flow to be maintained between the sales and financial transactions.

2.5.2 Financial Accounting - AR - Incoming Payment /Lock Box (V1D)

Customer payments are recorded into the system to represent the collection of money and the application of this money against Customer liabilities to the company. This can be performed two ways, either on an individual payment-by-payment basis, or collectively, in what is commonly called lockbox processing.

Individual payment-by-payment processing will have the User entering one transaction per payment. Lockbox processing is a two-step process: step one has User using one transaction to post multiple payments based on data file from the bank, and step two is a transaction to correct any un-applied payment data from step one.

Lockbox is a function, performed by a bank, which allows the Customer to send payments directly to a bank via ‘lockbox’ (a specific mail address set-up for the company at the bank). These payments are collected by the bank and applied to the company’s bank account, with data from the payments (like check routing number, Customer bank account number, check number, payment amount and invoices being paid) being made available to the company in a file format to allow for collective processing. The lockbox data is either sent daily to the company, or located at the bank, and retrieved by the company daily.

The lockbox process is designed with the BAI2 record format. This file format is designed that each document number is on a different record type 4 with its corresponding payment and deduction amounts. The process uses a 'lockbox clearing' account (125310) to post all payments directly to the bank G/L account. This allows the bank account to have a correct balance while the ‘clearing’ account has non-zero balance until all payments are applied to Customers or written off.

2.5.3 Financial Accounting - Customer Statement: Dunning (V1F)

This process is used to produce a batch of Customer Statements based on data found in the Customer Master identifying the statement interval, like weekly or monthly. The Customer statement is used to provide a list of clearing activity against the Customer’s account and an open items list of invoices to be paid. The clearing activity covers a period of time, usually since the last Customer Statement, and also provides open item aging section.


2.5.4 Financial Accounting - Vendor down Payment (V1B) The purpose of down payments depends to a vendor is that they require partial payment upfront before they deliver goods or services. This is a purely statistical document that you require to enable the system to post the down payments to your vendor automatically using the payment program. Once the down payment request has been created, you can enable the system to post the down payments in the next automatic payment run. If the vendor invoice is later posted manually, the invoice is cleared with the down payment that has already been posted so that only the difference remains to be paid to the vendor.

2.5.5 Financial Accounting - AP -Outgoing Payment (V1C)The process involves reviewing blocked vendor invoices and unblocking them if necessary. Vendor invoices and down payments are paid periodically using checks. This is achieved by using the payment program function in SAP. The program selects open invoices and down payment requests to be for vendors based on the following criteria:

Payment method entered in vendor master records

Payment terms on the invoices and down payment requests

Selection parameters entered in the payment program

The open items selected are presented in the form of a proposal. The proposal can be edited further to block certain open items, if required. Once the proposal is acceptable, the payment run is executed resulting in clearing the open items on the vendors account and crediting the outgoing checks bank clearing account. Checks are then printed using the print function of the payment program.

2.5.6 Financial Accounting - AP -Manual Invoice/Credit Memo (V1A)

Vendor invoices for items / services not purchased through a standard purchase order can be invoiced manually using the invoice recording functions in SAP. Additionally, a vendor credit memo could also be recorded in the same manner.

The process involves getting approval for the invoice / credit memo from the responsible manager and entering the specifics of the invoice or credit memo. The processing of these requests creates open items for the vendor and updating the entered expense / accrual within the correct General Ledger account.

2.5.7 Asset acquisition through direct capitalization (V2A)To purchase an Asset investment(s) that does not have an asset under construction (AuC) phase, you capitalize the asset directly in Asset Accounting. The need for a new asset is requested and approved by the cost center manager, purchased through the purchasing department, and the costs associated with the purchase order are capitalized when the Vendor invoice is processed. (This will be a computer or such like)


2.5.8 Asset transactions – Retirements (with / without revenue) (V2B)

In business, assets are acquired, constructed, used (depreciated) and ultimately disposed of or sold. This scenario shows the processes for asset disposition. An asset may be scrapped (i.e. without revenue) or it may be sold.

If the asset is scrapped, the asset retirement without revenue transaction is used. On completing the transaction, the asset acquisition cost and accumulated depreciation are reversed out and the loss on asset retirement, if any, is recorded.

If the asset is sold, the asset retirement with revenue transaction is used. On completing the transaction the asset acquisition cost and accumulated depreciation are reversed out and the gain / loss on asset sale, if any, is recorded. The amount for which the asset is sold is recorded on a temporary clearing general ledger account. When the money for the sale is received, the temporary account is cleared off and the cash / bank account is updated.

Once the asset is disposed off completely, the asset gets a deactivation date.

2.5.9 Asset acquisition for constructed assets (V2C)Assets under construction (AuC) are a special form of tangible assets. They are usually displayed as a separate balance sheet item and therefore require a separate account determination and their own asset classes. During the construction phase of an asset, all actual postings are assigned to the AuC. Once the asset is completed, a transfer is made to the final fixed asset. This will be a building

The recommendation of using Investment orders to capture the costs of AuC assets during the period and month-end processing will ‘settle’ the costs from the Investment order to the AuC. This is done so that budget information can be entered for the AuC and tracking of the actual-to-budget can be performed. Once the AuC is completed, the final asset is created in the appropriate asset class, and the Investment order is set to ‘complete’ so that the next settlement will transfer the AuC asset value to the completed asset.

2.5.10 Financial Accounting - GL - Period End (plant) (V1I)The Plant/Central closing process is done to make sure that all financial postings are made to represent the plant(s) activity for the period. Daily activity in the plant is posting various financial documents into the general ledger and cost controlling module. This process makes sure that all activity in the plant is shown correctly, and that there are no missing financial postings. Some data (total stock value, total stock, valuation class, price control indicator, and price unit) are managed by period. For these values, and goods movements, to be posted to the correct period, the period must be set whenever a new period starts. Management reporting needs to receive plant information with reference to variances, WIP, and scrap to allow for the correct reporting of these figures. The production/process orders that are no longer active need to be flagged as ‘closed’ so that future postings will not be allowed. This process ends by flowing into the Central Closing process that finishes the financial reporting of the company.

2.5.11 Financial Accounting - GL - Period End (Central) (V1J)The closing operations component helps you prepare and carry out the activities required for month-end closing. For this purpose, the system provides a series of standard reports that you can use to generate evaluations and analyses directly from all of the posted account balance. The system helps you carry out the following:

Creating the balance sheets and P&L statements


Documenting the posting data

To carry out the closing operations in G/L accounting, you first need to carry out the closing operations in the sub-ledger accounting areas utilized. These include:

Accounts receivable and accounts payable accounting

Inventory accounting

Asset accounting

Month-end closing comprises all the activities involved in closing a posting period. You can open and close posting periods as part of month-end closing.

You close one or more posting periods in the past for posting, and permit posting to be made to one or more current or future posting periods. Typically, you will leave two periods open. The prior period is open to allow period-end adjustments and a new open period is open for customer and vendor postings.

Create external reports: You can use report programs to create the following reports, for example:

o Financial statements

o Sales tax report

o Withholding tax report

o Document the posting data (this includes the following reports):

Compact journal

Balance audit trail

Accounting reconciliation

Account balances

Open item list

Month-End Closing: Checklist

Item Description

Fixed Assets Execute the depreciation run and update the batch input session

Inventories GR/IR clearing account – clarify any differences and correct them if necessary

Clear the GR/IR clearing account

MM Period closing program

Settle the work in process

Receivables and Other Asset Items

Check whether all the billing documents have been posted

Additional Tasks Check whether the accrual/deferral documents have to be reversed

Carry out recurring entries and update the batch input session


Reconcile cost of sales accounting/period accounting

Close the posting period

Printing Reports and Notifications

Balance sheets and P&L statements

Sales tax report

Withholding tax report

Internal Closing

Item Description

Internal order tasks Settlement

Cost center-related tasks Assessment and cost center variance

2.5.12 Financial Accounting - GL - Year End (V1K) Year-end closing is split into two phases:

At the beginning of the new fiscal year, you open new posting periods and carry forward the balances from the previous year.

You then prepare and create the financial statements and document the business transactions using the balance audit trail.

The SAP ECC system offers a range of reports with which you can carry forward balances into the new fiscal year. During this process, the profit and loss accounts are carried forward to one or more retained earnings accounts. The balances of the balance sheet accounts are simply carried forward into the new fiscal year. You do not have to create special opening financial statements.

Any postings you make in the old fiscal year automatically adjust the relevant carry-forward balance. You do not have to close the old fiscal year and carry out the closing postings before opening the new fiscal year.

As with month-end closing, you can create all the external reports required, document the posting data, and carry out the internal evaluations.

Year-End Closing: Checklist

Item Description

Controlling CO versions for planning available for future period(s).

Accounting Perform normal month-end processing

Fixed Assets

Run the fiscal year change in Asset Accounting

This process creates the balance carry forwards for Asset Accounting. We recommend that you execute this run on the first day of the new fiscal year. Note: by this time, you should have completed year-end closing for Asset Accounting for the previous year.

Accounting Carryforward A/P balances

Carryforward A/R balances

Carryforward G/L balances

Run ‘Final’ financial reports


Close previous accounting period

2.5.13 Electronic Bank Statement (V1G)The SAP bank statement reconciliation program offers customers daily reconciliation of cash in transit postings made during the prior day. BAI is the most common file format for the bank statement used in the United States. Although it is regulated by the Bank Administration Institute, the format is loosely interpreted by most banks and can vary significantly from bank to bank. For this reason, the SAP system offers a wide range of flexibility when importing bank statements from each bank. The RFEBKA00 program imports account statements into the SAP R/3 system and then offers three options:

Create batch input sessions for updating the general ledger and the sub ledger

Post immediately to the general ledger and sub ledger

Create memo records

There is also the option to post only to the general ledger and then run the program again at a later time to post to the sub ledger. The most common usage is to post immediately.

2.5.14 Financial Accounting – Internal Projects (V1H) In manufacturing companies various Research and Development projects are undertaken which consume resources and incur costs or expenses. These projects are usually undertaken for future development of products. The product lines are generally determinable for such projects. The costs of these projects need to be tracked for various purposes such as cost control, return on investment calculations, tax reporting, etc.

This process makes use of SAP’s internal order functionality in order to track costs and status. For every project undertaken, an internal order is created using the R&D order type (Z100). Cost planning is carried on this order; the order is assigned to a profitability segment in the settlement rule. When the project is approved, the order is released. Costs incurred for the project can then be posted on the order. Periodically, the costs collected on the order are allocated to CO-PA by a process known as settlement. When the project is complete, and fully settled, the order is then closed by setting the appropriate status.

2.6 Controlling

2.6.1 AOP - Sales Quantity Budget and Transfer to SOP (V6A)Businesses typically have an annual planning exercise known as Annual Operating Planning (AOP). In this planning all aspects of the business are planned, namely: revenue, production, direct procurement, and indirect procurement, capacity, and product/overhead costs.

The AOP planning is also sometimes referred to as the Annual budget. The plan is prepared for the next fiscal year and data collection for the plan / budget is usually started in the last quarter of the current fiscal year.

The AOP exercise generally begins with forecasting the sales quantities and revenue for the coming fiscal year. Various bases are used to come up with the forecast. Some of the common techniques are extrapolating current year sales and quarterly sales forecasts.

The process starts with copying previous year’s actual sales quantities in Controlling-Profitability Analysis (CO-PA) into the AOP budget version as the basis for planning. The quarterly forecast


sales quantities for the current year are then copied into the AOP budget version. The figures are downloaded into Excel and sent to the sales managers for their review. The sales mangers review and adjust the sales quantities based on their information and judgment. Some of the plan figures, especially for new products are planned against only at the product line level. The revised sales quantity plans are loaded into CO-PA. A top-down distribution is performed to break out the quantities at product line level into a plan at product and customer level. The sales quantities are again reviewed, adjusted manually if necessary, and then valuated. This results in valuated sales revenue and cost of sales for the planned sales quantities.

The accepted sales quantities are then transferred to Sales and Operations planning where planning for the manufacture of the budget sales quantities occurs.

2.6.2 AOP - SOP through Long-Term Planning Transfer to LIS/PIS/Capacity (V6B)

After the sales plan is verified, the sales quantities are transferred to Sales and Operation Planning (SOP). In SOP, a long-term plan is created to match the manufacture of parts to be sold with the sales quantities. Materials requirements planning (MRP) is run in a simulated mode to review planned requirements for all the materials and resources required to manufacture the materials to satisfy the demand. Simulation of MRP also allows review of capacities of the plants. Capacity leveling can then be carried out to smooth out the bottlenecks in the capacities.

Once the simulated version of the manufacturing plan is accepted, the planned requirements are transferred to active version in demand management.

2.6.3 AOP - Purchased Material Price Planning (V6C)Standard costs for purchased materials need to be periodically reviewed and updated, if necessary, to match the current market conditions and negotiated prices.

This process begins with transferring the quantities of materials required from long term planning and downloading the latest purchase prices. The material requirements valuated with the latest purchase prices are reviewed by the buyers to compare with the current standards. The buyers update the spreadsheet with the prices that they determine should be the new standard. The updated prices are then uploaded as the new planned prices. These planned prices are used by the product-costing run to valuate the semi-finished and fished goods to come up with the standard cost of goods sold for the final products.

2.6.4 AOP - General Cost Center Planning (V6D)During the annual budgeting process, the managers of non-operational cost centers such as sales, marketing, administrative, research and development, etc. plan the costs for various cost types/elements for their respective cost centers. The usual starting point for development of these plans is the actual data for the current/previous year.

In this process, the previous year’s actual expenses for these cost centers are copied into an AOP budget version in cost center accounting. As an alternative, the previous year’s budget data can also be used as a starting point for the exercise. The data in this version is downloaded into spreadsheets by each cost element and cost center. The respective cost center managers review and update the budget values according to their requirements and plans. Then these plans are uploaded back into SAP. The plans in SAP are reviewed and finalized.

The planned depreciation on fixed assets is transferred separately to the cost center plan version. The system calculates the planned depreciation on assets by cost center based on the asset values posted on the cost centers. In the case of cost centers having machinery, the depreciation is planned based on cost center and activity type.


2.6.5 AOP- Manufacturing Cost Center Planning (V6E)During the annual budgeting process, the managers of non-operational cost centers such as sales, marketing, administrative, research and development, etc. plan the costs for various cost types/elements for their respective cost centers. The usual starting point for development of these plans is the actual data for the current/previous year.

In this process, the previous year’s actual expenses for these cost centers are copied into an AOP budget version in cost center accounting. As an alternative, the previous year’s budget data can also be used as a starting point for the exercise. The data in this version is downloaded into spreadsheets by each cost element and cost center. The respective cost center managers review and update the budget values according to their requirements and plans. Then these plans are uploaded back into SAP. The plans in SAP are reviewed and finalized.

The planned depreciation on fixed assets is transferred separately to the cost center plan version. The system calculates the planned depreciation on assets by cost center based on the asset values posted on the cost centers. In the case of cost centers having machinery, the depreciation is planned based on cost center and activity type.

The resource requirements in the form of planned activity quantities are transferred from Sales and Operations planning to the cost centers as planned activity consumption. Plan reconciliation between the SOP activity requirements and manually planned requirements on the operational cost centers is carried out. Once the activity quantities and budget amounts are finalized, planned activity prices are calculated in the system.

2.6.6 AOP - Research and Development Order and Cost Center Planning (V6F)

Various Research and Development (R&D) projects are undertaken to develop and improve products. The costs for these projects are tracked using special orders. During the annual planning exercise, the planned costs are entered for each of the R&D orders created by cost element. Once finalized, the costs are reviewed and transferred to profitability analysis by a process known as settlement.

2.6.7 Quarterly Plan – Sales Quantity Forecast (V6I)Businesses typically review their sales forecasts and operations quarterly on a rolling year basis.

This process starts with copying the existing planned sales quantities in Controlling – Profitability Analysis (CO-PA) into the forecast version as the basis for planning. The figures are downloaded into Excel and sent to the sales managers for their review. The sales mangers review and adjust the sales quantities based on their information and judgment. The revised sales quantity plans are loaded into CO-PA. The sales quantities are again reviewed and adjusted manually, if necessary.

The accepted sales quantities are then transferred to Sales and Operations planning where planning for the manufacture of the budget sales quantities occurs.

2.6.8 AOP- Standard Cost Calculation (V6G)Annually, the standard costs for products are updated as part of the Annual operations planning. This is necessary to reflect the changes in the prices of purchased parts, change in labor and overhead costs, and change in bills of materials and operations needed to manufacture the semi-finished and finished goods.

Once the planned prices for purchased parts are updated and planned activity prices are calculated, a costing run is done to calculate the standard planned prices of the materials. The calculated standards are reviewed for accuracy and the responsible persons are informed of any corrections


that must be made. Once the calculations are acceptable, the prices are updated as future planned costs in the respective material master records.

Once the current year is closed, the marked cost estimates are released. This results in a revaluation of existing inventory to the new standard prices.

2.6.9 AOP- Revenue Cost of Sales Transfer (V6H)After sales quantities, standard costs and all cost center budgets are finalized, the planned data is transferred to COPA. The sales quantities are valuated with planned sales prices to get the planned revenue. At the same time, the sales quantities are evaluated with the standard costs broken down by the cost components to get the planned cost of sales. The planned cost center costs are allocated to COPA by using planned assessment cycles.

The above processes result in a planned income statement by product line. The planned income statement is reviewed. After the income statement is approved, it is transferred from the AOP budget version in COPA to the active version. Both, the AOP budget version and active version are then locked for planning.

3 Functional ScopeSAP Best Practices are the easiest way to set up a business solution that provides unlimited scalability, best-of-breed functionality, complete integration, and easy collaboration for every business. With SAP Best Practices you can reap business benefits quickly and eliminate as much risk as possible. It provides you with the combined benefits of a powerful solution and proven business expertise that stems from collaborative efforts between SAP and its partners.

SAP Best Practices quickly turns your SAP software into a live system that handles all your specific business requirements. Preconfigured SAP ERP Enterprise business scenarios help you rapidly realize business benefits without extensive configuration. Use it to evaluate your specific business solution. And use it to implement this solution so that you can realize all its benefits faster, with less effort, and less expensively than ever before.

SAP Best Practices can be used by midsized enterprises that need rapid implementation or by large companies that must create a corporate template for their subsidiaries. It can be easily applied to existing customer solutions.

SAP Best Practices are built in a way that customers can easily use them. Three different components are included:

Detailed, step-by-step activation procedure including automated activities.

Extensive reusable documentation that you can use for self-study, evaluation, and for project team and end-user training.

Complete preconfiguration settings that provides the ability to run integrated key processes "out of the box" with reduced installation effort. The configuration is fully documented including preconfigured business processes, training material, user roles, data conversion tools, and test catalogs. It is built using the latest technology, so you can adapt it quickly and easily.


3.1 Building Block B32: Best Practices ECC Installation

PurposeThe building block Best Practices ECC Installation provides the necessary steps to prepare your development client for further installation steps. Here you will find installation procedures concerning setting up the client, the logical system, and other steps necessary for the installation of SAP Best Practices in an SAP ERP environment.

Function List Maintenance of user settings

Client maintenance

Maintenance of logical system

3.2 Building Block J02: Organizational Structure

PurposeThis building block creates a generic organizational structure in the system.

The following subsection describes the organization structure of the SAP Best Practices for Software Providers solution and the functions placed in the individual entities. The organization structure corresponds to the one of the SAP Best Practices for Baseline US V3.600 which is the same organizational structure used in SAP Best Practices for Telecommunications US V1.600

The SAP Baseline solution was designed to support alternatives in the organizational structure. The flexibility arises primarily from the possibility of creating structures that are more concurrent. The delivered organization entities are defined as follows:


3.3 Building Block V03: Financial Accounting

PurposeIn the area of financial accounting, the SAP Best Practices for Software Providers V1.600 solution ensures you have access to the necessary information to increase the efficiency in accounting. The following functions support your financial processes and form a basis for industry specific enhancements,

Profit and Loss Statement

General Ledger

Accounts Receivable

Accounts Payable

Bank Accounting

Tax Accounting and

Asset Management Accounting

In addition, the management accounting tool is provided to monitor and control performance relevant information in an environment of complete integration with all operative transactions throughout the company. Accounting maintains a consistent, reconciled, and auditable set of books for use in


statutory reporting, management support and as a source for analytic applications, and helps a company take control of its profitability.

Function ListThe building block consists of configuration that covers the following areas:

Financial Accounting

Chart of Accounts

Financial Statement Version

Assets

Exchange Rates

General Ledger

Baseline package Chart of accounts

Journal postings

Transaction clearing

Month end closing

Year end closing

Accounts Payable

Invoice and credit note processing

Process outgoing payments


Generate aged listings

Accounts Receivable

Invoices and credit note processing

Process incoming payments (Lockbox and manual check application)

General Customer Credit Management


Generate aged listings

Customer Statements

Key Points Can be used by enterprises operating on a national level, and by groups operating on a global

level

Can be used as the basis for setting up integrated solutions

With the new ledger, you can extend the general ledger simply and rapidly with user fields


3.4 Building Block V08: Basic Controlling

PurposeThis building block is used to set up industry-independent basic controlling. This creates a basis for industry-specific enhancements.

Function ListThe building block consists of configuration that covers the following areas:

Master Data

Cost Center / Cost Center Groups

Activity / Group Types

Primary and Secondary Cost Elements

Internal Orders

Cost Center Planning

Cost and activity inputs planning

Activity output/prices planning

Automated loading of cost center budgets

Cost center reporting

Internal Orders

Statistical orders for accumulating expenses

Regular internal orders for tracking miscellaneous capital transactions (AUC)

Orders for internal expenses tracking (Marketing and R &and; D Projects)

Budget internal orders for controlling costs

Planning Aids

Planning by cost center and account

Tools for subsequent year planning

Computation of activity rates based on planned expenses

3.5 Building Block V05: Materials ManagementThis building block is used to set up industry-independent materials management. including materials, vendors and purchase orders. This creates a basis for industry-specific enhancements.

Function List Master Data

Vendors

Info Records

Source Lists


Material taxability maintenance

Purchase Order Release Strategy (Order type , Purchasing Group, Value)

Purchasing

Quotations

Purchase Requisitions

Contracts / Blanket orders

Purchase orders

Vendor Analysis

Materials

Stock items

Non-stock items

Goods receipt

Goods issue

Invoice Verification

Process against purchase order and goods receipt (3- way match)

Process against purchase order only

Process credit and debit memo

3.6 Building Block V04: Sales & DistributionThis building block is used to set up industry-independent sales and distribution processes, including customers, prices and sales documents. This creates a basis for industry-specific enhancements.

Function List Master Data

Customers

Pricing (List and Discounted)

Customer Credit Master

Customer taxability maintenance

Sales

Sales quotations / Cost estimates

Orders

Delivery

Shipment creation

Picking and goods issues

Billing

Invoices

Credit memos


Debit memos

3.7 Building Block V06: Production Planning and ControlThis building block contains all the necessary activities and settings required for production and implementation of the master data for the Production Planning and Control System.

Function List

The building block contains the major activities within the production area and following functions are provided to support the Production Planning and Control building block:

Basic data for Production Planning

Settings for sales and operations planning

Essential settings required for materials requirement planning

Essential settings required for shop floor control

3.8 Building Block J10: Asset AccountingThis building block is used to set up industry-independent asset accounting processes, including asset types and depreciation. This creates a basis for industry-specific enhancements.

Function ListThe following functions are provided to support the J10 building block:

Fixed Assets

Process depreciation

Track Assets Under Construction

Retire assets

Sell assets

Purchase Assets

Depreciation reporting for book and tax (US) purposes

3.9 Building Block V18: Product Cost PlanningThis building block is used to set up industry-independent product cost planning processes, including standard costs, results analysis, and settlement. This creates a basis for industry-specific enhancements.

Function List

Settings Cost Estimate with Qty Structure

Define Cost Component Structure


Definition of Valuation Variant

Settings for Costing Variant

Activate Cross-Company Costing

Results Analysis

Define Results Analysis Key

Define Results Analysis Version

Define Valuation Methods

Define Assignment of Cost Elements for WIP & RA

Define Update of WIP Calc & RA

Define Posting Rules for Settling Work in Process

Define Valuation Method (Actual Costs)

Variance and Settlement

Define Default Variance Keys for Plants

Create Allocation Structure

Create Settlement Profile

Define Target Cost Versions

Manufacturing

Define Cost-Relevant Default Values for Order Types

Define Goods Received Valuation for Order Delivery

3.10 Building Block V17: Profitability AnalysisThis building block is used to set up industry-independent profitability analysis processes, including COPA reports. This creates a basis for industry-specific enhancements.

Function List

Create COPA Structure

Create Operating Concern BPUS

Maintain Characteristics - Transfer from SAP Table

Maintain User Defined Characteristics

Maintain Value Fields

Create Master Data

Activate COPA

Create a set for product line A_PA_0001 for table CE7BPUS

Flows of Actual Values

Assign PA Transfer Structure to Settlement Profile

Define Key Figure Schemes


Create COPA Report

3.11 Building Block V64: PP - MTS Basic DataThis building block is used to set up industry-independent basic data to support the make to stock processes.

Function List Define Order Types Define order type-dependent parameters Define Checking Control Define Confirmation Parameters Define Scheduling Parameters for Production Orders

3.12 Building Block V66: PP MTO Basic DataThis building block is used to set up industry-independent basic data to support the make to order production processes.

Function List Define Combination of Item Categories/Account Assignment Cat

Define Order Types

Define BOM Explosion Control

Define Requirements Types

Define Requirements Classes

Define Strategy Group

Define Strategy

Define Checking Control

Define Confirmation Parameters

Define Scheduling Parameters for Production Orders

3.13 Building Block V49: PP - ETO Basic DataThe SAP Best Practices for Telecommunications delivers configuration to enable the process of providing goods to for an engineer/project manufacturing production order.

Function ListThe following functions are provided to support the V49 building block:

Define Order Types Define Checking Control


Define Confirmation Parameters Define Scheduling Parameters for Production Orders

3.14 Building Block V4E: Free of Charge DeliveryThe SAP Best Practices for Telecommunications delivers configuration to enable the process of providing goods to a customer at no cost. A unique sales order type is created that is non-billing relevant, but is expensed to a specified cost center that is determined from the order reason (free of charge sample) assigned to the sales order. The order is confirmed based on the availability of goods. A delivery is then created; the goods are subsequently picked, confirmed, and delivered to the customer.

Function ListThe following functions are provided to support the V4E building block:

Free of Charge Delivery

3.15 Building Block V4F: SD Configuration; Returns and Complaints

This building block is used to set up industry-independent basic data to support the returns and complaints processes including creation of the credit memo request and return delivery.

Function ListThe following functions are provided to support complaints processing:

Sales Document Types

Return Item Category

Return Schedule Lines

Assign Shipping Points for returns

Define Billing

3.16 Building Block V4I: SD Configuration ETO ScenarioThis building block is used to set up industry-independent basic data to support the ETO sales scenario process.

Function ListThe following functions are provided to support the V4I building block:

Sales functions for Project/Engineer to order sales


3.17 Building Block V4J: SD Configuration MTO ScenarioThis building block is used to set up industry-independent profitability analysis processes, including COPA reports. This creates a basis for industry-specific enhancements.

Function ListThe following functions are provided to support the V4J building block:

Sales functions for make to order sales

3.18 Building Block U50: Telecommunications Delta Configuration

This building block is used to set up industry specific configuration changes, including COPA characteristics, reports and cost centers. This creates a basis for industry-specific enhancements.

Function ListThe following functions are provided to support the U50 building block:

Cost Centers

COPA Reports

Assessment Cycles

3.19 Building Block U51: RM-CA CustomizingThis building block is used to set up industry specific configuration changes, including COPA characteristics, reports and cost centers. This creates a basis for industry-specific enhancements.

Function List Basic Configuration

Payment Process

Returns

Security Deposit

Refund

Dunning

Write-offs

Reconciliations and Closing

Master Data


3.20 Building Block U53: Configuration for VC ScenarioThis building block is used to set up industry specific configuration changes, including sales related billing and delivery configuration. This creates a basis for industry-specific enhancements.

Function List Requirements Classes For Costing/Account Assignment

Settlement Profile

Characteristics Groups

Item Category Groups

Assign Item Categories

Sales Documents: Copying Control

3.21 Building Block U59: Master DataThis building block is used to set up industry specific master data, including customer, and delivery. This creates a basis for industry-specific master data that will be used in the business scenarios.

Function List Other Setup

Create Sets Y0010_BALSHEET & Y0010_REV_COGS

Customize Bank Routing Number

Check lots

Product Hierarchy

Material Group

Release Strategy Setup

Other Condition Records

COPA Condition Records

Activate FI Initialization Programs: RK811XST (Create TRANSACTION Basic Sets for Allocation Processor); RFTAXIMP: Tax code import DC3K900904

FI Tax Rates

Purchasing Tax Code Condition

Tax Condition Records

Other Master Data


Activity Types

Customer Master

Vendor Master

Work Center

Variant Characteristics

Material Master

Engineering Change Master

Material Master Revision Levels

Purchase Contracts

Purchasing Info Record

Source List

Variant Tables

Dependencies

Dependency Net

Configuration Profile

BOM

BOM dependencies

Output Condition Records

Create Sales Condition Records (AN00)

Create Sales Condition Records (BA00)

Create Sales Condition Record (BA00) II

Create Shipping Condition Records

Create WMTA Condition Record

Create Billing Condition Records

Create RFQ and Quotation Rejection

Create Purchase Contract

Create Purchase Order

Create Goods Receipt and Goods Issue

ETO Master Data

Material Master

Sales Pricing Conditions

Create Standard Project

Standard Network


Customer Return Scenario Master Data

Material Master


Sales Pricing Conditions


BOM (Header and add Items)

Routing

3.22 Building Block U54: Quality Management in Procurement

This building block contains all of the activities necessary when activating the Quality Management basic settings for Materials Management (MM) procurement processes.

Function ListThe following functions are provided to support and enable the Quality Management core building block:

Maintenance of master data for inspection plans, for example, the creation of catalogs and selected sets

General Quality Management Customizing for MM.