FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx

FOR ACADEMIC USE ONLY
ALL MATERIALS FROM SAP LIBRARY ADAPTED
WITH PERMISSION OF SAP AMERICA UNIVERSITY
ALLIANCE
©2013 Ronny Daigle, Fawzi Noman, and Ross Quarles Page: 1
Classic Rockers Case
Student Text
(MM, PP, SD, FI/CO)
Classic Rockers Case:
Processing Transactions through the
Logistics and Support Processes of SAP with an
Emphasis on Internal Control
Ronny Daigle
Fawzi Noman
Ross Quarles
Version 1.0
6/1/2013

Sam Houston State University
Huntsville, Texas
Acknowledgements: The authors thank Kimberly Omura, Chris
McMillan and Matt
Williams for helpful edits of this case.
ALLIANCE
Table of Contents – Student Text
I. Chapter 1: Introduction
This chapter provides a general description of the case for
students and
introduction to basic SAP modules and terminology, business
processes, and types
of data. This chapter also provides an overview of basic internal
control concepts;
specifically those emphasized throughout all chapters of the

Case, such as control
objectives, separation of duties, preventive vs. detective
controls, and general vs.
application controls. Many of the internal control questions
asked throughout this
case will require students to refer back to material discussed in
this chapter.
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.
ALLIANCE
CHAPTER 1: Introduction to Case

Case Overview
Classic Rockers allows participants to process transactions and
learn fundamental internal
control concepts for sales logistics, production logistics,
procurement logistics, and
accounting/controlling. 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
Classic Rockers.
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
Classic Rockers 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, the
integration of the various processes with one another (i.e., an
organization’s value chain),

and fundamental internal control concepts specific to SAP. 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, how processing makes use of master data to process
transactions across the
value chain, and how internal control can help make information
more reliable and the value
chain more efficient and effective. These concepts, especially
internal control, are typically
covered in Accounting Information Systems courses.
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
Classic Rockers utilizes the five “basic” modules of SAP R/3 as
described in the following
table.

ALLIANCE
SAP
Module
Function (Process) Functional Areas
MM Materials Management
(Procurement Logistics)
Purchasing, invoice verification, inventory
management, warehouse management
PP Production / MRP
(Production Logistics)
MRP, production orders, bills of materials, work
centers, routing instructions, batch management
SD Sales and Distribution
(Sales Logistics)
Order entry, picking/packing/shipping, invoicing,
inquiries, quotes, sales reporting
FI Financial Accounting
(Support Process)

General ledger, A/R, A/PAY financial reporting, cash
management legal consolidation
CO Cost Accounting
(Support Process)
Cost accounting and internal reporting by cost center,
internal order, project, profit center, or other unit,
profitability analysis
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
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.

ALLIANCE
Passwords: Each user has a unique password. On the initial log
in to the system, the
user must change a generic delivered password to one chosen by
the user. 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 should
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.
SAP also produces a
separate application enhancement called Governance Risk and
Controls, which can
identify compatible and incompatible duties with a color
coding. This application is not

part of the software you are using, but know that organizations
use it to properly define
roles.
In the Classic Rockers 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 control and separation of duties. The
concept of separation
of duties will be discussed later in this chapter, and emphasized
through certain
internal control questions you may be asked by your instructor
at the end of each
case.
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 Classic Rockers
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
ALLIANCE
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 chain. 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 Classic
Rockers 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 Classic
Rockers 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 Classic
Rockers 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.
ALLIANCE
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 Classic Rockers
contains exercises that
require the processing of transactions through the particular
process.
Internal Control
Internal control is an essential and fundamental element in any
system for it to operate
efficiently and effectively. The primary focus of internal control
in this case is that in an
accounting information system (AIS). To appreciate internal
control, it is first important to

appreciate the concept of an AIS. This section provides an
overview of what is meant by an
AIS and its integral components, which includes internal
control. It also provides an overview
of typical control objectives and internal control procedures,
particularly application controls
that are present in SAP.
This and later sections of this chapter serve to summarize basic
fundamental concepts that
are discussed in commonly accepted internal control
frameworks, such as the Committee of
Sponsoring Organizations (COSO) Internal Control – Integrated
Framework, and numerous
AIS textbooks.1 Your instructor may have you refer to such
discussion in conjunction with
that summarized here for fully appreciating these concepts.
To begin appreciating what is meant by an AIS, it is important
to first appreciate what is
meant by a system, and then what is meant by an information
system. A system is a set of
interrelated components working together to achieve a common
purpose or set of objectives.
1
As an example of how the information discussed in this and
later sections summarizes and can complement a
more thorough discussion found in AIS textbooks, citation
references are provided on remaining pages of this
chapter to certain information contained in Accounting
Information Systems by Romney and Steinbart (11
th

Edition). Similar information to the cited information can be
found in a number of other commonly used AIS
textbooks,
ALLIANCE
With a focus on information as the purposeful outcome or
objective of a system, an
information system is a set of interrelated components working
together to collect and
process data into reliable information for decision-makers. With
a further focus on accounting
information, the data collected and processed into information
is that from economic and
financial events. Economic and financial events are not just
those that give rise to recognition
in an organization’s financial statements per Generally
Accepted Accounting Principles
(GAAP), but events that lead up to and follow such GAAP-
related events.
For example, the receipt of an order of goods is an event
requiring recognition in the financial
statements per GAAP. While the purchase order placed for those
goods received is not

recognized in the financial statements per GAAP, it is an
important economic event for which
data must be collected and processed for ensuring the later
event of receiving is proper. Why
is this so? It is so because the purchase order authorizes the
receipt of goods. The lack of a
purchase order should result in no receipt, and therefore no
recognition of the receipt in the
financial statements.
To bring together the concepts of a system, information and
accounting, an AIS is therefore a
set of interrelated components working together to collect and
process data from economic
and financial events into information that is useful to decision-
makers.
AIS Components and Objectives
In general, an AIS is comprised of the following basic
interrelated components (Romney and
Steinbart, 2009):
People who design, implement, manage, operate and maintain
the AIS
of SAP data in the
previous section)
processing

Formal and documented procedures to be performed for
collecting and processing
data into information (the exercises in the cases can be thought
of as formal
procedures, for example)
er on which you
complete these exercises and
the server on which SAP resides)
generating information, and
safeguarding assets and data
These components are interrelated, meaning that the failure of
one will likely lead to the
failure of one or more objectives of the system. For example, if
there is a lack of formal and
documented procedures for training those who must collect and
process data, then the
information generated will have diminished value to decision-
makers, leading to poor
ALLIANCE

decisions. As another example, internal control should be
formally documented as part of the
procedures for helping people and each process within a system.
While people are arguably
the most important component of any system because people
design, implement, manage,
operate and maintain all parts of the AIS, the failure of any
component will result in the failure
of the entire system.
In general, there are three basic objectives of an AIS (Romney
and Steinbart, 2009):
l events
-makers
generating information,
and safeguarding assets and data
Just as the components of an AIS are interrelated, so are these
basic objectives. If one
objective is not met, the other objectives will likely not be met.
Note that internal control is a
basic component of an AIS, as well as its inclusion as a basic
objective for helping collect and
process data and generate information for decision-makers.

While each organization has
unique objectives specific to their business activities, every
organization’s accounting
information system has the generic objective of providing
internal control over data,
information, and assets.
Internal Control Objectives
Just as internal control is part of a system, internal control is
also a system comprised of
interrelated components that meet certain internal control
objectives. The COSO Framework
describes internal control as a process implemented by an
organization’s management that
provides reasonable assurance that certain objectives will be
met:
The objective of reliable financial reporting can be broken down
further into common
transaction-related control objectives for greater appreciation of
just what is meant by
“reliable financial reporting” (Romney and Steinbart, 2009):
perly authorized (i.e., should
have occurred).

been posted in the
records).
ALLIANCE
©2013 Ronny Daigle, Fawzi Noman, and Ross Quarles Page:
10
correct account; amounts,
including any necessary reevaluations; dates; etc. being updated
in records).
These transaction-related internal control objectives not only
seek to ensure reliable financial
reporting, but also seek to safeguard assets and data from loss
or theft, as well as make
business operations more efficient and effective through the
information generated for
making decisions. Just as both the components of an AIS and
internal control objectives are
interrelated, respectively, so are these objectives. Failing to

record transactions accurately
will likely result in lost or stolen assets, thereby making
operations less efficient and effective.
While these control objectives help enhance the processing of
transaction data, please
recognize that these control objectives are also applicable to
master data, which is used for
processing transactions. Just as transactions should be properly
authorized, valid, recorded,
and accurate, so should master data. Further, meeting these
control objectives over master
data will also enhance the safeguarding of assets and data from
loss or theft, as well as
make business operations more efficient and effective through
the information generated for
making decisions. This is because the master data are being
used to properly process
transactions.
It is important to appreciate the emphasis on “reasonable
assurance” in COSO’s description
of internal control. This means that internal control is not
perfect and absolute, but is to be
reasonable for helping meet its objectives. Just what is
“reasonable” is very subjective within
any particular organization. It is the responsibility of an
organization’s management to identify
risks and respond appropriately with control procedures for
helping provide reasonable
assurance.
Internal control can only provide reasonable assurance because
there are certain inherent
weaknesses in any system of internal control. These include
management override of

controls, collusion amongst people with incompatible duties and
human error. The cost of a
control in comparison to risk minimization can also be a
prohibitive factor when designing
internal control. For these reasons, there is no full-proof system
of internal control.
Internal Control Components
COSO identifies five interrelated components of internal control
for helping meet internal
control objectives:
– The tone at the top of an organization;
management’s
philosophy and operating style; the board of directors;
management’s commitment to
integrity and ethics; management process and human resource
standards
– Proper identification, response and
management of risks that can
impede or prevent operational objectives from being met
– Policies and procedures that help address
risks and meet
objectives

ALLIANCE
11
– Review and response to how internal control is
meeting risks and
meeting objectives; includes internal audit activities
– Gathering information
about internal control and
communicating it to management and employees provides
feedback on what is being
done successfully and what is not, so that improvements can be
made for managing
risks and meeting objectives
The most important component or foundation of internal control
is the control environment.
This is because it is management driven, and management is
responsible for an
organization’s internal control. In other words, internal control
begins with management and
its attitude and objectives. With respect to internal control
activities, there are two basic
categories:

All internal control activities stem from these two basic
categories. An organization’s audit
trail is comprised of the data and records of activities that are
discussed previously in this
chapter. Careful attention to the exercises throughout this case
will show the importance of
the audit trail and how it is captured in SAP, particularly
through the integration of data.
Proper design of a database information system such as SAP,
including its tables and
relationships between tables based on proper primary and
foreign key identification and
implementation, helps assist in the creation of a reasonable
audit trail of integrated data and
activities.
Not only is it important to design a system to collect and
process data and generate
information with reasonable assurance, it is important to assign
various tasks in a way so that
errors and fraud are minimized. This is the concept of
separation of duties, which is referred
to previously in this chapter when discussing Roles and
Profiles. For a particular type of
transaction and related assets and records, four types of duties
should be separated so that
errors and fraud are minimized:

For example, it is inappropriate to allow the same individual to
update vendor master records
(authorization) and record vendor activity such as vendor
invoices. Doing so would allow the
individual to manipulate a vendor’s records, such as the
vendor’s address to his/her own, and
record a fictitious invoice to that vendor, thereby increasing the
risk of fraud through a
fictitious check disbursement. As another example, the person
who takes the deposit to the
bank (custody) should not reconcile the bank statement to the
general ledger. This person
ALLIANCE
12
could steal from the deposit and more easily hide the theft
because he/she is the one who
performs the reconciliation.
Proper separation of duties does not simply mean that no person
can perform two different

types of duties. The duties must not be related to the same type
of transaction and related
asset and records. For example, it is proper to allow an
individual to process payroll
transactions (recordkeeping) and update vendor master records
(authorization). This is pair is
compatible as opposed to the recordkeeping-authorization pair
given above dealing with
vendors. Similarly, it is proper to allow a person to handle the
bank deposit (custody) while
reconciling the fixed asset records to the general ledger. This
pair is also compatible, unlike
the custody-reconciliation pair given above dealing with cash
transactions.
As noted previously, students will have access to areas in SAP
that they would (or should)
not have if they were assigned a position within an actual
organization. Having access to
many areas allows students to appreciate the integration of
activities and audit trail in SAP. At
the same time, students should appreciate which activities are
compatible and incompatible
with others. Your instructor may seek to emphasize this concept
by assigning certain internal
control questions throughout the case.
Preventive vs. Detective Controls
A common dichotomy of internal control activities is
categorizing them as either a preventive
or detective control. Preventive controls deter errors or fraud
from occurring/updating to
records. Detective controls identify errors or fraud that has
occurred/updated records. For
example, proper separation of duties is a preventive control,

while reconciliation of a bank
account to the general ledger is a detective control. While
Benjamin Franklin’s adage that “an
ounce of prevention is worth a pound of cure” indicates that
preventive controls are
preferable, an organization should have a combination of both.
Referring back to the two
examples provided above, the bank reconciliation is one of the
most crucial and basic
controls in any organization, but if given to an individual with
an incompatible duty, the control
procedure is weakened.
As an aside, some AIS textbooks identify a third category of
controls, corrective controls.
Corrective controls are procedures performed after discovery of
an error or fraud. For
example, a disaster recovery plan (such as data back-up) is
described by some textbooks as
a corrective control. However, it can also be described as a
preventive control because it
seeks to prevent loss of data and interruption of operations.
This case focuses solely on the
dichotomy of preventive vs. detective controls.
General vs. Application Controls
Another common dichotomy of internal control activities are
general vs. application controls.
General controls are broader and extend over the organization
and its AIS, such as disaster
recovery procedures. Application controls are more specific to
particular transactions and
focus on proper data entry, processing, and output. Students
will encounter numerous
instances of automated data entry and processing application

controls in SAP, including
(Romney and Steinbart, 2009):
ALLIANCE
13
– Seeks to ensure that all required data
has been entered
before a transaction is recorded or record updated. For example,
some may have
encountered when processing a purchase online at a website that
a message
prompted the person that he/she has not entered all required
data, such as an address
or phone number. Reflecting back on the common transaction-
related control
objectives, depending on the attribute a completeness check can
help enhance that a
particular transaction or record is recorded, or a transaction or
record is recorded
accurately. When controlling a primary key attribute, such a
check is helping make
sure a transaction is recorded because the primary key is the
attribute upon which the
record is based for recording. When controlling a non-key or
secondary attribute of a
transaction, such a check is helping make sure it is recorded

more accurately.
– Determines if the characters in a field are the
proper type, such as
numeric, alpha/numeric, zip code, etc. before a transaction is
recorded or record
updated. A field check typically helps enhance that data is
recorded accurately
because it seeks to make sure the value entered is of the correct
character type.
– Tests a numerical amount in a field against an
upper or lower
predetermined value before a transaction is recorded or record
updated. For example,
a customer should have a credit limit entered in their master
record, and the
combination of the customer’s outstanding accounts receivable
balance and sales
orders should not exceed the pre-established credit limit. As
another example, if
employees can only work 40 regular hours a week and are paid
bi-weekly, a limit
check would prevent an input of more than 80 regular hours for
payroll. Assuming all
data had been input properly in the first example, the limit
check is helping enhance
that a particular transaction is properly authorized. Assuming
that an error had been
made in the second example, the limit check is helping enhance
that a particular
transaction is recorded accurately.

– Like a limit check but includes both an upper
and lower limit on a field.
For example, an organization may require a certain minimum
value of items to be
ordered, but a certain maximum value before a special
authorization is required. A
range check would make sure the minimum was met and
whether special
authorization is required. Assuming all data had been input
properly in this situation,
the range check is helping enhance that a particular transaction
is properly authorized
because it is making sure that it should occur.
– Determines the correctness or logic of
a relationship between
two or more data items before a transaction is recorded or
record updated. For
example, it could be considered unreasonable for a particular
category of employee to
be paid a certain salary. For example, it is unreasonable for an
administrative assistant
to have a salary of $25,000 per month, while it is more
reasonable for someone in
executive management to have such a salary. The relationship
between employee
category and salary is considered illogical. Assuming an error
had been made in
entering an administrative assistant’s salary in the master
records in this situation, the
reasonableness test is helping enhance that the master record is
recorded accurately,
and therefore related transactions.

ALLIANCE
14
– Determines if the data entered has the
appropriate sign before a
transaction is recorded or record updated. For example, an
individual may be entering
a transaction in the general ledger. If the transaction requires
the reduction of an asset
account, the individual may try entering a negative value in the
field. However, if the
screen is designed with a field for debits and a field for credits,
no negative value is
necessary, with the value entered in the credit field. In this
situation, the sign check is
helping enhance that a particular transaction is recorded
accurately.
– Determines that the data being input will fit into
the assigned field before
a transaction is recorded or record updated. For example, a
standard zip code field
should only allow five digits to be input. As a real-life example
of where a size check
(or a limit check) would have been highly appropriate, an
individual purchased a pack

of cigarettes with his debit card and was charged a “17-digit
number – a stunning
$23,148,855,308,184,500 (that is twenty-three quadrillion, one
hundred forty-eight
trillion, eight hundred fifty-five billion, three hundred eight
million, one hundred eighty-
four thousand, five hundred dollars).”
(http://www.huffingtonpost.com/2009/07/15/man-
charged-23-quadrillio_n_233286.html). The individual spent
two hours on the phone
trying to correct it, as well as having the $15 overdraft charge
reversed. In these
examples, the size check is helping enhance that a particular
transaction is recorded
accurately.
– Compares the data entered into a field for
either a transaction or
master record to that in a field of another master record to
verify the data entered
exists. Common examples of this would be primary keys such as
customer number,
vendor number, employee number, inventory item number, store
number, plant
number, etc. Other examples would be predetermined values
such as state and
currency abbreviations. The validity check is helping enhance
that a particular
transaction is recorded accurately by seeking to ensure the value
entered does exist.
-loop verification – Similar to a validity check except
it retrieves and displays
other data related to the data that has been entered before a

transaction is recorded or
record is updated. For example, upon entering a customer
number on an input screen,
SAP may show the customer name of the customer number
entered. This application
control not only helps ensure that a valid data item has been
entered, but the desired
data item has been entered. Closed-loop verification is helping
enhance that a
particular transaction is recorded or record updated accurately
by seeking to ensure
that correct and valid data has been entered.
-balance test – Compares numerical data entered to a
pre-determined number
for ensuring accuracy. For example, when entering a transaction
in the general ledger,
debits should equal credits. If not equal, SAP will not allow
posting. The zero-balance
test is helping enhance that a particular transaction is recorded
accurately.
Each of these application controls is present in SAP. Careful
attention throughout the
exercises will help gain an appreciation for them. Students may
make data entry mistakes at
times in these exercises, and such application controls as these
are in place to help make
sure the mistakes are not recorded. Careful study of these
application controls shows that
application controls are generally a preventive control
automated in the system.
http://www.huffingtonpost.com/2009/07/15/man-charged-23-

quadrillio_n_233286.html
http://www.huffingtonpost.com/2009/07/15/man-charged-23-
quadrillio_n_233286.html
ALLIANCE
15
Earlier discussion noted that control objectives regarding proper
authorization, validity,
recording and accuracy are applicable for both transaction data
and master data. Many
application controls are useful for enhancing the reliability of
both transaction data and
master record data.
As a further observation, note that with each application control
description and examples, an
explanation is given that links the application control to a
transaction-based internal control
objective specific to the example situation. It is important to
note “specific to the example
situation” because an application control may help enhance one
particular objective in one
situation, but another objective in another situation because of
how implemented and used.
Controls that help enhance multiple objectives at once, or are
flexible across transaction
situations to help enhance differing objectives are valuable

controls, generally more so than
controls that do not.
Another observation to be noted is that explanations refer to
how the control “helps enhance”
a particular control objective. The use of “helps enhance” is
meant to indicate that the risk of
failing to meet the control objective has been reduced but not
eliminated. As mentioned
previously, there are certain inherent weaknesses in every AIS,
as well as cost-benefit
considerations. Risk, therefore, exists in every AIS, and it is a
matter of determining the level
of risk a company is willing to assume (COSO refers to this as
an organization’s “risk
appetite”).
As one final observation about control activities and control
objectives, internal control is not
meant to be “red tape” but is meant to help meet specific
objectives. One should be able to
explain why a control procedure is being performed by linking
it to one or more control
objectives in the given situation. If an individual cannot explain
a control procedure in terms of
a desired control objective, the individual either does not
understand the purpose and value
of the control (which is either due to a failure of training the
employee or the employee being
unable to grasp the value) or the control fails to have value by
not meeting one or more
control objectives.
To summarize much of this discussion on internal control, it is a
key element in any system,
especially in an AIS. Internal control helps:

-
makers
ata from loss or theft
Understanding these objectives and particular sub-objectives
(such as at the transaction
level), helps provide an appreciation for procedures that exist in
SAP (such as application
controls) for helping ensure that the exercises performed are
done so efficiently and
ALLIANCE
16
effectively. These internal control concepts should be kept in

mind when reading later
chapters and completing related exercises of this case.
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.
Romney, M. B. and P. J. Steinbart. 2009. Accounting
Information Systems. 11th ed. Upper
Saddle River, NJ: Pearson Prentice Hall.
SAP Help Portal. <http//help.sap.com>
ALLIANCE
17

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 integration of data
improves the efficiency and effectiveness of the value chain
within an organization.
The graphic below identifies the process flows and master data
requirements for procurement
logistics processing.

Vendor Data: Vendors are business partners that are suppliers
of materials or services to
the firm. While vendors can be internal (components of the
same company), the vendors in
this case are external – parties that are independent entities that
are not affiliated with or a
part of Classic Rockers. 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 is,
the primary key value), 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
Vendor
Data
Invoic
e
Goods
Purch
asing
Purch
ase
Materia
l Data

ALLIANCE
18
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. This is because the vendor number is a foreign key
in both the purchase order
table and payables table (vendor subsidiary records).
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.
Valuation and costing/price calculation information. Examples:
Standard price, past
and future price, and current valuation.
ALLIANCE
19
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.
Data provided by Purchasing for a material. Examples:
Purchasing group (group of
buyers) responsible for a material, over- and under-delivery
tolerances, and the order
unit.
Engineering and design data on a material. Examples: CAD
drawings, basic
dimensions, and design specifications.
Information relating to the storage/warehousing of a material.
Examples: unit of issue,
storage conditions, and packaging dimensions.
Information for predicting material requirements. Examples:
How the material is
procured, forecasting period, and past consumption/usage.
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 (capture in the primary key field) 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 stock-keeping
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,
ALLIANCE
20
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. Documentation of the request helps enhance the
transaction-related control objective
that a particular transaction is properly authorized because it
helps support that the eventual
purchase order placed should have occurred.
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. This
integration helps enhance the transaction-related control
objective that a particular
transaction is recorded accurately.
Purchasing (Purchase Order)
A purchase order is a legally binding instruction from a
purchasing organization to a vendor
to deliver 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.
Similar to the purchase requisition, the purchase order helps
enhance the transaction-related
control objective that a particular transaction is properly
authorized because it helps support
that the eventual receipt, invoicing and payment from vendor
should have occurred.
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
ALLIANCE

21
placement of the material into storage (stock put-away), 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 (thereby
maintaining an audit trail), for the following reasons:
ether the delivery is from an
actual purchase order
(typically through reference of the purchase order number on
the vendor’s receiving
report that accompanies the goods). This checking helps
enhance the transaction-
related control objective that a particular transaction is properly
authorized.
entry of the goods
receipt (for example, the material ordered, its quantity, and so
on). This integration of
data in SAP therefore simplifies both data entry and checking
(over- and under-
deliveries). This integrating data feature in SAP helps enhance
the transaction-related
control objective that a particular transaction is recorded
accurately. This integrating
data feature is not only present here, but in other instances such

as when creating the
invoice receipt (see later discussion in this chapter).
allows the Purchasing
department to monitor the purchase order history and initiate
reminder procedures in
the event of a late delivery. This feature helps enhance the
transaction-related control
objective that a transaction is recorded, as well as recorded
accurately because the
integration of data reduces data entry errors.
and the delivered quantity.
This feature helps enhance the transaction-related control
transaction is properly authorized, as well as being valid (the
invoice is valid because
an authorized receipt took place).
order price or the invoice
price. This feature helps enhance the transaction-related control
objective that a
particular transaction is recorded accurately.
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 (thereby enhancing the

transaction-related control objective
that a particular transaction is recorded accurately) 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. This requirement helps
enhance the transaction-related
control objective that a particular transaction is recorded
accurately.
Goods receipts for the warehouse can be posted to three
different stock types:
-use stock: stock located in the warehouse that
is not subject to any
kind of usage restrictions.
ALLIANCE
22
but is in the process of
incoming quality inspection and which has not yet been released
for unrestricted use.

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 (thereby enhancing the transaction-related
control objective that a
particular transaction is recorded accurately). 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.
The automatic creation of these records helps enhance the

transaction-related control
objective that a particular transaction is recorded. Further, by
using the same data
which reduces data entry errors, the automatic creation of these
records also helps
enhance the transaction-related control objective that a
particular transaction is
recorded accurately.
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:
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.
for consumption,
only the consumption statistics are updated in the material
master record.

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.
ALLIANCE
23
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 storage location is allowed for
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. This feature
helps enhance the transaction-related control objective that a
particular transaction is
recorded. Further, by using the same data which reduces data
entry errors, this
feature also helps enhance the transaction-related control
transaction is recorded accurately. 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
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, the posting date of the goods receipt,
and which
user(s) recorded/updated the purchase order.
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:
requirements reduction in
materials planning
Management System
As noted a number of times in this section, there are many
instances of automatic
posting/updating of records in SAP. As a point worth
emphasizing, such automatic
positing/updating helps enhance the transaction-related control
objective is that a particular

ALLIANCE
24
transaction is recorded, as well as recorded accurately because
of the integration of data
when posting/updating.
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:
rials procurement process - which starts
with the purchase
requisition, continues with purchasing and goods receipt, and
ends with the invoice
receipt

procurement (for example, services,
expenses, course costs, etc.) to be processed
cancellations to be processed
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:
prices, and arithmetic
ount postings resulting from an invoice
and material prices
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.
As can be seen by this discussion, the use of purchase order
data at the time of invoice
receipt helps enhance the transaction-related control objective is
that a particular transaction
ALLIANCE
25
is recorded accurately. The integration of data in SAP allows
this capability, and is used at
other times, such as when creating the data for the purchase

order based on data from the
purchase requisition, as well as when creating the data for the
goods receipt based on data
from the purchase order.
If variances exist between the purchase order and goods receipt
based on amounts or goods
receipt and the invoice based on price, 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.
The use of tolerance limits helps provide dual consideration of
both accurately recording a
particular transaction (a transaction-related control objective)
and promoting efficient and
effective operations (an internal control objective) by allowing
some tolerance so that
activities do not get halted by some acceptable difference that
can then be investigated.
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. Similar to previous discussion about
automatic posting, this feature helps
enhance the transaction-related control objective that a
particular transaction is recorded, as
well as recorded accurately. 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.
: With purchase-order-
based Invoice Verification,
items that have been ordered and received 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.
-receipt-based
Invoice Verification, each
individual goods receipt is invoiced separately.
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.
ALLIANCE
26
Procurement Logistics Master Data and Transaction Exercises
for Classic Rockers
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.
Classic Rockers 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. While not used in these exercises, the GR/IR account
can still be used for better
tracking services that occur over long periods of time.
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
Classic Rockers, 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.
ALLIANCE

27
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, within tolerance
limits. 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.

ALLIANCE
28
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, the production method of materials requirement
planning (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
ALLIANCE

29
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

ALLIANCE
30
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 (BOM) 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 following graphic shows some components of a bicycle that
are included in a BOM.
2
For a full discussion of material master records, see
Procurement Logistics.
ALLIANCE
31
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).

ALLIANCE
32
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:
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:
- Operating times and formulas are entered in the
work center, so that the
duration of an operation can be calculated.
- 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.
- The available capacity and formulas for
calculating capacity
requirements are entered in the work center.
- Various default values
for operations can be
entered in the work center.
The following graphic illustrates the use of work center data.

ALLIANCE
33
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:
ta
System (HR))

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.

ALLIANCE
34
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:
coverage, that is, an internal
planning element. It is not binding and does not trigger
procurement directly; it serves
for planning purposes only.
orders for direct
production and for direct procurement).
-house or
procured externally is left open.
uced in-house, it represents the pegged

requirement for dependent
requirements and can be used in the capacity calculation.
-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
3
Outline agreement on the basis of which materials are procured
at a series of predefined points in time over a
certain period.
ALLIANCE
35
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
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:
data (quantities, dates, account assignment, material
data, procurement data,
etc.), and
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

ALLIANCE
36
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:
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:
sts
Production orders can be generated in the following ways:
conversion of a planned
order to a production order)

ALLIANCE
37
manually
When a production order is created the following actions are
carried out:
transferred to the order
material are transferred to
the order
ions4 are generated for bill of material items held in
stock

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

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx

Recommended

Recommended

More Related Content

Similar to FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx

Similar to FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx (20)

More from budbarber38650

More from budbarber38650 (20)

Recently uploaded

Recently uploaded (20)

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED.docx