STUDENT TEXT FULLY INTEGRATED VERSION (MM, …athensstatesapfaculty.pbworks.com/f/Flya+Kite+Fully+Integrated... · (MM, PP, SD, FI/CO, HR) ... ALL MATERIALS FROM SAP LIBRARY ADAPTED

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF

SAP AMERICA UNIVERSITY ALLIANCE

©2008 Ross Quarles and Fawzi Noman STUDENT TEXT INTEGRATED VERSION Page: 1

STUDENT TEXT

FULLY INTEGRATED VERSION

(MM, PP, SD, FI/CO, HR)

Flya Kite Case: Processing transactions through the

logistics and support processes of SAP

Ross Quarles Fawzi Noman

Version 4.0 03/01/2009

Sam Houston State University

Huntsville, Texas




Table of Contents – Student Text

I. Chapter 1: Introduction

General description of case for students and introduction to basic SAP modules and terminology, business processes, and types of data.

II. Chapter 2: Procurement Logistics (MM) Discussion of the procurement process in SAP along with descriptions of the exercises in the Student Exercises document that require students to create vendor and material master records and go through the purchasing cycle from purchase requisition to logistics invoice verification.

III. Chapter 3: Production Logistics (PP) Discussion of the production logistics process along with descriptions of the exercises in the Student Exercises document that require students to create MRP views for materials, BOM, routing, run MRP, convert planned orders, issue goods to manufacturing, confirmation of completion, and order settlement.

IV. Chapter 4: Sales Logistics (SD) Contains description of the sales and distributions logistics process along with descriptions of the exercises in the Student Exercises document that require students to create customers, create sales views for trading goods and finished products, material prices, discounts, customer material info records, item proposal, customer inquiry, create sale orders, create delivery, pick goods, post goods issue, and bill the customer.

V. Chapter 5: Financial Accounting and Controlling (FI and CO) Contains discussion of both the financial accounting and controlling administrative processes along with descriptions of the exercises in the Student Exercises document that require students to create and/or process general ledger accounts, primary cost elements, vendor records, general ledger document entry, posting vendor invoices, posting outgoing payments, receiving customer payments, distribution cycle, and assessment cycle.

VI. Chapter 6: Human Resources (HR)1 Contains discussion of human resources administrative process along with descriptions of the exercises in the Student Exercises document that require creation of HR organizational structure, creation of jobs and positions, entering job evaluations and pay grades, entering initial applicant data, and hiring an applicant.

1 This chapter was developed by Professor Kathy Utecht of Sam Houston State University




CHAPTER 1: Introduction Case Overview Flya Kite is an integrated case with exercises that allow participants to process transactions for sales logistics, production logistics, procurement logistics, accounting/controlling, and human resources. The case is preconfigured with all control/configuration data and master data necessary to process those transactions. However, for each area, the case has optional exercises that can be used by participants to set up the master data required for transaction processing. Each participant will utilize his/her own set of master data (either self-created or pre-established) to process transactions within Flya Kite. The case can be used in its entirety (all sets of exercises – either with pre-established master data or with self-created master data) in classes that have the objective of addressing the primary business processes of sales, production, procurement and materials management, etc. Alternatively, each set of exercises addressing a particular logistics or support area can be used independently in classes where only that business area is of concern (again with or without master data creation exercises). Through the use of the Flya Kite case, in total or in part, students are introduced to SAP navigation, master data use (and optional creation), transaction processing, the flow of data through each business process, and the integration of the various processes with one another. This feature allows the use of the case across disciplines with minimum detailed knowledge of the complete SAP system on the part of the instructor. Its best use would be to introduce students to how transactions are processed and how processing makes use of master data to process transactions across the value chain. SAP Overview SAP (Systems, Applications and Products in Data Processing) started operations in Germany in 1972. It is the world’s largest vendor of standard application software, the fourth largest software vendor in the world, and the market leader in enterprise applications software. The most current version of R/3 utilizes client server technology and contains over 30,000 relational data tables that enable a company to link its business processes in a real-time environment. Each instance (installation) of SAP can be distinctively configured to fit the needs and requirements of customer operations (within limits). Basic SAP Modules Flya Kite utilizes the five “basic” modules of SAP R/3 as described in the following table.




SAP Module

Function (Process) Functional Areas

MM Materials Management (Procurement Logistics)

Purchasing, invoice verification, inventory management, warehouse management

PP Production / MRP (Production Logistics)

MRP, production orders, bills of materials, work centers, routing instructions, batch management

SD Sales and Distribution (Sales Logistics)

Order entry, picking/packing/shipping, invoicing, inquiries, quotes, sales reporting

FI Financial Accounting (Support Process)

General ledger, A/R, A/PAY financial reporting, cash management legal consolidation

CO Cost Accounting (Support Process)

Cost accounting and internal reporting by cost center, internal order, project, profit center, or other unit, profitability analysis

HR Human Resources (Support Process)

Employee master data, training records gross/net calculation, payroll, planning and reporting

The various modules of SAP R/3 are highly integrated. Much of the data in the system are shared. The table below indicates some of the sharing aspects of master data in SAP.

Master Data Record Modules Using Record

General Ledger Accounts FI, CO, SD,MM, PP, HR

Customer Master Records FI, SD

Vendor Master Records FI, MM, PP

Material Master Records SD, MM, PP, CO

SAP General Terms There are a number of terms that have specific usage and meaning in dealing with SAP. Some of these general terms are identified below.

Client: The highest level in a SAP instance. A client is a self contained unit with a separate set of master records and its own set of configuration tables. An instance (installation) can have more than one client (e.g., a training client, a testing client, and a production client). In using SAP the user logs on to a particular client that usually has a three digit numeric identifier. Company Code: Represents an independent legal accounting entity that contains a balanced set of books as required by law or regulation. A client may have more than one company code (e.g. a company code for the US, one for Germany, one for Canada, etc.) Chart of Accounts: A list of all accounts in the General Ledger for a company code. Each company code must be assigned one, and only one chart of accounts. However, more than one company code can use the same (i.e., identical) chart of accounts. SAP comes preconfigured with a large number of charts of account. For example, the




delivered US chart of accounts is CAUS. Accounts can be added to, deleted from, or modified in the delivered chart of accounts as desired by the user. Passwords: Each user has his or her own password. On the initial log in to the system, the user must change a generic delivered password to his/her own. The password must be at least three characters long, cannot begin with a “!” or “?”, and the first three characters unique and not contained in the user name. Roles and Profiles: Roles specify the sets of tasks or activities that can be performed by a particular user within the system. A role is assigned to each user. When the user logs on, the system automatically presents a specific menu for that user’s assigned role. For example, a receiving clerk can perform only certain tasks within the SAP system. When a receiving clerk logs on, that user’s role will define what the user will be allowed to view, create, change, delete, etc. Profiles work in the same manner as do roles to restrict authorization for access to the system. User profiles and roles are entered by system administrators into user master records thus enabling users to access and use specific functions within the system. In the Flya Kite case, users will have authorization to all master data and transaction processing applications. This would be highly unusual in actual practice given the need for internal controls and separation of duties. Session: Each instance in which a user is connected to the SAP system is known as a session. A user can have up to nine sessions open at any given time (but each session is logged into the same client and company code). Configuration: Configuration is table-driven customization of the SAP system to meet specific customer requirements. In configuration the user sets values in tables to cause the system to function in a desired manner. Configuration is somewhat like setting the defaults in a word process or spreadsheet application. It does not change the underlying source code in the system. In the Flya Kite case there are no configuration exercises. The case system has been preconfigured.

Business Processes A business process can be described as a set of linked activities that transform an input into a more valuable output thus creating value. In many cases business processes are classified as operational processes or as support processes. At the most basic level, a typical business utilizes three operational processes: procurement (purchasing and materials management), production, and sales and distribution (customer order management). The typical support processes include accounting/controlling and human resources. While these processes have specific identities, they are linked together (integrated) in order to carry out the day to day activities of a business. For example, the sale of a manufactured product involves not only the sales process but also production (the creation of the product), procurement (of necessary raw materials), accounting/controlling to determine the profit on the sale, and human resources to ensure the operations are staffed with qualified or trained employees. These linkages of activities across business processes necessitate the sharing of data across those processes, regardless of which process created the data initially. For example, data




related to a finished product may be initially created in the production process, but the data are also required in the procurement process and, of course, in accounting/controlling for costing purposes, as well as in calculating pay based on work production hours. SAP as an integrated ERP system utilizes the principle of a common data record for a given object that can be accessed by any process that has need of the various attributes contained in that common record. Business processes are often viewed as elements of a logistics value chains. From this perspective the operational processes are defined as sales logistics, production logistics, and procurement logistics. This is the approach taken in the overall structure of the Flya Kite case. The case is separated into the sections as outlined below. Types of Data There are three differing types of data within the SAP system: control or configuration data, master data, and transaction data. Control or configuration data include system and technical functions of the SAP system itself. These data drive the logic of the applications within the system and is primarily used for defining the details of business processes. For the Flya Kite case, all control/configuration data have been pre-established so that no configuration is necessary to complete the case exercises. Master data represent the various business entities present in the system, both internal and external. For example, master data include internal entities such as the company, a plant, a sales area, a cost center, an account, a material, a routing, a bill of material, or a personnel file. In addition there are external entities that are a part of the system’s master data such as vendors, customers, employees, and even competitors. From one perspective, master data can be thought of as providing the “which” or the “what” that is of interest in the activities of the business process. The attributes of the fields within master data are relatively stable. For example, the master data for a customer containing specific values for the customer’s attributes such as name, address, delivery priority, terms of payment, etc. vary little over time. Once the master data record for the customer is set up in the system, it is rarely changed. Also, once set up within the system, it can also be accessed by any business process that may have use for the master data. For example, a customer master record may be used in sales, transportation and shipping, production, marketing, accounting, or any other process that may have use for data contained in the master record. The sets of exercises in Flya Kite contain optional exercises that can be used to set up master data for each of the logistics areas and for accounting. If these optional exercises are not assigned or completed, the case contains pre-established master data records for each process that can be used to process transactions in the transaction processing exercises. As an additional alternative, the optional exercises involving creation of master data can also be used to create additional master data beyond that contained in the case. This allows creation of transaction processing exercises in addition to those already contained in the case. Transaction data describe a business event or may be the result of a business process. For example, a sales order would contain transaction data that have resulted from a customer placing an order to purchase a product from the company. The various attributes necessary to process that sales order transaction would include such data as the customer (which allows detailed customer data to be drawn from the customer master record), the item or




items being sold (which would draw data from the material master records for those items), the quantities being sold, the desired delivery date, the customer PO number, etc. While the customer master data for this transaction would be the same for various sales orders to that customer, the other data such as items wanted, quantities, delivery dates, etc. would most likely vary from order to order. For this reason, transaction data vary from event to event. Transaction data may also arise as the result of the outcome of a completed business process. For example, the system may process an inquiry to determine the current stock quantity level for a raw material. That inquiry is a transaction that extracts the data for the quantity on hand in the warehouse. This too, of course, will vary over time. Other examples, pertaining to human resources, would involve the hiring of employees and pay transactions. From one perspective, therefore, transaction data can be viewed as resulting from the events or activities that are taking place in the business. The transaction data represent the recorded attributes, elements, and results or outcomes of business events and activities, and, as a result is the most volatile and frequently used data in day to day business operations. Each of the logistics and support processes addressed in Flya Kite contains exercises that require the processing of transactions through the particular process. References: Curran, Thomas A., and Andrew Ladd. SAP R/3 Business Blueprint. Upper Saddle River, NJ, Prentice Hall, 2000. McDonald, Kevin, et al. Mastering the SAP Business Information Warehouse. New York: John Wiley & Sons, 2002. Hernandez, Jose A., Jim Keogh, and Franklin F. Martinez. SAP R/3 Handbook. 3rd ed. New York: McGraw-Hill, 2006. Hayen, Roger. SAP R/3 Enterprise Software, An Introduction. New York: McGraw-Hill, 2007. SAP Help Portal. <http//help.sap.com>




CHAPTER 2: Procurement Logistics (MM) Procurement logistics, defined as Materials Management (MM) in R/3, involves purchasing, inventory management, and warehouse operations. Materials must be ordered from vendors, received into the warehouse, issued from the warehouse for sale or for use in manufacturing, and the vendor must be paid. In all of these processes the quantities ordered and on hand, the prices to be paid, and the costs to be charged to sales or manufacturing must be tracked. The high level of integration in R/3 simplifies many of the tasks associated with these activities such as determination of the optimum source of supply, analyzing and comparing vendor pricing, issuing purchase orders, managing authorizations for purchase requisitions, and processing invoices for payment. In addition, for manufacturing firms, inventory management must be highly integrated with production planning to ensure that raw materials and components are available when production is scheduled. The graphic below identifies the process flows and master data requirements for procurement logistics processing. Vendor Data: Vendors are business partners that are suppliers of materials or services to the firm. While vendors can be internal (components of the same company), the vendors in this case are external – parties that are independent entities that are not affiliated with or a part of Flya Kite. In order to facilitate purchases from these external vendors, a vendor master record is set up within the SAP system. The attributes that are needed within the vendor master record include items such as the vendor name, address, tax jurisdiction code, language, payment terms, currency to be used, etc. These are the data items that will be of use each time a purchase is initiated with the particular vendor and do not change frequently. When a vendor master record is created in SAP, the choice can be made to let the system assign a vendor number or the user can assign the vendor number. It is generally better to allow the system to assign the vendor number thereby letting the system track numbers and thus prevent duplications. Once the vendor number is assigned, that becomes the key value used to track business activities with the vendor. The vendor number not only tracks the purchasing transactions with the vendor, it also serves as that vendor’s account number in the accounts payable subsidiary ledger in the Financial Accounting (FI) module of SAP. If the company wishes to purchase something from a given vendor, inputting that vendor’s number in the purchase order will automatically reference and access all vendor master data

Vendor Data

Invoice

Verification

Goods

Receipt Purchasing Purchase

Requisition

Material Data




necessary to carry out that transaction and also facilitate the entry required in the payables ledger for the amount owed when the materials are received.

In many cases, a company may wish to enter a long term purchasing arrangement with one or more of its vendors. One means of doing this in the SAP system is a contract. This is a type of "outline agreement", or longer-term buying arrangement rather than one or a series of individual purchases. The contract is a binding commitment to procure a certain material or service from a vendor over a certain period of time. A scheduling agreement is another type of "outline agreement", or longer-term buying arrangement. Scheduling agreements provide for the creation of delivery schedules specifying purchase quantities, delivery dates, and possibly also precise times of delivery over a predefined period.

In many cases a company may wish to purchase a given material from one particular vendor. This eliminates the need to search for possible vendors for the given material when a purchase is required. The SAP system allows for the creation of a purchasing info record that will accomplish this task. The info record establishes the link between a given material and specific vendor. This info record contains data that facilitate the purchasing activities. For example, the info record shows the unit of measure used for ordering from the vendor and indicates vendor price changes affecting the material over a period of time. A business may wish to purchase materials or services from a number of vendors and thus create and maintain relationships with more than one vendor as a matter of company policy. This can be done by creating a quota arrangement that allows the company to automatically apportion the total requirement of a material over a period among a number of different sources of supply.

Material Data: All materials within the SAP system are tracked through the use of a material master record. While there is a wide variety of materials that can be purchased from outside vendors (as opposed to being produced in manufacturing within the company), trade goods and raw materials are the most prevalent. Trade goods are goods or materials that are purchased with the intent of being resold. These goods are purchased for later sale. Raw materials, however, are goods that are purchased for use used in manufacturing to produce other products which, in turn, will be sold. Raw materials are used in the manufacturing process to produce finished goods which will be sold to customers. In all of these cases, a material master record must be created in the SAP system in order to track transactions involving a given material. Such activities as ordering, receiving the material, stocking the material into the warehouse, issue of the material to manufacturing or for sale, shipping the material, costing the material to determine profit on a sale, etc. will all use data contained within the material master record. For this reason, the material master record may be described as the “most integrated” data record within SAP and thus contains a large volume of individual data attributes. Below are a number of areas that utilize data from the material master record and examples of the data used by each.

Accounting Valuation and costing/price calculation information. Examples: Standard price, past and future price, and current valuation.

Materials planning and control




Information for material requirements planning (MRP) and consumption-based planning/inventory control. Examples: Safety stock level, planned delivery time, and reorder level for a material.

Purchasing Data provided by Purchasing for a material. Examples: Purchasing group (group of buyers) responsible for a material, over- and underdelivery tolerances, and the order unit.

Engineering Engineering and design data on a material. Examples: CAD drawings, basic dimensions, and design specifications.

Storage Information relating to the storage/warehousing of a material. Examples: unit of issue, storage conditions, and packaging dimensions.

Forecasting Information for predicting material requirements. Examples: How the material is procured, forecasting period, and past consumption/usage.

Sales and distribution Information for sales orders and pricing. Examples: Sales price, minimum order quantity, and the name of the sales department responsible for a certain material

For each of these and for all areas that access material master records for transaction processing, only the data pertinent for that particular area are presented in a view for the area. The view for each area must be created. For example, the sales view for a material must be created that includes items such as the transportation group for route determination and the loading group for determination of the type of equipment required in order to move the material into the shipping area from the warehouse.

A unique number is assigned to each material master record. This number identifies a specific material. Material numbers can be assigned internally or externally. Internal number assignment means that the system assigns material numbers, whereas external number assignment means that the person creating the material master record does so. Once this number is assigned, it is used to track the material throughout the SAP system.

The material master record contains attributes of the given material such as the description of the material, the units of measure (e.g., base or stockkeeping unit, order unit, sales unit, unit of issue), material type (e.g. trading, finished, raw material), gross and net weight (with and without packaging, respectively) and weight units (e.g., lbs, ounces, kilos, etc.), price (e.g., standard, moving average), packaging material required for sale, loading group (e.g., forklift, crane, handcart), country of origin, shelf life, and transportation group (e.g., on pallets, in liquid form, etc).

Procurement logistics transaction process flows: From an overall perspective, the logistics value chain processes involve obtaining purchased materials from suppliers, monitoring the status of those purchases, and receiving the items into inventory. The process involves the creation of a purchase requisition followed by the creation of a purchase order, the receipt of goods into inventory, the receipt of an invoice for the acquisition, and the payment of that invoice.




Purchase Requisition

A purchase requisition is an internal document (one that is used within the company only) that instructs the purchasing department to initiate steps to buy a material or procure a service by a certain date. This request may come from an individual who is authorized to request such a purchase or it may come from the MRP (materials requirement planning) system. The MRP system uses a number of statistical methods to anticipate future demand for a given stock item. That demand is balanced with the current quantity and other demand needs of the item to determine the need to acquire a given additional quantity of the item at some date in the future. If the company has not yet determined the vendor for the item and created a vendor master record in the SAP system, the purchasing department must identify the appropriate vendor and create that master record. If the vendor has been previously identified and the appropriate record created in the system, purchasing can then proceed to the processing of a purchase order to acquire the material from the vendor. The integration within the SAP system allows the data from the requisition such as the material number, quantity needed, desired delivery date, etc. to automatically populate the purchase order.

Purchasing (Purchase Order)

A purchase order is a legally binding instruction from a purchasing organization to a vendor to delivery a quantity of material or to perform a service at a given time at an agreed upon price. The purchase order contains data such as the required material, the quantity to be delivered, the price, terms of delivery, etc. The purchase order can also include a storage location in the warehouse where the material will be stored when received. This storage location is, of course, for internal use only and is of no use to the vendor. If the vendor accepts the purchase order, the material will be delivered as per the requirements established in the purchase order.

Goods Receipt

When ordered materials arrive from the vendor, a goods receipt must be processed in order to receive the material into inventory and update the quantity records for the material. As soon as the ordered goods arrive, the goods receipt is posted. The material is thus recorded in the inventory management system. The goods receipt triggers quality inspection and placement of the material into storage (stock putaway), and settlement with regard to the goods received.

If a material is delivered for a purchase order, it is important for all of the departments involved that the goods receipt entry in the system references this purchase order, for the following reasons:

Goods receiving can check whether the delivery actually corresponds to the order. The system can propose data from the purchase order during entry of the goods

receipt (for example, the material ordered, its quantity, and so on). This simplifies both data entry and checking (overdeliveries and underdeliveries).

The delivery is marked in the purchase order history. This allows the Purchasing department to monitor the purchase order history and initiate reminder procedures in the event of a late delivery.

The vendor invoice is checked against the ordered quantity and the delivered quantity.




The goods receipt is valuated on the basis of the purchase order price or the invoice price.

If material is intended for stocking into the warehouse, the purchase order data can define a storage location for it. This storage location is then automatically proposed by the system during entry of the goods receipt and can be accepted or changed. If no storage location is entered in the purchase order, the storage location must be specified when the goods receipt is entered.

Goods receipts for the warehouse can be posted to three different stock types: To unrestricted-use stock: stock located in the warehouse that is not subject to any

kind of usage restrictions. To stock in quality inspection: stock that has been received but is in the process of

incoming quality inspection and which has not yet been released for unrestricted use. To blocked stock: stock that is present in the company but, for various reasons, is not

to be used and cannot be classified as unrestricted.

The purchase order data can define whether or not the material is to be posted to stock in quality inspection. However, at the time of goods receipt the decision as to which stock type the material is posted can be revised.

When a goods receipt is entered into the system a number of other activities occur and updates take place.

Creation of a Material Document: When the goods receipt is posted, the system automatically creates a material document which serves as proof of the goods movement from receiving to the warehouse. Creation of an Accounting Document: Parallel to the material document, the system creates an accounting document. The accounting document contains the posting lines (for the corresponding accounts) that are necessary for the movement. Creation of a Goods Receipt/Issue Slip: When the goods receipt is entered, a goods receipt/issue slip can be printed at the same time. Sending a Mail Message to Purchasing: If the goods receipt message indicator has been set in the purchase order, the buyer automatically receives a message informing him/her of the delivery. Stock Update: Which stocks are updated in the material master record depends on the destination of the goods:

Goods receipt into the warehouse: If the goods are destined for the warehouse, the system increases total valuated stock and the stock type (for example, the unrestricted-use stock) by the delivered quantity. The stock value is updated at the same time.

Goods receipt into consumption: If the goods are destined for consumption, only the consumption statistics are updated in the material master record.

Goods receipt into goods receipt blocked stock: If the goods receipt is posted into goods receipt blocked stock, the stock level remains the same. The goods are recorded only in goods receipt blocked stock of the purchase order history.

Goods receipt into a new storage location: If goods are posted into a storage location that does not yet exist for this material, the storage location is




automatically created in the material master record when the goods receipt is posted (if automatic creation of the storage location is allowed for both the plant). If automatic creation is not allowed, the user must add the new storage location to the material master record before a goods receipt to it can be posted.

Update of General Ledger Accounts: When the goods receipt is posted, the system automatically updates the G/L accounts by the value of the goods receipt. Updates can also occur in other related applications. In the case of a goods receipt to consumption, for example, the account assignment object (such as a cost center, order, asset, etc.) is debited. Updates in the Purchase Order: When a goods receipt is posted, the following purchasing data are updated:

Purchase order history: During goods receipt posting, a purchase order history record is automatically created. This record contains data essential for Purchasing, such as: the delivered quantity, the material document number and item, the movement type, and the posting date of the goods receipt.

Purchase order item: If the "delivery completed" indicator is set in the material document, the order item is considered closed, and the open purchase order quantity is set to zero.

Other Updates: Depending on the characteristics of the material, movement, and components used, additional updates are carried out in other components. For example, a goods receipt is relevant for:

Entries to be made in the planning file or independent requirements reduction in materials planning

Statistical data in Inventory Controlling Vendor evaluation data in Purchasing Transfer requirements and quantities in the Warehouse Management System Inspection lots in Quality Management

Invoice Verification

The invoice verification component of the Materials Management (MM) system provides the link between the Materials Management and the Financial Accounting, Controlling, and Asset Accounting components.

Invoice Verification in Materials Management serves the following purposes: It completes the materials procurement process - which starts with the purchase

requisition, continues with purchasing and goods receipt, and ends with the invoice receipt

It allows invoices that do not originate in materials procurement (for example, services, expenses, course costs, etc.) to be processed

It allows credit memos to be processed, either as invoice cancellations or discounts Invoice Verification does not handle the payment or the analysis of invoices. The information required for these processes is passed on to other departments. Invoice Verification tasks include:

Entering invoices and credit memos that have been received Checking the accuracy of invoices with respect to contents, prices, and arithmetic




Executing the account postings resulting from an invoice Updating certain data in the SAP system such as open items and material prices Checking invoices that were blocked because they varied too greatly from the

purchase order

Each invoice contains various items of information. To post an invoice, this information is entered into the system. If an invoice refers to an existing transaction, certain items of information will already be available in the system. The system proposes this information as default data so that the user only needs to compare it and, if necessary, correct any possible variances. If an invoice refers to a purchase order, for example, the user only needs to enter the number of the purchase order. The system selects the right transaction and proposes data from the purchase order, including the vendor, material, quantity ordered, terms of delivery, terms of payment. This default data can be overwritten if there are variances. The system can display the purchase order history to show, for example, which quantities have been delivered and how much has already been invoiced.

If variances exist between the purchase order or goods receipt and the invoice, the system will issue a warning on the screen. If the variances are within the preset tolerance limits, the system will allow the invoice to be posted but will automatically block it for payment. The invoice must then be released in a separate step. If the variances are not within the tolerances, the system will not allow the invoice to be posted.

When the invoice is entered, the system also finds the relevant account. Automatic postings for sales tax, cash discount clearing, and price variances are also generated and the posting records displayed. If a balance is created, the user is required to make corrections, as an invoice can only be posted if the balance equals zero.

As soon as the invoice is posted, certain data, such as the average price of the material ordered and the purchase order history, are updated in the system.

The invoice posting completes invoice verification. The data necessary for the invoice to be paid are now contained in the system. The accounting department can retrieve the data and make the appropriate payments with the aid of the Financial Accounting component.

As a rule, an invoice refers to a transaction for which the issuing party requests payment. Invoice Verification differs depending on the type of invoice involved.

Invoices based on purchase orders: With purchase-order-based Invoice Verification, all the items of a purchase order can be settled together, regardless of whether an item has been received in several partial deliveries. All the deliveries are totaled and posted as one item.

Invoices based on goods receipt: With goods-receipt-based Invoice Verification, each individual goods receipt is invoiced separately.

Invoices without an order reference: When there is no reference to a purchase order, it is possible to post the transaction directly to a material account, a G/L account, or an asset account.




Procurement Logistics Master Data and Transaction Exercises for Flya Kite

The following discussion outlines the general flow of the exercises that will be completed in creating master data and processing procurement logistics transactions in this case. Flya Kite will be doing business with a number of vendors (suppliers) that will provide the raw materials and trade goods used and sold by the company. In order to do business with these vendors, a master record for each must be created in the system. Master vendor records can be set up basically in two ways: (1) for each individual application separately or (2) centrally. For example, a vendor master record can be created for accounting’s use. In that case, only the accounting attributes (view) of the record will be created. If another functional area of the company wants to create a particular set of data for the same vendor, that area can add its data to existing record. For example, if accounting has already set up a vendor master record (and created a vendor master number in the system), the purchasing function can access that vendor record using the vendor number and add the purchasing data (view) it required. In cases where the vendor is to be set up centrally, all data attributes for all functions will be created at one time for the vendor. In some cases a vendor will not supply goods but will provide a service such as rental space. A vendor master record for this type of vendor is set up in the same manner as the master record for a supplier of tangible goods. These services are generally purchased under some type of contractual agreement and will not involve the physical receipt of goods from the vendor. In order to purchase raw materials from vendors, there must be a raw material master record. This master record will contain all of the basic data needed to acquire the good from the vendor. A material master record must be created for each trade good that will be purchased. Raw materials are goods that will be used in production to create finished products. Trade goods are generally sold separately as independent products, but trade goods may also be used in production as component parts of a given manufactured product. In creating finished goods from raw materials, the system must have some means of recording the use of the raw materials to produce the finished goods. This requires that a master record for each finished product be created so that the physical quantities materials used and the related costs can be transferred in the system from raw materials to finished goods as the products are completed in production. When a good is to be acquired, a decision must be made to determine what vendor will supply that good. In order to save time and resources, the company may decide to always buy a particular good from the same vendor. This eliminates the need to search for vendors for that good, to obtain bids, or to work out other details of the purchase. In the case of Flya Kite, the company has decided to acquire all raw materials and trade goods from one vendor. To create the necessary linkages in the system between the goods and that vendor, there must be a purchasing info record set up. After the creation of this record, the only user decision will be to determine when and how many items are to be purchased; the system automatically determines the vendor for these items.




When the company determines the need to acquire goods, a purchasing requisition is initiated. This requisition is an internal document in that it does not leave the company. It notifies the purchasing department that something must be acquired and allows the individual who is in the position to authorize the acquisition to do so. Once the purchase requisition has been approved, the company creates a purchase order that is sent to the vendor. A purchase order is a binding offer to buy the goods listed on the purchase order, at the stated prices, and at the other conditions specified in the purchase order. This purchase order can be delivered to the vendor by mail or electronically. Upon its receipt, the vendor will pack the requested goods and deliver them to the company under the terms of the purchase order. When goods are delivered to the company as requested in the purchase order, they must be received into the company’s inventory. Only items that have been authorized to be purchased (e.g., those that have a purchase order associated with them) should be received by the company. Otherwise, unscrupulous vendors might send goods that were not ordered and then demand payment if the company had accepted delivery of the goods. This is why the purchase order to which the goods receipt applies must be input into the system at the time of the goods receipt. Only if the goods are recorded into the company’s inventory records will the various interested parties be aware that the goods have been received and can now be used. This is accomplished by completing a receiving report identifying how many items and of what type was received in reference to a specific purchase order number. Vendors that supply goods to the company have a nasty habit of wanting to be paid for those goods. In order to ensure they get paid, they send an invoice to the company outlining what is to be paid for, when, and how much. The vendor invoice will reference the original purchase order sent in order to facilitate the processing of the invoice for payment. Invoices are not paid unless the quantities, prices, and other aspects of the invoice agree with the purchase order data and also with the receiving report. Ensuring the agreement among these three is the role of purchasing logistics invoice verification. For this reason, the purchase order must be input in the invoice receipt process to establish the linkage between the purchase order and the vendor invoice. Before an invoice can be released to accounting to make a payment, the data from the purchase order, the receiving report, and the vendor invoice must be in agreement. For example, if the purchase order requested 100 items of a particular good, the receiving report indicated that 125 were received, and the vendor invoice indicated that 150 were to be paid for, the company would not wish to make this payment until these discrepancies were resolved.




CHAPTER 3: Production Logistics (PP)

The primary elements of production logistics are material requirements planning and production planning. Their main function is to guarantee material availability, that is, it is used to procure or produce the requirement quantities on time both for internal purposes and for sales and distribution. This process involves the monitoring of stocks and, in particular, the automatic creation of procurement proposals for purchasing and production. In doing so, MRP tries to strike the best balance possible between optimizing the service level and minimizing costs and capital lockup.

The type of order proposal which is automatically generated during materials planning depends on the procurement type of the material. For materials that are produced internally, a planned order is always created. For materials procured externally, the MRP controller has the choice between creating a planned order or a purchase requisition. If the MRP controller decides to create a planned order, the planned order must then be converted into a purchase requisition to make it available for use by the purchasing department.

The MRP component of R/3 assists MRP controllers in their area of responsibility. The MRP controller is responsible for all activities related to specifying the type, quantity, and time of the requirements, in addition to calculating when and for what quantity an order proposal has to be created to cover these requirements. The MRP controller needs all the information on stocks, stock reservations, and stocks on order to calculate quantities, and also needs information on lead times and procurement times to calculate dates. The MRP controller defines a suitable MRP and lot-sizing procedure for each material to determine procurement proposals.

The Demand Management component of MRP is needed to define requirement quantities and requirements dates for finished products and important assemblies. Demand Management also determines the strategy used for planning, procuring, or producing a certain finished product. Demand Management serves to determine requirement quantities and delivery dates for finished product assemblies. Customer requirements are created in sales order management. To create a demand program, Demand Management uses planned independent requirements and customer requirements. To create the demand program, the user must define the planning strategy for a product. Planning strategies represent the methods of production for planning and manufacturing or procuring a product. Using these strategies, the user can decide if production is triggered by sales orders (make-to-order production or assemble-to-order production), or if it is not triggered by sales orders (make-to-stock production). The user can designate sales orders and stock orders in the demand program. If the production time is long in relation to the standard market delivery time, the company can produce and stock the product or certain assemblies before they are needed to fill sales orders. In this case, sales quantities are planned, for example, with the aid of a sales forecast.

The make-to-stock strategy is appropriate if the materials are not segregated (i.e., not assigned to specific sales orders) and costs need to be tracked at material level, not at sales order level. Make-to-stock production should be used if stock is to be produced independently




of orders so that customers can be immediately provided with goods from that stock at a later time. The company may even want to produce goods without related sales orders if there is an expectation of future customer demand. This means that make-to-stock strategies can support a very close customer-vendor relationship because the objective here is to provide customers with goods from stock as quickly as possible. In a make-to-stock environment, smoothing of production can be an important feature. This means irregular requirements flow resulting from different customer requirements quantities can be smoothed and simply produced to stock.

Make-to-stock strategies are usually combined with a lot-size key or a rounding value. For instance, it may be desirable to produce the entire amount for the whole month once a month only, or to produce full pallets only. No specific product structures are required for make-to-stock strategies. In other words, the material may or may not have a BOM. The material can be produced in-house or procured externally.

In make-to-order production, a product is produced specifically for an individual sales order. It is a process in which a product is individually manufactured for a particular customer. In contrast to mass production for an unspecified market where a material is manufactured many times, make-to-order production creates a material only once though the same or a similar production process that might be repeated at a later time. In companies using make-to-order production, the demand program only determines the production area in which various variant types are produced. Orders are taken as they come. Each product is specifically produced for an individual customer so that the finished product is rarely placed in stock. The graphic below illustrates this process.

The sales order quantities are planned for production using the sales order number. The quantities produced for the individual sales orders cannot be changed. Each quantity is maintained specifically for the individual sales order. The production and procurement costs are maintained for each sales order in either a settlement order or in a project at sales order item level. This ensures a detailed analysis of the planned and actual costs.

An assemble-to-order environment is one in which the product or service is assembled on receipt of the sales order; key components are planned or stocked in anticipation of sales




orders. Receipt of a sales order initiates the assembly of the customized product. Assemble-to-order is useful where a large number of finished products can be assembled from common components. In the R/3 System, assemble-to-order is a special type of make-to-order planning strategy. If an assemble-to-order strategy is used, material and resource availability is checked at the moment when the sales order is created. The company can quote reliable delivery dates to customers because it is known whether the desired quantity will be available on the desired date. If the complete quantity cannot be committed, the system specifies when the total quantity will be available and whether a partial quantity can be committed at an alternative date.

An important factor for ensuring that customers are provided with reliable due dates is continuous feedback between sales and production. In the R/3 System, changes to quantities or dates for production or procurement of components are passed back to the sales order of the finished product where the committed quantity or confirmation date is also changed. Similarly, changes to quantities or dates in the sales order are passed on to production and/or procurement.

Master Data in Production Logistics

The Production Planning application component provides a solution for both the production plan (type and quantity of the products) and the production process. Preparations for production include the procurement, storage, and transportation of materials and intermediate products. Integral to that process are the MRP views of master materials, bills of material, routings, and work center master data records.

MRP VIEWS FOR MATERIAL MASTER RECORDS: MRP views for material master records set up the data necessary for materials requirements planning and production planning within the raw materials and finished products master records that generally have been created in the Procurement Logistics process.2

BILLS OF MATERIALS: Bills of material (BOMs) and routings contain essential master data for integrated materials management and production control. In the design department, a new product is designed to be suitable for production and for its intended purpose. The result of this product phase is drawings and a list of all the parts required to produce the product. This list is the bill of material.

A bill of material is defined as a complete, formally structured list of the components that make up a product or assembly. The list contains the object number of each component, together with the quantity and unit of measure. A bill of material can only refer to a quantity of at least 1 of an object.

The graphic below shows some components of a bicycle that are included in a BOM.

2 For a full discussion of material master records, see Procurement Logistics.




Bills of material are used in their different forms in various situations where a finished product is assembled from several component parts or materials. Depending on the industry sector, they may also be called recipes or lists of ingredients. The structure of the product determines whether the bill of material is simple or very complex.

ROUTINGS: A routing is a description of which operations (process steps) that must be carried out and in which order to produce a material (product). A routing contains information about the operations and the order in which they are carried out, details about the work centers at which they are carried out, and the required production resources and tools (includes jigs and fixtures) to be used. Standard values for the execution of individual operations are also saved in routings.

A routing is used as a source for creating a production order or a run schedule header by copying. It is composed of a header and one or more sequences. The header contains data that is valid for the whole routing. A sequence is a series of operations. Operations describe individual process steps, which are carried out during production (see Routing graphic below).

Routing

Before a material can be produced with a routing, the material must be assigned to the routing. The routing and the material can exist in different plants. If a bill of material (BOM) has been assigned to a routing, its components can be assigned to the individual routing operations. In general the BOM assigned to a routing is the material BOM for the material to be produced by the routing (see Assignment of Materials graphic that follows).




Assignment of Materials to be Produced and Material Components

WORK CENTERS: Operations are carried out at a work center. In the R/3 System work centers are business objects that can represent the following real work centers, for example:

Machines, machine groups Production lines Assembly work centers Employees, groups of employees

Together with bills of material and routings, work centers belong to the most important master data in the R/3 production planning and control system. Work centers are used in task list operations and work orders. Task lists are for example routings, maintenance task lists, inspection plans, and standard networks.

Data in work centers are used for: Scheduling - Operating times and formulas are entered in the work center, so that the

duration of an operation can be calculated. Costing - Formulas are entered in the work center, so that the costs of an operation

can be calculated. A work center is also assigned to a cost center. Capacity planning - The available capacity and formulas for calculating capacity

requirements are entered in the work center. Simplifying operation maintenance - Various default values for operations can be

entered in the work center.

The following graphic illustrates the use of work center data.




A work center is created for a plant and is identified by a key. The work center category, which is defined in customizing the work center, determines which data can be maintained in the work center. The data are grouped thematically together in screens and screen groups. Examples of such screen or screen groups are:

Basic Data Assignments (to cost centers, Human Resource Management System (HR)) Capacities Scheduling Default values Hierarchy Technical data

Work centers are assigned to operations in task lists. If default values in a work center are changed, the changes are effective in the task list if a reference indicator has been set for the default value. Work centers can be arranged in hierarchies. These are important in capacity planning. Hierarchies are used to cumulate available capacities and capacity requirements in a hierarchy work center.

A Logistics work center can be assigned to either an organizational unit or a work center in the Human Resource Management System (HRMS). Assignments to other HR-objects such as employees, qualifications, or specifications can be maintained using the HR work center.

Production Planning

In the case of in-house production, the system always creates planned orders. These planned orders are used to plan production quantities. Once the MRP controller is satisfied with the results of planning, these planned orders are converted into production orders and passed on to production. Production orders are fixed elements, which must be followed.

In the case of external procurement, the system creates either planned orders or directly creates purchase requisitions. Procurement proposals for external procurement plan the external procurement quantity. Once the MRP controller is satisfied with the results of planning, the planned orders are converted into purchase requisitions or the purchase requisitions are converted into purchase orders and passed on to the purchasing department. Purchase orders are also fixed elements, which must be followed.

If a planned order in external procurement is created first, the MRP controller has more control over the procurement proposals. Only when the MRP controller has checked the planned orders and converted them into purchase requisitions can the purchasing department order the material. Otherwise, the purchase requisition is immediately available to the purchasing department, which then takes over responsibility for material availability and warehouse stocks. The creation indicator for purchase requisitions in the initial screen of the planning run controls whether the system is to create purchase requisitions immediately or whether it is to create planned orders first.




If a scheduling agreement3 exists for a material and if an entry exists in the source list that is relevant to MRP, the user can also instruct the system to create delivery schedules in the planning run.

A planned order is sent to a plant and is an MRP request for the procurement of a particular material at a determined time. It specifies when the inward material movement should be made and the quantity of material that is expected.

A planned order has the following characteristics: It is a procurement proposal in MRP for requirements coverage, that is, an internal

planning element. It is not binding and does not trigger procurement directly; it serves for planning purposes only.

It can be changed or deleted at any time (exceptions: planned orders for direct production and for direct procurement).

Whether a material will later be produced in-house or procured externally is left open. For materials produced in-house, it represents the pegged requirement for dependent

requirements and can be used in the capacity calculation. For materials produced in-house, it specifies the basic dates for production.

Planned orders are converted into production orders for in-house production and into purchase requisitions for external procurement. In contrast to planned orders, production orders and purchase requisitions are fixed receipt elements, which commit to the procurement.

Automatic Creation of Planned Orders

During the MRP planning run, the system automatically calculates the materials to be procured as well as the requirements quantity and date. The system then creates the corresponding planned order.

The system also explodes the BOM for materials that are produced in-house and uses the BOM components as material components for the planned order. The system creates a corresponding dependent requirement for these components. If the quantity or the date of the planned order changes or if the bill of material changes, the bill of material is re-exploded in the next planning run and the dependent requirements of the material components are adjusted accordingly.

When the MRP system is executed, the system produces an MRP list which provides an overview of the results of the run. Any changes that have occurred between planning runs are ignored on this list. In addition, the system creates a stock/requirements list that displays all changes in stock, receipts and issues which have currently occurred. By using the MRP list and stock/requirements list comparison these two evaluations can be compared. This

3 Outline agreement on the basis of which materials are procured at a series of predefined points in time over a

certain period.




means that the user can compare the situation at the last planning run to the current stock/requirements situation.

Manual Creation of Planned Orders

Planned orders can also be created manually. For this, the material to be procured must be determined along with the quantity to be procured, the date it should be available, and whether it is to be procured externally or internally. If a planned order is created or changed manually, the user can also explode the BOM manually and adjust the material components.

The planned order consists of the following: Order data (quantities, dates, account assignment, material data, procurement data,

etc.), and Component overview.

Conversion of Planned Orders to Production Orders

Planned orders are created in material requirements planning to meet production requirements. Planned orders represent a demand to procure or produce a material. Planned orders for materials that are to be produced in-house are converted to production orders. The material components required for production are contained as items in the planned order and are copied directly when the planned order is converted to a production order.

Planned orders are internal planning elements for planning purposes and do not trigger any procurements. The system only triggers procurement, once planned orders are converted into fixed receipt elements such as purchase requisitions or production orders. Planned orders can be converted individually (one at a time) or collectively (several simultaneously).

For materials that are to be produced in-house, the planned order is converted into a production order. Production orders are a fundamental part of Production Planning and Control (PP). PP is fully integrated in the Logistics (LO) component and has, among others, interfaces to:

Sales and Distribution (SD) Materials Management (MM) Controlling (CO)

A production order defines the material to be processed, the location, the time, and how much work is required. It also defines which resources are to be used and how the order costs are to be settled. As soon as a planned order or a company-internal requirement is generated from previous planning levels (material requirements planning), shop floor control takes over the information available and adds the order-relevant data to guarantee complete order processing. Production orders are used to control production within a company and also to control cost accounting.

The production order can be used to specify: What is to be produced




When production is to take place Which capacity is to process the order How much production costs

Production orders can be generated in the following ways: From a requirement generated in requirements planning (i.e., conversion of a planned

order to a production order) Using an assembly order Without any previous requirement, that is, by creating it manually

When a production order is created the following actions are carried out:

A routing is selected and its operations and sequences are transferred to the order The bill of materials is exploded and the items in the bill of material are transferred to

the order Reservations4 are generated for bill of material items held in stock The planned costs for the order are generated The capacity requirements5 are generated for the work centers Purchase requisitions are generated for non-stock items and externally-processed

operations

A production order specifies which material is to be produced, where it is to be produced, which operations are required, and on which date production is to take place. It also defines how the order costs are to be settled.

As described in this procedure, production orders can be created manually without being previously requested. Alternatively, they can be automatically created by converting a planned order. During requirements planning (MRP run), planned orders are created at every BOM level to cover requirements. For materials produced in-house, a secondary requirement is also generated when the BOM is exploded, which is necessary for producing the end

4 A reservation is a request to the warehouse or stores to keep a material ready for issue at a future date for a

certain purpose. The purpose of a reservation is to ensure that a material is available when required. A material can be reserved for a cost center, an asset, or an order for example. 5 Capacity requirements specify how much capacity output is required for individual orders at a specific time.




product or assembly. For externally produced materials, an ordering transaction is initiated when a purchase requisition is generated.

Planned orders generated in the MRP run can be converted individually into production orders from the current stock/requirements list. Planned orders can also be grouped together by the MRP run and converted into production orders together. These production orders can be released together. In a partial conversion, a planned order is reduced in partial quantities into several production orders. Partial conversion is described separately.

If, when converting the planned order, changes are made to the required quantity or if the basic finish date is changed, then a planning file entry is generated. When material requirements planning is executed again, the material and its components are planned again.

The material components required for production are contained as items in the planned order and are copied directly when the planned order is converted to a production order. The BOM is not exploded again. On conversion, the secondary requirements for the components are converted to reservations. The operation data and production resource/tool data are copied as usual from the routing for the material to be produced.

Preliminary Costing

When a production order is created and after each subsequent change to the order, the system calculates the planned order costs expected to be incurred during production. The planned costs are assigned to cost elements. Those cost elements are primary costs and secondary costs. Primary costs (material costs and costs for external procurement/external processing) are assigned to the order, for example, via primary costs, such as material withdrawals or the purchasing of externally processed parts. Secondary costs (production costs, material overhead costs, and production overhead costs) are allocated to the order via internal cost allocation. When a production order is settled (after the production is completed), the actual costs incurred for the order are settled to one or more receiver cost-objects (for example, to the account for the material produced or to a sales order). Offsetting entries are generated automatically to credit the production order. If the costs for the production order are settled to a material account, the order is credited each time material is delivered to stock. The material stock account is debited accordingly. If the costs for the production order are settled to another receiver (for example to a sales order), the production order is credited automatically at the time of settlement. The cost-objects (material account or sales order) are debited accordingly. The debit posting remains in the order and can be displayed even after the costs have been settled. The settled costs are updated in the corresponding receiver cost-object and can be displayed in reporting.

Scheduling

The plant activities involved in the production of materials must be scheduled to meet the promised delivery times and to optimize the production resources of the plant. In scheduling,




the system calculates the start and finish dates of orders or of operations within an order. The time of an operation can be divided into the queue time, setup time, processing time, teardown time, and wait time. In addition to these operation segments, a move time can be defined in the system. The move time is the time needed to move a material from one work center to the next one. Move time is always between two operations and is assigned to the preceding operation. These times along with the required delivery date, the available capacity in the plant, and the raw materials availability dates are used to determine when the actual production will begin and be completed.

Scheduling can be order-related or non order-related:

Order-related scheduling is carried out for planned orders. Planned orders can be scheduled using the in-house production time in a material master record and the routing. The determined dates are saved.

Non order-related scheduling is carried out using routings. This type of scheduling can be used to calculate the in-house production time of a material and compare it to the lot size-independent in-house production time from the material master record. The lot size-independent in-house production time from the material master record can then be automatically or manually adjusted.

Completion of Production

When the production of the order is completed, a completion confirmation is entered into the system to confirm both the completion of the order and the quantity of materials produced. In order to track the movement of the completed goods from production into, for example, the warehouse and also into finished goods inventory, a goods receipt is posted. This automatically creates a material document which serves as proof of the goods movement. Parallel to the creation of the material document, the system creates an accounting document that contains the posting lines to record the movement of the cost of the goods from production to finished goods inventory.

Factory Calendar

The SAP system contains a calendar in which working days are numbered sequentially. The factory calendar is defined on the basis of a public holiday calendar. The validity period of a factory calendar must be within the validity period of the public holiday calendar. The weekdays that are working days must also be specified in this calendar.

Examples: Monday through Friday are working days. Saturday, Sunday and public holidays are non-working days.

The system will not allow production orders to be released on non-work days or on holidays. For the Flya Kite case, where users may be working on weekends and holidays, the system has been configured with a special factory calendar that ignores these non-working days so that the exercises can be completed at any time.




Production Logistics Master Data and Transaction Exercises for Flya Kite

The following discussion outlines the general flow of the exercises that will be completed in creating master data and processing production logistics transactions in this case. Before raw materials can be used in the materials requirement planning process, the MRP view of the material must exist as part of the material master record. If these views have not already been created within the master record, they must be created before production logistics can process the materials. Adding these MRP views is necessary for raw materials, for trade goods that may be used in production, and for the finished goods that will be produced. A bill of material must exist identifying what components are necessary to build a particular product. This must be created along with a routing in order to identify the processing steps to be performed during the production process. Once the bill of material and routing are created and components assigned, the MRP system is executed to plan the availability and requirements for the actual manufacture of kites. A stock requirements list can be displayed in order to view the results of the planning run. Once the planned order is completed, it can be converted to a production order. However, the planned order can be changed at any time before it is converted to a production order. For example, the number of kites to be produced can be increased. Once the conversion takes place, the planned order is changed into a production order that is scheduled for actual production. As production takes place, the materials to produce the kites must be moved from storage locations to the production line. The specific materials for the specific order are “issued” both physically and in the records by a goods issue referencing the production order number. When production is completed, the system must be “informed” that the work is complete. This is done through a completion confirmation specifying the actual yield of product (i.e., number of kites produced) from the manufacturing process. The kites produced by the completed production order must be transferred from production into inventory (both physically and in the system for record keeping). This is done through the use of a goods receipt with a movement type code of production order to warehouse indicating the storage location (in this case shipping) to where the finished products are to be moved. This is done for finished products that will be immediately shipped to customers. If the finished goods are not to be shipped to fill a specific order, the storage location is the warehouse rather than shipping.

OONNCCEE TTHHEE PPRROODDUUCCTTIIOONN AANNDD VVAARRIIOOUUSS MMOOVVEEMMEENNTTSS OOFF TTHHEE KKIITTEESS PPRROODDUUCCEEDD BBYY

TTHHIISS PPRROODDUUCCTTIIOONN OORRDDEERR AARREE CCOOMMPPLLEETTEEDD,, IITT IISS TTIIMMEE TTOO SSEETTTTLLEE TTHHEE CCOOSSTTSS TTOO

PPRROODDUUCCEE TTHHEE KKIITTEESS TTOO TTHHEE OORRDDEERR.. AAFFTTEERR TTHHIISS SSEETTTTLLEEMMEENNTT IISS EEXXEECCUUTTEEDD,, AA

RREEPPOORRTT IINNDDIICCAATTIINNGG TTHHEE AACCTTUUAALL//PPLLAANN//VVAARRIIAANNCCEE AAMMOOUUNNTTSS CCAANN BBEE VVIIEEWWEEDD

FFOORR TTHHEE OORRDDEERR..




CHAPTER 4: Sales Logistics (SD)

Sales logistics is the business process through which an entity secures and processes orders from customers (sales order processing), initiates the delivery of products or the provision of services (outbound logistics), and bills the customer for products shipped or services rendered (billing). In SAP this process is located in the Sales and Distribution (SD) module. In order to carry out the sales logistics process, SD must access data on customers, be integrated with Materials Management (MM) in order to establish product delivery, and be integrated with Financial Accounting (FI) in order to provide data on receivables due from billings generated. The graphic below illustrates the various steps and interactions necessary in the SD process.

Organizational Structure in Sales Logistics In SD there are certain organizational structure elements that are required to carry out the sales logistics process. The primary element is a sales organization. A sales organization is responsible for the sale and distribution of goods and services. It represents the selling unit as a legal entity. It is responsible for product guarantees and other rights to recourse. A sales organization must be created in the structure of a company code in order to carry out SD transaction processing. A sales organization can be subdivided into several distribution chains which determine the responsibility for an organizational element defined as a distribution channel. The distribution channel represents the channel through which salable materials or services reach customers. Typical distribution channels include wholesale, retail and direct sales. Within a sales organization a customer can be supplied through several distribution channels. In




addition, the material master data relevant for sales, such as prices, minimum order quantity, minimum quantity to be delivered and delivering plant, can differ for each sales organization and distribution channel.

Several divisions can be assigned to a sales organization which is responsible for the materials or services provided. In the SAP R/3 System you can define a division-specific sales organization. For example, a kite company may wish to have a “standard” division that sells consumer kites and a “competitive” division that sells competitive graded kites. Product groups (i.e., divisions) can be defined for a wide-ranging spectrum of products. For every division you can make customer-specific agreements on, for example, partial deliveries, pricing and terms of payment. Within a division you can carry out statistical analyses or set up separate marketing procedures.

The graphic below illustrates the relationships between sales organization, distribution channel, and division

A given sale would be processed by the sales organization through one of the distribution channels and through one of the divisions within that distribution channel. This would allow performance to be specifically tracked, for example, of the sales of competitive grade kites through the wholesale distribution channel. A particular linkage between a sales organization, a distribution channel, and a division is described, for statistical analysis purposes, as a sales area in SAP.

Company Code

Flya Kite

Distribution Channel:

Retail

Flya Kite Sales

Organization

Standard

Division

Competitive

Division

Distribution Channel:

Wholesale

Competitive

Division

Standard

Division




An additional organizational relationship must be created between the sales organization and one or more company plants. A plant is a place where either materials are produced, or goods and services are provided. As a retail or wholesale site, it makes merchandise available for distribution and sale. It can be subdivided into storage locations, allowing stocks of materials to be broken down according to predefined criteria (for example, location and materials planning aspects). Linking a sales organization to one or more plants is logical because the plant is the location from where the products being sold come. When there is only one plant producing one product line, the situation is obvious. However, consider a toy company with multiple plants that produce many product lines (e.g., kites, bicycles, baseball bats, etc.). If a given sales organization sold one or more of these product lines it would, therefore, have to be linked to the appropriate plant as a product source.

In order to process the delivery or shipment of products in SD, independent organizational entities defined as shipping points are created which are responsible for scheduling and processing deliveries to customers, as well as replenishment deliveries to the company’s own warehouses. A delivery is always carried out by one shipping point only. The shipping point depends on the following criteria:

Delivering plant Type of shipping (for example, train, truck) Loading equipment necessary

Master Data in Sales Logistics

A number of master data records must be created in order to permit processing of transactions with the sales logistics process. These records include the customer master data, product or material data from the SD view, and sales prices for products.

CUSTOMER MASTER RECORD: Data on customers6 is important for both sales and distribution logistics and the accounting/controlling support function. In order to avoid data redundancy, accounting data and sales and distribution data are stored in one master record, the customer master record. A customer master record is created for customers with whom the company has business contacts. This master record contains all data necessary for processing the business transactions. A customer master record contains all data needed for business transactions and correspondence with the customer. This includes address data, shipping data, sales data, and data for invoice creation. Maintaining the master data correctly can greatly reduce the work needed to process transactions. This is because the master data are automatically copied into the transactions.

General data, company code data, and sales and distribution data are stored separately in the customer master record.

General data are maintained for every customer, such as name, address and telephone number, communication, etc. These data are identifiable only via the customer number, not via the number of the company code or the sales area.

6 Customers are sometimes referred to in SAP as business partners. Other business partners are vendors

and employees.




Maintaining the data is possible from both the accounting view and the sales and distribution view.

Company code data are only of interest for the accounting/controlling function. It includes, for example, information on insurance or account management. This data applies to only one company code.

Sales and distribution data are only of interest for the sales and distribution department. It includes, for example, data on pricing or shipping. This data only applies to one sales area, and therefore is dependent on the sales structure (sales organization, distribution channel, division).

Only after entering the sales and distribution data for a customer can you process sales and distribution transactions for the customer (for example, a sales order). Also, you can only send an invoice to the customer if the data on the payer has been maintained from the financial accounting view.

A customer business partner can be a natural or legal person who is directly involved in a business transaction with you. The following partner functions are defined in the system:

Sold-to party - Person or company that places an order for goods or services. The sold-to party can also perform the functions of the payer, bill-to party or ship-to party. For the sold-to party, data on sales is necessary (for example, the assignment to a sales office or to a valid price list). In most cases, the company which places an order for the delivery of goods or the rendering of services is at the same time ship-to party, payer and bill-to party. For this reason in the SAP R/3 System the function sold-to party includes all these other functions.

Ship-to party - Person or company that receives the goods. The ship-to party is not necessarily the sold-to party, the bill-to party or the payer. For the ship-to party only data required for shipping is necessary (for example, unloading point and goods receiving hours).

Bill-to party Person or company that receives the invoice for a delivery or service. The bill-to party is not necessarily the payer who settles the bill. For the bill-to party you need the address, data on output and possibly data on electronic communication.

Payer - Person or company that settles the bill. The payer is not necessarily the bill-to party. A payer is a company or person who settles the invoices for delivered goods or rendered services. For the payer, data on billing schedules and bank data are necessary.

If a customer fulfills all functions at the same time, only one master record is necessary, in which all data required for these functions is entered. In this case you create a master record for the sold-to party.

If the functions are divided among different companies, a corresponding number of master records is needed. In one master record you enter, for example, the address of the sold-to party for correspondence, in another one the address of the ship-to party for the delivery. Only in the customer master record of the sold-to party is a link between the individual partners established, and this is done by entering the customer number of the respective partners.




Materials with the same basic attributes are grouped together and assigned to a material type. The material types primarily involved in SD are trading goods, finished products, services, and packaging material. The material type represents certain features of materials in the system, and has important control functions: the material type is used, among other things, to group field selection functions for a material, or to define the screen sequence, the type of number assignment and number ranges during material master record maintenance. Depending on the material type, company areas maintain different data screens. This screen selection applying specifically to an application is called a "view".

Trading goods are movable goods intended for commercial exchange. Trading goods are always bought and re-sold by the company. The material master record for trading goods, therefore, always contains purchasing data and sales data. Finished products are goods that are produced in-house by the company in the manufacturing process. These goods are created from raw materials through the production logistics process. Services are represented and managed in the SAP System as materials. Services are non-material goods that differ from other goods, particularly in that their production and consumption coincide. Services are generally regarded as non-transportable and non-stockable. Typical services are commercial services, transport services, bank and insurance services, goods from cultural organizations and the mass media, as well as services provided by the public security forces or the education and health sectors. Since services cannot be stored, a material master record of this material type does not contain inventory data or inventory management data. No fields for gross weight, net weight or unit of weight are included in the basic data for a service, as are for other material types. Packaging material includes all materials needed for packaging, for example, boxes or crates.

All data and information entered for a material is stored in the data structure of the material master record. For sales and distribution, general data and sales and distribution data in the material master record are relevant. General data in a material master record is identical for every sales organization, plant and storage location. General data contains, for example, the material number that identifies it, the material description, units of measure, value, weight, volume and divisions. Sales and distribution data in a material master record is defined for a specific sales organization and distribution channel. The delivering plant, the assignment to the sales group, grouping terms for price agreements and sales texts, for example, are included in sales and distribution data. The fact that a material is linked to a distribution channel allows the material to be sold with different conditions through the various distribution channels.

Sales and distribution data are divided into data that depend on the sales organization and data that depend on the plant. Sales organization/distribution channel data includes the delivering plant, the sales unit, the minimum order quantity and the minimum delivery quantity. Plant data applies to a plant and all its storage locations. Examples of plant data are Material Requirements Planning (MRP) data, such as the safety stock quantity, the reorder level, or the shipping processing time.

A material can be stored, transported and sold in various units of measure. In the SAP R/3 System, you can therefore define various units of measure which are maintained in the sales and distribution screens. However, you only need to maintain the fields of the units of measure if they deviate from the base unit of measure. If no other fields with units of measure




are maintained, the system automatically takes the base unit of measure as a basis for its calculations. Stocks of a material are managed in the base unit of measure. All quantity movements in other units of measure are converted automatically by the system into the base unit of measure. As soon as units of measures other than the base unit of measure are used in a material master record, the system prompts you in a dialog box to enter a calculation factor to the base unit of measure, the so-called alternative unit of measure. Several alternative units of measure can be defined. If, for example, a product is managed in the base unit of measure "Piece" but is sold in the sales unit "Box", you must define the conversion factor. The alternative unit of measure can define, for example, that 1 box of this material contains 12 pieces. The unit of measure in which materials are sold is referred to as a sales unit (for example, piece or bottle). The delivery unit refers to the unit in which materials can be delivered. Only exact multiples of the delivery unit can be delivered. For example, with a delivery unit of 30 bottles, 30, 60 or 90 bottles can be delivered, but not 100 bottles.

In sales logistics two different quantity specifications are used: the minimum order quantity and the minimum delivery quantity. The minimum order quantity refers to the minimum quantity the customer must order. A warning message appears if the minimum order quantity is not reached during order entry. The order can be entered in spite of the warning message. The minimum delivery quantity refers to the minimum quantity you must deliver to the customer. The minimum delivery quantity is automatically checked during delivery processing. A warning message appears during delivery processing if you enter a delivery quantity lower than the minimum delivery quantity. The delivery can be created in spite of this warning message.

In a company that has multiple plants, the delivering plant refers to the plant from which the goods are to be delivered to the customer, within a specific sales organization and distribution channel. The plant can be automatically proposed by the system when processing a sales order, if it has been maintained in one of the master records.

In order to better serve customers, a customer material information record can be created. The data in this record includes the customer-specific material number, the customer-specific material description, and customer-specific data on deliveries and delivery tolerances. If, for example, one of your customers uses a number for a material, which differs from the number your company uses to identify it, you can store the material number used by the customer in the customer material information record. During order entry, items can be entered by specifying the material number used by the customer. The system will then relate the customer’s material number to the material number used in your company for that product and access all of the pertinent data for that material.

SALES PRICES: Sales prices are the amounts that customers will pay for the materials or products sold to them without any consideration of discounts. Sales prices are defined by sales organization and distribution channel. For example, sales prices for the retail distribution channel would not be the same as those for the wholesale distribution channel. Prices must be related, of course, to each specific trade good or finished product that will be sold to customers. In some cases, however, a specific customer may receive a special price known as a customer specific material price. Transactions with that particular customer will use these specific sales prices rather than the general prices charged to others. In many




sales transactions, the company will offer a customer a discount based on any number of criteria. The customer discount is established by sales organization and distribution channel. In many cases the discount is a percentage based on the total order value.

Sales Logistics Transaction Processing

Although there are many variations, the basic process involved with sales transactions is to obtain information from a customer that desires to purchase a product, approve the sale to the customer, process the data within the company to locate/obtain/manufacture the product, deliver the product to the customer, and bill the customer for the order. For the purposes of this case, the flow of activities in this process will involve an inquiry from a customer, creation/processing of a sales order to fulfill that inquiry, deliver the material ordered, and bill the customer.

A customer inquiry is a customer’s request to a company that they provide a quotation or sales information without obligation thereby representing actually a request for a quotation. An inquiry can relate to materials or services, conditions and, if necessary, delivery dates. The sales area that accepts the inquiry becomes responsible for further processing. The inquiry contains one or more items that contain the quantity of a material or service that the customer asked for. The inquiry usually also includes a desired delivery date. When processing the inquiry, the availability of the desired product is checked to determine when it can be promised for delivery. The response to the inquiry is valid for a specific period of time (as set up when processing the inquiry). In processing the inquiry, the system accesses both the customer master record and the material master record for related sales data.

In cases where there are frequently occurring material combinations and common delivery quantities associated with customer orders, data can be stored as an item proposal. This proposal forms a “template” that can be used when customers place orders that meet the established material combinations and delivery quantities. The order entry can be processed more efficiently using item proposals when an order is placed by a customer. An item proposal, containing the materials a customer usually orders, can be assigned to that customer. When using item proposals in the sales document, this item proposal is then proposed for selection.

A sales order is created in the SAP system when a customer places an order, either independently or with reference to a preceding document such as an inquiry. If it is created with reference to a preceding document, the initial data are copied into the sales order. A sales order is a contractual agreement between a sales organization and a customer to supply materials or services in certain quantities. Sales orders can be processed in the SAP R/3 System differently, depending on your specific needs. In the simplest case, you can enter a sales order with several items in a single screen. The system automatically proposes data from the relevant master records:

From the customer master record of the sold-to party, the system proposes sales, shipping, pricing, and billing data. In addition, the system copies customer-specific master data about texts, partners, and contact people at the customer site.

For each material in the sales order, the system automatically proposes data from the relevant material master records, such as data for pricing, delivery scheduling, availability check, tax determination, and weight and volume determination.




The data proposed by the system can be used as a basis for the order. If the sales order processing requires it, you can modify this data manually or add new data. For example, your pricing policy may allow you to manually change the value of certain discounts within a permitted range. In addition, you can branch in the sales order to a number of different screens where you can display and modify data, such as terms of payment and delivery data.

In the sales order, functions such as pricing and printouts are available. The system checks whether the material is available for the requested delivery date and if necessary, transfers the requirements to materials planning. Shipping deadlines and shipping points are determined in delivery scheduling. If the system is so configured, a check of credit limits for the customer can be performed at the time the sales order is created.

When you enter a sales order, you can only confirm the delivery of the goods for the required delivery date if the goods are available for all the necessary processing activities which take place before delivery. To meet that date the shipping department must ensure that freight forwarding or another shipping company is advised early enough so that sufficient time remains for packing and loading to be carried out. In addition, the procurement department must ensure that the production and purchasing departments are advised of inadequate stock quantities so that goods can either be produced punctually or ordered. Sales transfers the information on materials ordered as requirements to material requirements planning (MRP). Requirements are planned outward movements of stock. The transfer of requirements informs production that goods must be produced, or advises purchasing that purchase requisitions have been created for which purchase orders must be created and sent to the suppliers.

A sales order can also be created under the provisions of a customer scheduling agreement. A customer scheduling agreement is an outline agreement with a given customer containing delivery quantities and dates. These are then entered as schedule lines in a delivery schedule. You can either create schedule lines when you create the scheduling agreement or you can create them later. You fulfill a scheduling agreement by creating the deliveries in the schedule as they become due on the transportation scheduling date. The system determines from this date when transport activities must be started to ensure that the requested delivery date is met. You process deliveries for a scheduling agreement in exactly the same way as you process a normal delivery. After you have carried out the delivery, the system updates the Delivered quantity field in the scheduling agreement item with the delivery quantity.

As soon as the material availability date or the transportation scheduling date for a schedule line is reached, the schedule line becomes due for shipping. When you create an outbound delivery, you initiate shipping activities such as picking, packing, and transportation scheduling. A delivery is processed through one shipping point. Which shipping point carries out the processing for a delivery can be determined automatically during order processing or you can specify it manually in the order. The system carries out the following activities when an outbound delivery is created:

Checks the order and materials to make sure the outbound delivery is possible (for example, it checks for delivery blocks or incompleteness)

Determines the delivery quantity of an item and checks the availability of the material Calculates the weight and volume of the delivery




Calculates work expenditure Packs the outbound delivery according to the reference order Checks the delivery situation of the order and any partial delivery agreements Redetermines the route Adds information relevant for export Checks delivery scheduling and changes deadlines (if necessary) Assigns a picking location Carries out batch determination (if material is to be handled in batches) Creates an inspection lot if the material must pass a quality check Updates sales order data and changes order status

You can make changes in a delivery after it is created if the delivery situation changes in any way. In addition, you can confirm picked quantities using the change function, or use the display function to access shipping information in a delivery. Order items or schedule lines that have identical shipping criteria are combined in one delivery. If data varies between items, for example, if a different ship-to party is defined for each item, two deliveries must be created for the order. Order items from different orders can be grouped together in one delivery provided that they have identical shipping criteria and that the sold-to party agrees.

During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept.

The picking process involves taking goods from a storage location and staging the right quantity in a picking area where the goods will be prepared for shipping. Regardless of how your company executes the picking process, you can make settings in the system so that picking is carried out as follows.

Automatically Routinely at certain times Manually according to overviews of the day's workload that an employee has

requested.

A picking status is recorded in each delivery item for the purpose of scheduling and monitoring the picking process. This status indicates where the item is in the picking procedure (picking has started for item A, for instance).

In the system standard settings, it is a prerequisite for goods issue7 to be posted before the item relevant for picking can be picked completely. Therefore, delivery quantity and picking quantity (picked quantity) in the outbound delivery must be equal. Depending on the picking procedure being used, you can either determine delivery-relevant data before picking or wait until after picking is completed to record it. Delivery-relevant data may be made up of the following:

7 A goods issue is a term used in inventory management to describe a reduction in warehouse stock due, for instance, to a

withdrawal of stock or the delivery of goods to a customer.




Which batches a material is picked from

Which serial numbers are picked

Which valuation types the stock is taken from

Packing is part of delivery and shipment processing. When you process a delivery, you can select delivery items for packing and assign them to handling units (HUs). As an example, you could pack delivery items in boxes, pack the boxes on pallets for delivery to the customer, and load the pallets onto a truck.

A goods issue is created when the goods are transferred to the carrier for actual shipment to the customer. This is the point at which the sale can be recognized (if shipping terms are FOB shipping point). A goods issue has the following results in the system:

Material document is created Accounting document is created Stock is updated G/L accounts are updated Consumption is updated Reservation is updated Order is updated

When you post a goods issue, the system automatically creates a material document which serves as proof of the goods movement. Parallel to the material document, an accounting document is created. The accounting document contains the posting lines (for the corresponding accounts) that are necessary for the movement. The following stocks are reduced by the issued quantity: total valuated stock; unrestricted-use stock; reserved stock if the goods issue is entered with reference to a reservation or an order. When the goods issue is posted, the system automatically creates posting lines on the accounts of the accounting system. In addition to causing an inventory update in the material master record, a goods issue posting causes an update of the consumption statistics if the material is planned with MRP. If the withdrawal is unplanned, both total consumption and unplanned consumption are updated. With a goods issue that references a reservation or a sales order, the quantity withdrawn is updated in the reservation item. The reservation item is completed when the total reservation quantity has been withdrawn or when the final issue indicator is set manually at goods issue. In the case of a goods issue with reference to an order, the quantities withdrawn for the components are updated in the order.

Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing. During billing, you can decide whether you want to create an invoice for every delivery, or whether you want to send the customer an invoice every month. The billing process is integrated with the accounting/controlling support process. When you create a billing document, the system automatically creates all relevant accounting documents for:

o General Ledger o Profit center o Profitability Analysis o Cost Accounting o Accounting




The billing integration with financial accounting consists of forwarding billing data in invoices, credit and debit memos to Financial Accounting. The system

posts offsetting entries to the appropriate accounts (with the help of "account assignment"), and

makes sure that FI can recognize all billing documents belonging to one business transaction (for example, a credit memo to an invoice).

The integration with controlling consists of assigning costs and revenues to the appropriate sub-ledgers. One feature of sales logistics processing in the SAP R/3 SD module is the document flow display. The document flow shows how far the sales document has been processed and creates a business transaction out of consecutive documents in the system. For example, a document flow could contain an inquiry, a sales order, delivery, the good issue, the invoice, and the accounting document for the journal entry to record the sale. The document flow indicates the number of each document, the date initiated or completed, and the current processing status of the particular processing step. If you displayed the document flow from the sales order, the inquiry would be a preceding document and the delivery and invoice would be subsequent documents. The document flow can be used to access the original document created in the system when each of the steps in the sales processing took place. In this manner, it forms an “audit trail” that can be used to examine the supporting documents for a given transaction.




Sales Logistics Master Data and Transaction Exercises for Flya Kite

The following discussion outlines the general flow of the exercises that will be completed in creating master data and processing sales logistics transactions in this case. Customers are essential elements of sales. In order to process a sale to a customer in SAP, a customer master record must exist that contains the necessary data describing and identifying that customer. Although customer master records may be created in Accounting, the records created there may contain only the data and views necessary for processing the accounting aspect of a sale. The customer master records created in Sales Logistics will generally contain all of the complete set of data (all attributes and views) that will allow transaction processing related to the customer from all processes in the company. Therefore, the Complete creation of the customer master is accomplished here. A customer may have multiple functions associated with its transactions. For a given customer, the Sold-to party may be different from the Ship-to party that is a separate branch of the same customer. For example, a headquarters unit may be the customer branch that actually orders the goods but in that order requests that the goods be shipped to a location such as a regional distribution warehouse. In such a case the customer master record must be modified so that the sold-to party information is created to receive shipments. The value of a sale is measured by the price of the goods sold. Therefore, sales prices for materials sold must be created in the SAP system in order to value the sales transactions. Sales prices are defined by Sales Organization and Distribution Channel to address the issue that materials may be sold by different sales organizations through different distribution channels at different prices. For example, sales prices may differ between geographical regions and will almost certainly differ between retail and wholesale distribution channels. In some cases, unique sets of sales prices may be established for particular customers based on business considerations. These customer specific prices must be created for the materials sold to that customer. In other cases the company may make the business decision to offer discounts based on some factor such as the amount of the particular order. In these cases a customer discount must be set up to apply the discount to orders from specific customers. As a customer service aspect of sales order processing, the company may create a customer material info record for one or more of its customer. This record allows the customer to place orders using its own part number and/or part description. The customer material master record in the system links the customer’s material part numbers to the material part numbers of our company. In essence this allows the customer to place orders using their own familiar language (i.e., part numbers) and allows our company to process those orders using our language ((i.e., part numbers). The customer material master record accomplishes the “translating” necessary to do this. When a customer often places an order that contains the same individual items, especially if there are a large number of those items, the company can create a “template” that contains the set of items (and quantities) that the customer usually orders. This “template” is known




as an Item Proposal. When the customer places an order, the Item Proposal can be referenced in processing the order thereby avoiding reentry of the items over and over for customary orders and this saving sales order processing time. In many cases the beginning point of a sales transaction is an inquiry from the customer seeking information about the price of one or more materials. A sales representative can complete a record of this inquiry from the particular customer that contains the pertinent data regarding the customer number, quantities, prices, and other related data. If the customer decides to place the order, the sales order can be created by transferring the data form the inquiry to the sales order thereby reducing processing time. When a customer order is filled, the items ordered must be delivered. Creating a delivery for a sales order brings the order to the point of determining the availability of the stock items and classifies the quantities of the items ordered as scheduled for delivery. These materials must by “picked” from the inventory stock of materials. The completion of this picking process initiates a materials delivery note that indicates that quantity of each item actually picked and which are to be delivered. Picked goods are moved to the shipping location in order to await pick-up for delivery to the customer. When the items in the order are actually dispatched to the customer, a Post Goods Issue is crated to record the actual shipment and to transfer ownership to the customer. Once the Post Goods Issue is created, the customer can be billed for the goods ordered. An invoice is created that is sent to the customer requesting payment for the shipment and which references the customer’s purchase order number, quantity shipped, prices, and all other pertinent data regarding the sales transaction.

TTHHEE AACCTTUUAALL BBIILLLLIINNGG OOFF TTHHEE CCUUSSTTOOMMEERR FFOORR AA SSHHIIPPPPEEDD SSAALLEESS OORRDDEERR OOCCCCUURRSS

IINN TTHHEE PPRROODDUUCCTTIIOONN LLOOGGIISSTTIICCSS PPRROOCCEESSSS RRAATTHHEERR TTHHAANN IINN AACCCCOOUUNNTTIINNGG AASS MMAAYY

BBEE AASSSSUUMMEEDD.. AA BBIILLLLIINNGG DDOOCCUUMMEENNTT WWIITTHH AA UUNNIIQQUUEE NNUUMMBBEERR IISS CCRREEAATTEEDD TTHHAATT

WWIILLLL BBEE UUSSEEDD BBYY AACCCCOOUUNNTTIINNGG TTOO PPRROOCCEESSSS TTHHEE AACCTTUUAALL CCOOLLLLEECCTTIIOONN OOFF

FFUUNNDDSS FFRROOMM TTHHEE CCUUSSTTOOMMEERR WWHHEENN TTHHEEYY AARREE RREEMMIITTTTEEDD..




CHAPTER 5:

Financial Accounting and Controlling (FI and CO)

In the SAP system, accounting and controlling exist as separate but highly related elements. Financial Accounting accomplishes the necessary processing and recording of accounting transactions along with the creation of financial statements and other reports for external users (e.g., individuals and entities outside of the company such as shareholders, government agencies, trade associations, etc.). Financial accounting is thus referred to in many instances as “external accounting” and as such must follow Generally Accepted Accounting Principles (GAAP) and external regulatory requirements. Controlling, on the other hand, takes care of the internal management uses of accounting information.

Controlling provides the company with information for management decision-making. It facilitates coordination, monitoring and optimization of all processes in an organization. This involves recording both the consumption of production factors and the services provided by an organization. The major activity of Controlling involves the assignment of costs to products and to cost centers to permit cost and profitability analysis.

Although Financial Accounting (FI) and Controlling (CO) are independent components in the SAP system, data flow between the two components on a regular basis. Therefore, all data relevant to costs automatically flow from Financial Accounting to Controlling.

Financial Accounting (FI)

In carrying out its external accounting function, Financial Accounting involves basically three accounting functions: General Ledger Accounting, Accounts Receivable processing, and Accounts Payable processing.

General Ledger Accounting provides a comprehensive picture for external accounting and accounts. Recording all business transactions (primary postings as well as settlements from internal accounting) in a software system that is fully integrated with all the other operational areas of a company ensures that the accounting data are always complete and accurate. General ledger accounting is the heart of financial accounting. Each accounting transaction (as defined under Generally Accepted Accounting Principles) is recorded directly or indirectly in the general ledger. The general ledger contains accounts that represent the detail for the major accounting classifications of assets, liabilities, equity, revenue, and expenses. The general ledger reflects the balance among these various accounts. The account balance data for the various accounts in the general ledger are the input for the company’s financial statements.

Accounts Receivable processing records and administers accounting data of all customers. It is also an integral part of sales logistics and management. All sales (assuming they are on credit) must be recorded and tracked for receipt of payment by customer. All postings in Accounts Receivable are also recorded directly in the General Ledger. Different G/L accounts are updated depending on the transaction involved (for example, receivables, down




payments, and bills of exchange). The system contains a range of tools used to monitor open items such as account analyses, alarm reports, due date lists, and a flexible dunning program. The correspondence linked to these tools can be individually formulated to suit company requirements. This is also the case for payment notices, balance confirmations, account statements, and interest calculations. Incoming payments can be assigned to due receivables using screen functions or by electronic means such as EDI and data telecommunication. Accounts Receivable is not merely one of the branches of accounting that forms the basis of adequate and orderly accounting. It also provides the data required for effective credit management (as a result of its close integration with the Sales Logistics) as well as important information for the optimization of liquidity planning through its link to Cash Management.

Accounts Payable processing records and administers accounting data for all vendors. It is also an integral part of the purchasing logistics and management. Deliveries and invoices are managed according to vendors. The system automatically makes postings in response to the operative transactions. In the same way, the system supplies the Cash Management application component with figures from invoices in order to optimize liquidity planning. Payables are paid with a payment program. The payment program supports all standard payment methods (such as checks and transfers) in printed form as well as in electronic form (data medium exchange on disk and electronic data interchange). This program also covers country-specific payment methods.

Organizational Structure in Financial Accounting

COMPANY CODE: The company code is the smallest organizational unit for which a complete self-contained set of accounts can be drawn up for purposes of external reporting. This includes the entry of all transactions that must be posted and the creation of all items for legal individual financial statements, such as the balance sheet and the profit and loss statement. It also involves recording all relevant transactions and generating all supporting documents for financial statements such as balance sheets and profit and loss statements. A company code can, for example, be a company or subsidiary.

All data that are valid for a particular company code, as well as for the plants and storage locations assigned to it, are stored at company code level. This includes, for example, accounting data and costing data if valuation is at company code level. Before the Accounts Receivable, Accounts Payable, and General Ledger application components of SAP can be used, a company code must be created as a minimum structure. More than one company code can be set up per client, enabling accounting for several separate companies simultaneously. At least one company code must be created.

A legally independent company is normally represented by one company code in the R/3 System. The definition of the company code, however, also states that it represents a dependent operating unit according to commercial law. This is necessary if this operating unit is based in another country and therefore has to meet the currency and tax-based requirements of this country.




In Financial Accounting, business transactions are always entered, saved and processed at company code level. Likewise, accounts are also always managed at company code level. Further levels can be created by using internal organizational structures. All company-specific specifications such as how payment transactions are to be carried out are made at company code level.

Customer and vendor master records have a company code area, which contains data that are only relevant to one company code. This includes, for example, data representing the business relations between the company code and a customer or vendor. The terms of payment that apply to each customer or vendor are assigned in the company code area of the master record.

CREDIT CONTROL AREA: The credit control area is an organizational unit that represents the area where customer credit is awarded and monitored. Credit and risk management takes place in this area. A credit control area can serve one or more company codes, but it is not possible to divide a company code into several credit control areas.

Master Data in Financial Accounting

CUSTOMER MASTER RECORD: Both Financial Accounting and Sales Logistics use customer master records. By storing customer master data centrally, it can be accessed throughout the organization and avoid the need to enter the same information twice. Maintaining the customer data centrally also avoids inconsistencies. If the address of a customer changes, for example, this change will only have to be entered once and the accounting and sales departments will always have up-to-date information. The customer master record links primarily to the Accounts Receivable function within Financial Accounting. By definition an account receivable is an amount owed by a customer. The customer master data record is necessary, therefore, not only to make the sale but to also process the collection of the customer’s payment and recording that payment in accounts receivable.

VENDOR MASTER DATA: Both Procurement Logistics and Financial Accounting use vendor master records. Storing the vendor data centrally allows access where needed throughout the organization without duplication of data. Central storage also avoids inconsistencies in data that is duplicated in numerous locations. Vendor master data are necessary in Procurement Logistics in order to obtain needed materials and services from the appropriate vendor. Vendor master data are also needed in the Accounts Payable function of Financial Accounting so that the liability to vendor can be recorded, the payment rendered, and the liability cleared.

GENERAL LEDGER: Essentially, the general ledger serves as a complete record of all business transactions. It is the centralized, up-to-date reference for the rendering of accounts. The main task of G/L accounting is the overall presentation of Financial Accounting. Transactions are recorded in and reports are generated from the general ledger based on accounts. An account is a structure which records value transactions within an accounting unit (in this case a company code) as an element from a value grouping such as assets, liabilities, revenues, etc. The account contains transaction figures, which reflect the changes to the values in a summarized form per company code. The accounts are listed in a chart of accounts. The chart of accounts is a list of all G/L account master records that are




used in one or several company codes. For every G/L account master record, the chart of accounts contains the account number, the account name and controlling information. Generally a company code utilizes one of the master charts of account that come with the SAP system. Accounts can be added to that master as the company so desires. Accounts in the general ledger are classified as assets, liabilities, equity, revenues, and expenses.

ACCOUNTS RECEIVABLE SUBSIDIARY LEDGER: The Accounts Receivable Subsidiary Ledger is set up to account for the values from business transactions with customers. The accounts receivable ledger records values at company code level. When a sale is made to a customer (as processed and recorded in Sales Logistics), an entry is made in the accounts receivable ledger under that customer number indicating that there is an amount owed by that customer to the company. The accounts contained within the accounts receivable ledger are all of the customer numbers created in the company code. The sum of all amounts owed to those customers (i.e., the sum of the account amounts in the ledger) is the total amount owed by customers to the company. When a payment is received from a customer, the customer account in the accounts receivable ledger is reduced by the amount of the payment. Therefore, in transaction processing, sales to customers are recorded by customer number and payments received from customers are recorded by customer number.

ACCOUNTS PAYABLE SUBSIDIARY LEDGER: The Accounts Payable Subsidiary Ledger accounts for the values of business transactions with vendors. The accounts payable ledger records values at company code level. When a purchase is made and goods are received from a vendor (as processed and recorded in Procurement Logistics), an entry is made in the accounts payable ledger under that vendor number, indicating that there is an amount owed to that vendor for the goods. For each vendor there is a sub-ledger account to which all amounts concerning this vendor are posted. A posting to the vendor account is not the same as a payment. For example, payment is only executed when the Financial Accounting department posts the vendor's payment to a bank account, for example.

The accounts contained within the accounts payable ledger are all the vendor numbers created in the company code. The sum of all amounts owed to those vendors (i.e., the sum of the account amounts in the ledger) is the total amount owed by the company to all of its vendors. When a payment is made to a vendor, the vendor account in the accounts payable ledger is reduced by the amount of the payment. Therefore, in transaction processing, purchases from vendors are recorded by vendor number and payments made to vendors are recorded by vendor number.

RECONCILIATION ACCOUNTS: Transactions with customers are posted to customer accounts in the accounts receivable subsidiary ledger, which carry a unique customer number for each customer. Transactions with vendors are posted to vendor accounts in the accounts payable subsidiary ledger, which carry a unique vendor number for each vendor. The customer subsidiary ledger contains all of the customer accounts (and numbers), while the vendor subsidiary ledger contains all vendor accounts (and numbers). However, vendor and customer numbers are not part of the general ledger set of accounts, even though that ledger contains an account both for accounts receivable and for accounts payable. In order for the general ledger accounts for receivables and for payables to reflect the total of the accounts in the respective subsidiary ledgers, a linkage between the subsidiary ledgers and their respective general ledger accounts is created.




The Accounts Payable Subsidiary Ledger and the General Ledger are related through the general ledger reconciliation account for accounts payable. The Accounts Receivable Subsidiary Ledger and the General Ledger are related through the general ledger reconciliation account for accounts receivable. Each of these general ledger reconciliation accounts is automatically updated when transactions are recorded in their respective associated subsidiary ledgers. This ensures that the developments in the subsidiary ledgers accounts are accurately reflected in the general ledger. Therefore, in the general ledger the amount shown for Accounts Payable is the total of all of the individual vendor accounts in the accounts payable subsidiary ledger.

THE GR/IR CLEARING ACCOUNT: In the business world, ordered materials may arrive either before or after the invoice for the goods is received from the vendor. If the goods are received prior to invoice receipt, the company would not want to delay entry of the goods into the material management system simply because no invoice had yet been received. To do so might delay production or other activities that are material dependent. However, since the invoice for these materials has yet to be received and the exact amount of the obligation determined, the company would not want to enter an assumed amount into the accounting system. The use of a GR/IR (goods receipt/invoice receipt) clearing account allows the organization to record the receipt of the materials and enter the materials into the materials management system but “suspend” the amount owed until the actual invoice is received. Thus, the GR/IR account functions like a traditional “suspense” account. The GR/IR clearing account is an intermediate account between the warehouse stock account and the vendor account. At goods receipt, the cost of the goods is posted to the inventory stock account and the net invoice amount expected is posted to the GR/IR clearing account. When the invoice is received, the posting in the GR/IR account is then cleared by an offsetting entry to the vendor account.

Transaction Processing in Financial Accounting

The transactions processed in Financial Accounting generally originate in some other part of the system. For example, recording and processing accounts receivable originates in Sales Logistics. The element of accounts receivable that originates within Financial Accounting is the recording of the receipt of the payment from the customer for that receivable. Transaction processing in Financial Accounting can generally be described as recording and reporting the results of events that occur elsewhere in the system. For this reason, Financial Accounting transactions can be described as data transactions as opposed to the physical transactions that occur in sales, procurement, and production.

The following graphic illustrates this flow of data transactions into Financial Accounting.




Many of the data transactions involved in Financial Accounting involve the payment of invoices or the receipt of payments from customers. However, payments for invoices involving purchased goods must be approved by the invoice verification process in Procurement Logistics before payment can be authorized. Customers are billed as the final step in the Sales Logistics. Financial Accounting processes the payments from customers that are received as the result of the billing invoices from Sales Logistics.

Controlling (CO)

Controlling involves the “internal’ accounting system used within the organization for management decision making. The information produced within Controlling is intended solely for internal use only. Controlling facilitates coordination, monitoring and optimization of all processes in an organization. This involves recording both the consumption of production factors and the services provided by an organization. The consumption of product factors and services provided are encompassed in the “costs” of those items. Although such costs are tracked in the Financial Accounting system, that tracking is primarily aimed at determining the value of ending inventory for the balance sheet and the cost of goods sold for the income statement for external reporting purposes. Therefore, these costs are not very useful for management decision-making such as the minimum sales price for the product, which customers or distribution channels are most profitable, whether overhead costs under or out of control, etc. Controlling meets the information requirement for such considerations.

Unlike Financial Accounting, Controlling is not governed by outside sets of rules such as GAAP. As well as documenting actual events in terms of costs, the main task of Controlling is planning. Controlling allows the determination of variances by comparing actual data with plan data. These variance calculations enable the company to control business flows. Income statements such as contribution margin accounting (not permitted for external




reporting) are used to control the cost efficiency of individual areas of an organization, as well as the entire organization.

Controlling (CO) and Financial Accounting (FI) are independent components in the SAP system. The data flow between the two components takes place on a regular basis. Therefore, all data relevant to costs flow automatically to Controlling from Financial Accounting. At the same time, the system assigns the costs and revenues to different CO account assignment objects such as cost centers, business processes, projects or orders. The relevant accounts in Financial Accounting are managed in Controlling as cost elements or revenue elements. This enables the reconciliation of the values from Controlling and Financial Accounting.

Within Controlling there are a number of features that provide different information sets for management decisions. Cost center accounting is used for the source-related assignment of overhead costs to the location in which they occurred. Activity-based costing can be used to analyze cross-departmental business processes in order to optimize overall organizational goals and to prioritize business flows. Internal orders are used to collect and control costs according to the job that incurred them. Product cost controlling calculates the costs that occur during manufacture of a product, or provision of a service; it enables the company to calculate the minimum price at which to profitably market a product.

Profitability analysis within Controlling analyzes the profit or loss of an organization by individual market segments. The system allocates the corresponding costs to the revenues for each market segment. Profitability Analysis provides a basis for decision-making, for example, for price determination, customer selection, conditioning, and for selection of the distribution channel. Profit center accounting evaluates the profit or loss of individual, independent areas within an organization. These areas are responsible for their costs and revenues. Profit Center Accounting is a statistical accounting component of the SAP system that occurs on a statistical basis at the same time as “true” accounting. In addition to costs and revenues, the system can display key figures, such as Return on investment, working capital or cash flow on a profit center.

Organizational Structure in Controlling

CONTROLLING AREA: Controlling uses the company code in a manner similar to its use in Financial Accounting. In Controlling a second structure element, the controlling area, is linked to the company code in order to allow greater tracking and analysis of data than in Financial Accounting.

A controlling area is an organizational unit that represents a closed system used for cost accounting. A controlling area may contain one or more company codes which can operate in different currencies, if required. The company codes within a controlling area must all use the same operational chart of accounts. All internal allocation transactions refer only to objects from the same controlling area.

Internal business transactions are portrayed in the controlling area. Primary costs are transferred from external accounting and classified according to managerial accounting perspectives. If the primary costs are direct costs (e.g., direct material or direct labor), then




they are assigned directly to cost objects such as production orders or sales orders. If primary costs are overhead costs, then they are assigned to cost centers or overhead cost orders. The system then allocates the costs using internal allocation techniques based on their source.

When master data are created, the system always assigns the Controlling objects to a controlling area and a company code.

PROFIT CENTERS: A profit center is an organizational unit in controlling that reflects a management-oriented structure of the organization for the purpose of internal control. Management can analyze operating results for profit centers using either the cost-of-sales or the period accounting approach. By calculating the fixed capital, too, profit centers can be analyzed as investment centers.

In profitability accounting at the profit center level, all costs and revenues from the profit-relevant logistic activities and other allocations are transferred as statistical postings to the relevant profit centers. Every profit center is assigned to the organizational unit Controlling Area. This assignment is necessary because Profit Center Accounting displays values in general ledger accounts. The system transfers all the data to Profit Center Accounting together with the general ledger account to which the data was originally posted.

COST CENTERS: A cost center is an organizational unit within a controlling area that represents a defined location of cost incurrence. A cost center can be defined based on functional requirements (e.g., accounting, plant security, company cafeteria, etc.), allocation criteria (how costs are allocate to the unit such as by headcount of employees, square feet, etc.), physical location (e.g., the northern sales office, the southern sales office, etc.), or responsibility for costs. Cost centers are used for differentiated assignment of overhead costs to organizational activities, based on utilization of the relevant areas (cost determination function) and for differentiated controlling of costs arising in an organization (cost controlling function). Overhead costs are “collected” in a cost center and then allocated to the organizational units or functions that “use” the services provided by that cost center.

Cost centers can be collected into groups according to various criteria. Those groups can be used to build cost center hierarchies, which summarize the decision-making, responsibility, and control areas according to the particular requirements of the organization. The individual cost centers form the lowest hierarchical level. For example, the vice president in charge of sales may have four regional sales cost centers that report directly to him/her. Each regional sales cost center may have numerous area sales cost centers within the region; each area sales cost center may have numerous local sales office cost centers within its area. Linking these various cost centers together would allow tracking and analysis of operations and costs throughout the overall sales organization, by region only, by area only, or by individual sales office.

There must be at least one group that contains all cost centers and represents the entire business organization. This cost center group is described as the standard hierarchy. The user can assign additional cost center groups to the standard hierarchy if needed.




Any number of alternative groups of cost centers can be created. Groups can be structured, for example, by organizational and/or functional viewpoints. Cost center groups enable the user to perform evaluations for each decision-making, responsibility, or control area. These groups also support the processes during planning and internal allocations. Following the sales organization example, assume that each local sales office sells a particular line of the company’s products. Sales offices selling product line A could be grouped together in an alternative hierarchy along with all other local sales offices that sell the same product line regardless of the area or region. In this way, operations and cost could not only be followed by geographical location (under the standard hierarchy) but also by product line.

Users can assign each cost center to only one group within the standard hierarchy, but to as many alternative groups as required. This allows for the information related to each cost center to be “sliced and diced” any way management desires.

Master Data in Controlling

The major master data in Controlling involves cost elements that classify an organization’s valuated consumption of production factors within a controlling area. A cost element corresponds to a cost-relevant item in the chart of accounts. Cost elements document which costs (differentiated by category) are incurred within a settlement period, and the amount. They provide information concerning the value flow and the value consumption within the organization. The system distinguishes between two types of cost elements: primary costs and secondary costs.

PRIMARY COSTS: A primary cost element is a cost item in the chart of accounts for which a corresponding general ledger (G/L) account exists in Financial Accounting (FI). The user can only create the cost element in Controlling if it has first been defined as a G/L account in the chart of accounts and created as an account in Financial Accounting. The SAP System verifies that a corresponding account exists in Financial Accounting. Examples of primary cost elements include material costs, personnel costs, and energy costs.

Primary costs arise through the consumption of goods and services that originate from outside the company such as the cost of items purchased from vendors, employee salaries and wages, purchased services, costs of fixed assets (i.e., depreciation), etc. These costs are recorded as expenses in the appropriate accounts in the General Ledger in Financial Accounting. A link must be created in order for an item recorded as an expense in Financial Accounting to be treated as a primary cost in Controlling.

Because a primary cost has a matching expense account in Financial Accounting, a posting to an expense account therefore results in a cost that can be traced directly to a particular cost object in Controlling. For example, the costs for an external activity provided by a supplier can be allocated directly to a cost object in Controlling. This requires the incoming invoice to be assigned to the cost object. When the incoming invoice is entered in Financial Accounting (FI), the amount is immediately allocated to the cost object in Controlling as well as being recorded in the appropriate general ledger expense account in Financial Accounting.




An example of a primary cost is a direct materials cost. When a raw material is withdrawn from inventory to be used in manufacturing a finished product, a posting is generated to an expense account in Financial Accounting. The relevant expense account in Financial Accounting is the Raw Materials Consumption expense. The withdrawal (a goods issue) is entered in the application component Production Logistics (i.e., Materials Management - MM). Such goods movements in Production Logistics automatically generate postings in Financial Accounting. For raw materials, the system debits Consumption of Raw Materials and credits Raw Materials. The direct materials costs are allocated to the cost object. The amount allocated is the same as the expense posted in FI.

SECONDARY COSTS: Secondary costs are cost elements that represent the activity values produced during internal cost allocations. For example, the expenses accumulated in the operation of the company’s data processing center are collected and then allocated as secondary costs to the various internal organizational units that use the center. Therefore, secondary costs do not “originate” (in that they do not represent transactions with outside parties) but are “created” from internal allocations.

Secondary cost elements can only be created and administered in Controlling. They portray internal value flows such as those found in internal activity allocation, overhead calculations and settlement transactions. When a secondary cost element is created, the SAP System verifies that a corresponding account exists in Financial Accounting. If one exists, it cannot be created as a secondary cost element in Controlling.

A secondary cost does not have a matching expense account in Financial Accounting. Secondary costs are therefore valuated consumptions of internal activities (activities performed inside the company rather than purchased from outside.) Secondary costs are overhead costs.

Transaction Processing in Controlling Like Financial Accounting, the transactions in Controlling can be described as data transactions. In the most basic format, Controlling transactions involve the assignment of costs to various cost objects such as products, cost centers, orders, etc. through an allocation process.

ALLOCATION: You can periodically allocate amounts and quantities from sender objects to receiver objects using allocations. The two main types of allocations are assessments and distributions. Both plan and actual data can be allocated. Allocation is carried out using the allocation cycle function. Allocation rules are used to determine how amounts and quantities should be allocated from sender object to receiver object. It is possible to assess/distribute amounts and quantities according to a number of criteria that can be specified within the allocation rules.

DISTRIBUTION: A distribution allocation is used to allocate the primary costs of a cost center. In a distribution, the original cost element (the primary cost element) is retained. In addition, sender and receiver information (for example, the identities of the sender and receiver cost center/business process) is documented using line items in the CO document. A distribution is accomplished periodically (monthly, for example) in order to transfer the




primary cost from a cost center where it has been collected to the cost centers that are consuming that primary cost. When the distribution is complete, the amount of the primary cost of the item being distributed by the cost center may be zero (if the entire amount is distributed) or reduced to only the amount of the cost consumed by that cost center.

For example, assume that an office building is rented for $10,000 per month. The invoice for the monthly rental is received and recorded in Financial Accounting in the rent expense account. This account has been linked to Controlling as a primary cost element and as such requires a cost object to which it must be charged. For administrative simplicity, assume the company has set up the accounting department as the cost center to receive the entire amount of the rent cost in Controlling even though the accounting department occupies only part of the building. Also housed in the building are human resources, corporate sales, various vice presidents’ offices, and data processing. At the end of the month or at some other predetermined time, the rent cost charged to accounting must be allocated to all of the occupants of the building through a distribution. A distribution has been chosen for this allocation so that each receiving department will show a rent cost in its operating reports. This may have been decided so that if a department increases its share of the space in the building, it would be charged an increased rent cost. The distribution, therefore, has been set up based on the number of square feet occupied by a department as a percentage of the total square feet occupied by all departments. The table below indicates the various percentages of the total building space occupied by the departments.

Accounting 15% Human Resources 10% Corporate Sales 20% Vice Presidents 30% Data Processing 25% When the distribution is executed by the system, Accounting will receive an allocation of $1,500, Human Resources $1,000, Corporate Sales $2,000, Vice Presidents $3,000, and Data Processing $2,500. Each of these units will display this amount in the Rent Distribution line on its operating reports. In this way, each unit knows exactly how much it is charged for rent and that the charge is transferred from the Accounting department. For accounting, the entire $10,000 will be eliminated from its Rent Cost collection account (resulting in $0 in that account) but it will indicate a distribution of Rent of $1,500. Distributions can be based on square footage, employee headcount, number of telephones, or other criteria found to be meaningful by management. These various criteria are known as statistical key figures. These statistical key figures can be fixed value (for which the values are carried forward from one period to the next) or total value (for which the values must be recorded for each period independently). Fixed values are used for elements that remain relatively stable from period to period such as square feet occupied in a building. Total values are appropriate for items that fluctuate from period to period such as employee headcount.

ASSESSMENTS: An assessment is an additional way through which costs are allocated. Assessment is a method of internal cost allocation by which the company allocates (transfers) the costs of a sender cost center to receiver CO objects (orders, other cost




centers, etc.) under an assessment cost element. The method works according to the keys defined by the user.

Unlike Distribution, where only primary costs can be allocated, an assessment is a method of allocating both primary and secondary costs. In Assessment the original cost elements are assigned cumulatively, or in groups, to assessment (secondary) cost elements. The original cost elements are not recorded in the receivers’ accounts but are recorded as an assessment from the sender cost center. Also, sender and receiver information (sender cost center, receiver cost center, or business process) appears in the Controlling (CO) document.

Allocation through assessment is useful when the composition of the incoming costs is unimportant to the receiver. For example, the assessment of cafeteria costs to a cost center need not be itemized in the receiving cost center’s records.

Assume a company operates a subsidized cafeteria. The cafeteria incurs expenses for food, wages, electricity, etc. during operations. The cafeteria may also receive secondary cost charges such as maintenance, electricity, rent occupancy, etc. The amount of total cafeteria expenses not covered by revenue from food sales is to be charged to the cost centers whose employees use the cafeteria. Assessment will accomplish the allocation of both these expenses (primary costs) and secondary costs to other cost centers in the company.

The company can assess the costs from the cost center "Cafeteria" to receiver cost centers in proportion to the statistical key figure "Employees" for each cost center. Receiver cost center I has 10 employees, while receiver cost center II has 90. In this case, the system would assess 10% of the costs from the cost center "Cafeteria" to receiver cost center I and 90% to receiver cost center II. The credit entered in the sender cost center "Cafeteria" and the debits entered in the receiver cost centers are all assigned by the assessment cost element. Depending on the system settings, the system can assess all the costs of the sender cost center "Cafeteria" or only part of those costs

Under Assessment, the receiving cost centers or other objects receive the amount assessed with only a general description of what is being assessed. For example, the receiver cost centers in the example above will receive their assessment as “Cafeteria Assessment’ with no indication of the nature of the expenses within the cafeteria.




Accounting and Controlling Master Data and Transaction Exercises for Flya Kite

The following discussion outlines the general flow of the exercises that will be completed in creating master data and processing accounting and controlling transactions in this case. Although the SAP system has numerous charts of accounts that can be used by a company, there may be a need to add general ledger accounts. This is described as the manual creation of a general ledger account and results in a master record for the general ledger account being added to the chart of accounts and the general ledger system. If the company has determined to use a subsidiary ledger due to a large volume of transactions of a particular type, the reconciliation account (control account) for the particular specific type of subsidiary ledger must be added to the chart of accounts (as a master record for a general ledger account). The company may decide to add a goods receipt/invoice receipt (GR/IR) to the general ledger in order to expedite invoice verification and the receipt of goods from vendors. The company makes a business decision on this issue weighing the internal control aspects and the operational necessities in order to reach this decision. The company may decide to add profit and loss accounts (P&L accounts) to the general ledger in order to differentiate both expenses or revenues in a manner that is more detailed or descriptive than those the accounts provided by the system. For example, the company may wish to set up its own rent expense account in order to track rent charges from a particular vendor or for a particular rental. The company may also wish to track revenues from different sources in a more detailed manner than the revenue accounts delivered with the system. If the company decides to use cost allocation in Controlling, it must create accounts for primary cost elements that link Accounting to Controlling automatically. If vendor master records have not been created in one of the logistics areas or if the accounting views need to be added to such records that already exist, vendor records may be created in the accounting area or the accounting views added to the existing vendor records. As the company acquires products and services, the invoice or the events surrounding that transaction must be recorded to properly record the assets, expense, cash disbursements, and/or accounts payable involved. Entering these transactions provides a record of these events and also records the obligations to make payment if the transaction involved a credit purchase. If the event is initiated by a purchase made by check, the recording of the event involves the entry of the document to create the record of the transaction. If the event involves the direct receipt of a vendor invoice by accounting (as opposed to coming through logistics vendor invoice verification), the vendor invoice must be “posted” in the accounting system so that the liability is recorded and can be paid at a later date.




Amounts owed to vendors are contained in accounts payable until actual payment is made. An outgoing payment must be posted to clear the vendor invoice that is recorded in accounts payable. This posting clears the liability and decreases the cash available to the company. In cases where a customer owes the company for purchases made in the past, the specifics of that transaction are contained in accounts receivable. This account generally arises due to activities in sales logistics. The customer’s payment for the items, however, is processed in Accounting. This requires a receipt of payment from the customer. This receipt clears the receivable from the customer for the amount remitted. In cases where the company has made the business decision to allocate costs to cost centers, either a distribution cycle or an assessment cycle must be created. Either involves, of course, the cost centers from which and to which the charge is to be made. Each of these cycles must contain the “tracing factor” or basis on which the distribution or assessment is to be made (e.g., headcount, square feet, etc.). The company must make a business decision to allocate by a distribution (where costs retain their nature as they are allocated) or by an assessment (where the costs “lose” their identity and are simply charged as a lump-sum assessment).




CHAPTER 6: Human Resources (HR)8

Typical concepts and practices associated with Human Resource Management (HRM) include job analysis, recruitment and selection, performance management, training and development, compensation and benefits, and employee and labor relations. These practices are common to any organization, pertain to all types of employees, and are largely performed in a cycle of events, ranging from the beginning transaction of hiring an employee, to training the employee for future job opportunities, to rewarding the employee through compensation and other incentives. The Human Resources (HR) module in SAP R/3 incorporates these concepts and practices, enabling managers to perform transactions pertaining to the HRM cycle of events. Using more specific SAP terminology, the HR module in SAP R/3 is comprised of the following primary processes: organizational management, recruitment and selection, personnel development, training and event management, travel management, compensation management, benefits, personnel administration and manager’s desktop. Additional applications include shift planning, time management, payroll, personnel cost planning, and incentive wages, among others. The primary HR processes in SAP R/3, and as how they relate to HRM practices, are described below. Organizational Management provides the basis for structuring personnel planning and development processes, and is necessary for personnel administration. Using this application, an organizational structure, including departments, jobs, positions, and tasks, can be created. Work is further defined and described through the process of job analysis: the cornerstone of HRM. Recruitment and Selection transactions enable the advertising of position vacancies, the identification of recruitment sources, and the hiring of employees. Additionally, qualifications required of vacant positions can be matched with the qualifications of applicants to facilitate decision making in the selection process. Not surprisingly, this functionality in SAP R/3 relates well to recruitment and selection in HRM. Personnel Development pertains to performance appraisals, career and succession planning, and career development. Performance appraisals help facilitate decisions regarding promotions, merit pay, and terminations. Transactions in SAP R/3 relate to the typical HRM practices associated with performance management systems. Training and Event Management involves the management of employee activities associated with training, workshop attendance, and other business-related events. Information on descriptions of programs, prerequisites, and cost factors can be generated. As many organizations value continual learning, the SAP R/3 learning solution ties in well with the training and development practices common to HRM.

8 This chapter was developed by Professor Kathy Utecht of Sam Houston State University




Travel Management enables organizations to monitor the second largest controllable expense associated with travel, training, and entertainment. Employees frequently travel on business, so managing this expense is essential. Compensation Management is essential in promoting internal equity and external competitiveness. Features of this application include job pricing, reviewing salary surveys, and creating policies and budgets. These are hallmarks of compensation in HRM. Benefits in SAP R/3 extend far beyond the typical benefits required by law. Included are benefits pertaining to flexible spending accounts, 401(k) plans, health care accounts, as well as mechanisms to track costs of benefits. These are components commonly discussed in HRM. Personnel Administration facilitates the management of HR master data, personnel files, and relational data bases. Maintaining accurate and confidential employee records is critical to this function. Manager’s Desktop is a tool which enables managers to access employee information at a manager’s fingertips, i.e., managers do not have to access menu paths or transaction codes to retrieve employee information. Rather, through decentralization of HR tasks and responsibilities, managers can easily access HR data of subordinates, both directly and indirectly supervised, to perform administrative and organizational tasks, and to make strategic decisions.

Organizational Structures in Human Resources ENTERPRISE STRUCTURE: Every employee in an organization is included in the structure of his or her enterprise. The Enterprise Structure sub-divides organizations and employees according to factors relevant to time management and payroll. The determinants of an Enterprise Structure include the client, company code, personnel area, and personnel sub-area. The client is the major organization criterion in the system, and is a self-contained unit. Personnel data entered in a client can only be accessed in that client. Data cannot be exchanged among clients. If employees change clients, data have to be re-created in that new client. The company code is an independent accounting unit, and is also self-contained. A set of accounts can be developed in the company code, and financial statements such as balance sheets and profit-and-loss statements are created at this level. The personnel area represents the “company and country version for payroll” view, is used primarily in personnel administration, is unique within a client, and is a sub-division of the company code. It serves as a selection criterion for reporting, constitutes a unit in authorization checks, and allows one to generate default values for data entry, e.g., for the payroll accounting area.




The personnel sub-area represents the “location and public holiday calendar” view, is a subdivision of a personnel area, and identifies groupings of employees assigned to a particular personnel area or company code. It is the level at which the primary organizational aspects of human resources are controlled. Its functions include specifying a country grouping, setting groupings for time management so that work schedules can be set up for individual personnel sub-areas, generating a default pay scale type and area for basic pay. PERSONNEL STRUCTURE: This structure also sub-divides organizations and employees according to factors relevant to time management and payroll. Employees in a personnel structure are divided into two groups: employee group and employee sub-group. The employee group is the highest level, and defines the relationship between an employee and a company in terms of work, i.e., active employees, pensioners, and early retirees. These groups can be differentiated further. For example, an active employee may also be a trainee, an hourly wage earner, a salaried employee, etc. The principal functions of the employee group include generating default values for payroll accounting area and basic pay, serving as a selection criterion for reporting, and serving as a unit in authorization checking. The employee sub-group enables distinguishing among employees specifically with regard to their status. For example, active employees may be classified as a trainee, hourly wage earner, non pay-scale employee, salaried employee, etc. Functions include allowing different payroll procedures for different employee subgroups, controlling the validity of wage types on an employee sub-group level, and defining the validity of work schedules, attendance and absence quotas. ORGANIZATIONAL STRUCTURE: The organizational structure and plan is the comprehensive model of the structural and personnel environment in the enterprise, with hierarchies and reporting relationships clearly defined. Hierarchies and reporting relationships are determined once object types are created. Typical object types include organizational units, jobs, positions, tasks, and persons. Organizational units reflect the various business units or departments in the enterprise. Several organizational units can be created, and they must be related to one another in an organizational plan. They can be defined as functional, divisional, or geographical departments, or as project groups. An example of a functional structure would include accounting, sales, human resources, and manufacturing departments. Jobs reflect the tasks, duties and responsibilities of the work being performed in the organization. Typically, they are grouped in terms of the similarity of tasks being performed, and are more generic in nature. Some examples include analyst, specialist, manager, and supervisor. Positions are more specific than jobs, and all of the information stored in a job is inherited by all of the positions created from the job. Positions reflect individual employee assignments, and are occupied by persons. Examples of positions include Accounting Analyst, Logistics Specialist, Compensation and Benefits Manager, and Production Supervisor.




Persons are assigned to positions in the organizational structure, and generally represent the employees in the company. For example, Ross Quarles may be the Accounting Analyst, Fawzi Noman may be the Logistics Specialist, Kathy Utecht may be the Compensation & Benefits Manager, and High Asa Kite may be the Production Supervisor. Tasks are the individual duties and responsibilities undertaken by employees in their positions, as reflected in their job descriptions. Examples of tasks include “prepares accounting reports,” “maintains warehouse inventory,” “reviews salary surveys,” and “oversees production scheduling.”

Master Data in Human Resources A vast amount of HR data can be maintained in SAP R/3. Personnel data provide the basis for various HR transaction processing and reporting. Hence, its accuracy, timeliness, relevance, and completeness are crucial. While most data may be housed in an HR department’s information system, it is important that data that pertaining to an overall HR information system be included. Typically, the data pertains to employee information which is entered into the system using infotypes (types of information) and which is stored in an HR Master Database. Infotypes categorize information and enable data input, i.e., they are data entry screens which allow the entering of various types of information into data fields. Similar types of information can be grouped by content to facilitate data entry. Infotypes can be processed individually or through the fast entry mode (entering specific data for several employees at once). Processing of infotypes may include creating (creating a new record with beginning and end dates), changing (changing or correcting a record), copying (using the initial record as a template), delimiting (upon entering a delimitation date, records valid for that date are selected, and then setting the end date for that record to the day before the delimitation date), and displaying (viewing but not changing records). There are over 600 HR infotypes used to maintain employee and applicant data, and the number, types, and settings of infotypes can be customized to fit the business requirements of the company. HR Master Database is where HR data are stored. Typically, employee information is stored in a personnel file which can be accessed by entering the employee’s assigned personnel number (usually generated internally by the system). Several records of information on an employee can be reviewed, such as organizational assignment, basic pay, addresses, travel preferences, planned working time, etc. Information can also be retrieved in a relational database format by accessing specific infotypes. For example, if a manager wants to review the basic pay of an employee, the manager does not have to access the personnel file and review all of the records until basic pay is reached. Rather, the basic pay infotype (i.e., 0008) can be accessed directly so that only that information is retrieved.

Transaction Processing in Human Resources

Acquiring and retaining a qualified pool of talent to work in an organization is critical to the success of the organization. Human resources, or employees, are valued for their intellectual capital, flexibility, and ability to develop, adapt, and respond to a rapidly changing




environment. Human resources are also one of the most expensive resources in organizations. Hence, hiring, training, paying, and promoting valued employees in a cost effective way is essential. Monitoring HR data transactions in SAP R/3 helps facilitate the process. Organizational Management and Job Analysis: The organizational structure of the company is designed to reflect departments, hierarchies and reporting relationships. Data transactions include the creation of organizational units, jobs, positions, position descriptions, and an organizational chart. Recruitment: The objective of recruitment is to enable the selection and hiring of qualified applicants for a vacant position. Data transactions include creating a vacant position, determining the qualifications required of the position, advertising the position, receiving and screening applications, identifying the most qualified applicants, rejecting unqualified applicants, and storing applicant materials of those not hired but to be considered for future vacancies. Selection: Once qualified applicants have been identified, an offer or contract is extended. Data transactions include assigning a personnel number to the new employee, and transferring applicant data to a master database, where infotypes such as planned working time, basic pay, bank details are created. EEO compliance can also be assured through HR data transactions. Personnel Development: Employee performance is evaluated or appraised on a periodic basis for developmental reasons (to provide feedback to the employee) as well as for administrative purposes (to determine promotions, merit increases, etc.). Additionally, a profile match up of the position’s requirements and the person’s qualifications can be generated. Additional data transactions include conducting a performance appraisal using 360 degree feedback, and identifying the preferences, potentials, and dislikes of employees for career planning and training and development purposes. Training: Performance appraisals help identify qualification deficits. Employees needing to develop a competency can be sent to a training program or workshop. SAP R/3 data transactions include selecting the appropriate program based on its contents from a catalog, pre-booking an employee in the training program, and reviewing various reports, including costs, attendance statistics, and attendee training history. Travel Management: Employees typically attend training programs or engage in business off-site. Hence, the travel of employees must be managed. Data transactions include entering employee travel preferences in a database (e.g., airline, hotel, car rental), travel planning (e.g., selecting dates and destinations), posting travel expenses, and generating trip data reports to negotiate special conditions with travel service providers. Compensation Management: Rewarding employees with basic pay, as well as with incentives, is a typical feature of organizational life. In SAP R/3, common compensation transactions include entering internal job evaluation results and external salary survey data, generating salary structures, developing pay grades and pay scales, creating budgets, and developing incentive pay.




Benefits: Benefits are crucial to the entire compensation package, and play a vital role in enabling a company to remain competitive. Typical benefits transactions include activating benefits infotypes for employees, enrolling employees in various benefit plans (e.g., health, flexible spending accounts, 401(k) plans), and reviewing the costs of various employee benefit choices.

Human Resource Master Data and Transaction Exercises for Flya Kite

The following provides a brief summary of the general flow of the exercises that will be completed in creating master data and processing human resource transactions in this case. The cornerstone of human resource management is job analysis. No other human resource management practices can be undertaken until one knows what the jobs are in the organization. More specifically, without understanding what the job is, managers cannot begin the process of recruitment, selection, training, compensation, etc. Similarly, when jobs are created, they are attached to departments or divisions. Hence, creating an organization with a hierarchical structure reflecting departments, jobs, positions, and job descriptions, is fundamental in human resource management. In the following exercises, you will be creating an organizational structure with five departments for Flya Kite. And, for each of these departments you will create a job, position, and position description. These transactions will then produce an organizational chart for the company. Determining pay structures of jobs and positions in a company requires managers to maintain internal alignment as well as external competitiveness. More specifically, through job evaluation, jobs are placed in a hierarchy with regard to their worth to the company, and, eventually, corresponding salaries are assigned. This enables managers to maintain internal equity. Additionally, to ensure that salaries are competitive with similar jobs in other companies, managers need to review salary survey data from other companies. Examining both the internal and external salary information enables managers to determine if they are leading the market (paying above the market), meeting the market (paying about the same as), or lagging the market (paying less than). Based on the compensation strategy of the company, the results of this examination may require salary adjustments. So, determining compensation levels for the jobs created in the organizational structure is essential. For Flya Kite, you will be entering job evaluation points for each of the five jobs, which you created previously, to create an internal hierarchy of jobs in terms of their worth to the company. Next, for each of the jobs, you will enter salary data from a salary survey of comparable jobs in competing organizations. Finally, you will create a salary structure for the jobs in Flya Kite based on finding the best fit in maintaining internal equity and external competitiveness. Determining whether vacant positions (which are attached to jobs and descriptions) are to be filled in an organization occurs through the process of human resource planning and forecasting. The process of filling a vacant position is initiated through the recruitment process, i.e., identifying recruitment sources such as The Wall Street Journal, creating an advertisement which describes the position and the required qualifications, and receiving applications. In the hiring process, qualified applicants are selected and a database, i.e.,




personnel file, is created with information pertaining to the new employee. In Flya Kite you will be receiving an application for a previously advertised vacant position of Human Resource Manager. You will enter initial applicant data, determine the applicant is qualified for the position, and hire the applicant. Information about this new employee, such as organizational assignment and basic pay, will be entered in a newly created personnel file. Often times, new employees may not fit the new position exactly, and may be deficient in certain qualifications. This is often the case when the employee offers other characteristics that are of value to the company. When this is the case, employees are sent to training programs to enable the employee to develop an additional skill or competency. Associated with attending a training program are expenses incurred with the travel. As training and travel are, typically, large expenses, it is important for managers to conduct a cost benefit analysis. Recording travel expenses incurred with training provides a medium for tracking these costs. In Flya Kite, you have determined that your newly hired Human Resource Manager does not have a required level of proficiency in knowledge of compliance requirements regarding the Occupational Safety and Health Act (OSHA). Hence, you will send the HR Manager to an OSHA Safety Refresher Training program to develop that proficiency. Since the training is off-site, you will enter travel information regarding flights, hotels, and car rentals, as well as record airfare, hotel, and car rental expenses. This is a good example of the interface between HR and FI. Employees working in the manufacturing sector of a company are subject to compliance with OSHA and company safety policies. For example, employees working with or around machinery, chemicals, or in other conditions that may be hazardous must comply with specifications regarding the work environment. Typically, HR interprets and oversees these specifications. Therefore, HR may determine that workers need to pass a preventative health exam, wear a protective mask, or not exceed working a specified number of hours in sequence in compliance with the law and company policy. In Flya Kite, you will create a work center where production of kites takes place, and then have the HR Manager, who has now received refresher training in OSHA, assign required specifications to the work center. This is a good example of the interface between HR and Logistics. Finally, most organizations offer benefits beyond those required by law. These may include flexible spending accounts, health care plans, 401(k) plans, among others.

Documents

STUDENT TEXT FULLY INTEGRATED VERSION (MM, …athensstatesapfaculty.pbworks.com/f/Flya+Kite+Fully+Integrated... · (MM, PP, SD, FI/CO, HR) ... ALL MATERIALS FROM SAP LIBRARY ADAPTED