Flya Kite Fully Integrated Case

FOR ACADEMIC USE ONLY
ALL MATERIALS FROM SAP LIBRARY ADAPTED

WITH PERMISSION OFSAP AMERICA UNIVERSITY ALLIANCE
Flya Kite Fully Integrated Case
Student Text
(MM, PP, SD, FI/CO, HR)
Flya Kite Case:

Processing transactions through the
logistics and support processes of SAP
Ross Quarles
Fawzi Noman
Version 8.0
6/01/2016
Sam Houston State University

Huntsville, Texas
©2010 Ross Quarles and Fawzi Noman Page: 1

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 Capital Management (HCM)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 Function (Process) Functional Areas

Module
MM Materials Management Purchasing, invoice verification, inventory
(Procurement management, warehouse management
Logistics)
PP Production / MRP MRP, production orders, bills of materials, work
(Production Logistics) centers, routing instructions, batch management
SD Sales and Distribution Order entry, picking/packing/shipping, invoicing,
(Sales Logistics) inquiries, quotes, sales reporting
FI Financial Accounting General ledger, A/R, A/PAY financial reporting, cash
(Support Process) management legal consolidation
CO Cost Accounting Cost accounting and internal reporting by cost center,
(Support Process) internal order, project, profit center, or other unit,
profitability analysis
HR Human Resources Employee master data, training records gross/net
(Support Process) 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
Purch Purch Goods Invoic

ase asing e
Materia
l Data
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

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
4A 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
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.

ONCE THE PRODUCTION AND VARIOUS MOVEMENTS OF THE KITES PRODUCED BY

THIS PRODUCTION ORDER ARE COMPLETED, IT IS TIME TO SETTLE THE COSTS TO
PRODUCE THE KITES TO THE ORDER. AFTER THIS SETTLEMENT IS EXECUTED, A
REPORT INDICATING THE ACTUAL/PLAN/VARIANCE AMOUNTS CAN BE VIEWED
FOR THE ORDER.

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
Company
Code
Flya Kite
Flya Kite
Sales
Organization
Distribution Distribution
Channel: Channel:
Retail Wholesale
Standard Competitive Standard Competitive

Division Division Division 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.
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.
Maintaining the data is possible from both the accounting view and the sales and
distribution view.
6
Customers are sometimes referred to in SAP as business partners. Other business partners are vendors
and employees.

 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:
 Which batches a material is picked from
 Which serial numbers are picked
 Which valuation types the stock is taken from
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.

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
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.
THE ACTUAL BILLING OF THE CUSTOMER FOR A SHIPPED SALES ORDER OCCURS
IN THE PRODUCTION LOGISTICS PROCESS RATHER THAN IN ACCOUNTING AS MAY
BE ASSUMED. A BILLING DOCUMENT WITH A UNIQUE NUMBER IS CREATED THAT
WILL BE USED BY ACCOUNTING TO PROCESS THE ACTUAL COLLECTION OF
FUNDS FROM THE CUSTOMER WHEN THEY ARE REMITTED.

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
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 Capital Management (HCM)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.
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.
8 This chapter was developed by Professor Kathy Utecht of Sam Houston State University

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 Capital Management

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 Capital Management

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 Capital Management

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.

Flya Kite Fully Integrated Case - Student Text PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Flya Kite Fully Integrated Case - Student Text PDF

Загружено:

Авторское право:

Доступные форматы

FOR ACADEMIC USE ONLY

ALL MATERIALS FROM SAP LIBRARY ADAPTED

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

Flya Kite Case:

Sam Houston State University

©2010 Ross Quarles and Fawzi Noman Page: 1

Table of Contents – Student Text

II. Chapter 2: Procurement Logistics (MM)

III. Chapter 3: Production Logistics (PP)

IV. Chapter 4: Sales Logistics (SD)

V. Chapter 5: Financial Accounting and Controlling (FI and CO)

VI. Chapter 6: Human Capital Management (HCM)1

©2010 Ross Quarles and Fawzi Noman Page: 2

Basic SAP Modules

©2010 Ross Quarles and Fawzi Noman Page: 3

SAP Function (Process) Functional Areas

Master Data Record Modules Using Record

SAP General Terms

Company Code: Represents an independent legal accounting entity that contains a

©2010 Ross Quarles and Fawzi Noman Page: 4

Configuration: Configuration is table-driven customization of the SAP system to

©2010 Ross Quarles and Fawzi Noman Page: 5

©2010 Ross Quarles and Fawzi Noman Page: 6

SAP Help Portal. <http//help.sap.com>

©2010 Ross Quarles and Fawzi Noman Page: 7

CHAPTER 2: Procurement Logistics (MM)

Purch Purch Goods Invoic

©2010 Ross Quarles and Fawzi Noman Page: 8

©2010 Ross Quarles and Fawzi Noman Page: 9

Information for material requirements planning (MRP) and consumption-based

Procurement logistics transaction process flows: From an overall perspective, the

©2010 Ross Quarles and Fawzi Noman Page: 10

Purchasing (Purchase Order)

A purchase order is a legally binding instruction from a purchasing organization to a vendor

©2010 Ross Quarles and Fawzi Noman Page: 11

©2010 Ross Quarles and Fawzi Noman Page: 12

Invoice Verification in Materials Management serves the following purposes:

©2010 Ross Quarles and Fawzi Noman Page: 13

 Executing the account postings resulting from an invoice

©2010 Ross Quarles and Fawzi Noman Page: 14

Procurement Logistics Master Data and Transaction Exercises

©2010 Ross Quarles and Fawzi Noman Page: 15

©2010 Ross Quarles and Fawzi Noman Page: 16

CHAPTER 3: Production Logistics (PP)

The Demand Management component of MRP is needed to define requirement quantities

©2010 Ross Quarles and Fawzi Noman Page: 17

In make-to-order production, a product is produced specifically for an individual sales

An assemble-to-order environment is one in which the product or service is assembled on

©2010 Ross Quarles and Fawzi Noman Page: 18

components. In the R/3 System, assemble-to-order is a special type of make-to-order

Master Data in Production Logistics

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

©2010 Ross Quarles and Fawzi Noman Page: 19

ROUTINGS: A routing is a description of which operations (process steps) that must be

©2010 Ross Quarles and Fawzi Noman Page: 20

Assignment of Materials to be Produced and Material Components

Data in work centers are used for:

The following graphic illustrates the use of work center data.

©2010 Ross Quarles and Fawzi Noman Page: 21

©2010 Ross Quarles and Fawzi Noman Page: 22

A planned order has the following characteristics:

Automatic Creation of Planned Orders