Accounting HW

zon5008

classic_rockers_case_-_student_text.pdf

Home >Business & Finance homework help >Accounting homework help >Accounting HW

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

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.

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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.

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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.

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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.

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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.

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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

Edition). Similar information to the cited information can be found in a number of other commonly used AIS textbooks,

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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

 Data that is collected and processed (see discussion of types of SAP data in the previous section)

 Information that has been generated from data collection and 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)

 Software (such as SAP)

 IT infrastructure (such as the computer on which you complete these exercises and the server on which SAP resides)

 Internal control over data collection and processing, 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

FOR ACADEMIC USE ONLY ALL MATERIALS FROM SAP LIBRARY ADAPTED WITH PERMISSION OF SAP AMERICA UNIVERSITY 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):

 Collect and process data from economic and financial events

 Generate information for decision-makers

 Provide internal control over data collection and processing, 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:

 Reliable financial reporting

 Efficient and effective operations

 Compliance with laws and regulations 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):

 A particular transaction is properly authorized (i.e., should have occurred).

 A particular transaction is valid (i.e., did occur).

 A particular transaction is recorded (i.e., the transaction has been posted in the records).

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

 A particular transaction is recorded accurately (such as 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:

 Control environment – 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

 Risk assessment – Proper identification, response and management of risks that can impede or prevent operational objectives from being met

 Control activities – Policies and procedures that help address risks and meet objectives

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

 Monitoring – Review and response to how internal control is meeting risks and meeting objectives; includes internal audit activities

 Information and communication – 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:

 Audit trail of activities

 Proper separation of duties 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:

 Authorization

 Custody

 Recordkeeping

 Reconciliation 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

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

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

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

 Completeness check – 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.

 Field check – 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.

 Limit check – 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.

 Range check – 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.

 Reasonableness test – 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.

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

 Sign check – 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.

 Size check – 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.

 Validity check – 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.

 Closed-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.

 Zero-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

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

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:

 Improve data collection and processing

 Enhance the reliability of information generated for decision-makers

 Safeguards assets and data from loss or theft

 Operations be more efficient and effective

 Comply with laws and regulations 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

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

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>

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

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

Goods

Purch asing

Purch

ase

Materia l Data

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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:

 Goods receiving can check whether 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.

 The system can propose data from the purchase order during entry of the goods receipt (for example, the material ordered, its quantity, and so on). This 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).

 The delivery is marked in the purchase order history. This allows the Purchasing department to monitor the purchase order history and initiate reminder procedures in the event of a late delivery. 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.

 The vendor invoice is checked against the ordered quantity and the delivered quantity. This feature helps enhance the transaction-related control objective that a particular transaction is properly authorized, as well as being valid (the invoice is valid because an authorized receipt took place).

 The goods receipt is valuated on the basis of the purchase 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:

 To unrestricted-use stock: stock located in the warehouse that is not subject to any

kind of usage restrictions.

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

 To stock in quality inspection: stock that has been received but is in the process of incoming quality inspection and which has not yet been released for unrestricted use.

 To blocked stock: stock that is present in the company but, for various reasons, is not to be used and cannot be classified as unrestricted.

The purchase order data can define whether or not the material is to be posted to stock in quality inspection (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:

 Goods receipt into the warehouse: If the goods are destined for the warehouse,

the system increases total valuated stock and the stock type (for example, the unrestricted-use stock) by the delivered quantity. The stock value is updated at the same time.

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

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

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

 Goods receipt into a new storage location: If goods are posted into a storage

location that does not yet exist for this material, the storage location is automatically created in the material master record when the goods receipt is posted (if automatic creation of 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 objective that a particular 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: During goods receipt posting, a purchase order history

record is automatically created. This record contains data essential for Purchasing, such as: the delivered quantity, the material document number and item, the movement type, the posting date of the goods receipt, and which user(s) recorded/updated the purchase order.

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

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

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

materials planning

 Statistical data in Inventory Controlling

 Vendor evaluation data in Purchasing

 Transfer requirements and quantities in the Warehouse Management System

 Inspection lots in Quality Management

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

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

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:

 It completes the materials procurement process - which starts with the purchase

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

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

 It allows credit memos, such as discounts, and invoice 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:

 Entering invoices and credit memos that have been received

 Checking the accuracy of invoices with respect to contents, prices, and arithmetic

 Executing the account postings resulting from an invoice

 Updating certain data in the SAP system such as open items and material prices

 Checking invoices that were blocked for payment because they varied too greatly from

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

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

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.

 Invoices based on purchase orders: 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.

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

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

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

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.

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

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.

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

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

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

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

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

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.

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

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

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

Assignment of Materials to be Produced and Material Components

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

 Machines, machine groups

 Production lines

 Assembly work centers

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

 Scheduling - Operating times and formulas are entered in the work center, so that the

duration of an operation can be calculated.

 Costing - Formulas are entered in the work center, so that the costs of an operation can be calculated. A work center is also assigned to a cost center.

 Capacity planning - The available capacity and formulas for calculating capacity requirements are entered in the work center.

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

The following graphic illustrates the use of work center data.

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

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

 Basic Data

 Assignments (to cost centers, Human Resource Management System (HR))

 Capacities

 Scheduling

 Default values

 Hierarchy

 Technical data

Work centers are assigned to operations in task lists. If default values in a work center are changed, the changes are effective in the task list if a reference indicator has been set for the default value. Work centers can be arranged in hierarchies. These are important in capacity planning. Hierarchies are used to cumulate available capacities and capacity requirements in a hierarchy work center. A Logistics work center can be assigned to either an organizational unit or a work center in the Human Resource Management System (HRMS). Assignments to other HR-objects such as employees, qualifications, or specifications can be maintained using the HR work center.

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

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

In the case of external procurement, the system creates either planned orders or directly creates purchase requisitions. Procurement proposals for external procurement plan the external procurement quantity. Once the MRP controller is satisfied with the results of planning, the planned orders are converted into purchase requisitions or the purchase requisitions are converted into purchase orders and passed on to the purchasing department. Purchase orders are also fixed elements, which must be followed. If a planned order in external procurement is created first, the MRP controller has more control over the procurement proposals. Only when the MRP controller has checked the planned orders and converted them into purchase requisitions can the purchasing department order the material. Otherwise, the purchase requisition is immediately available to the purchasing department, which then takes over responsibility for material availability and warehouse stocks. The creation indicator for purchase requisitions in the initial screen of the planning run controls whether the system is to create purchase requisitions immediately or whether it is to create planned orders first. If a scheduling agreement3 exists for a material and if an entry exists in the source list that is relevant to MRP, the user can also instruct the system to create delivery schedules in the planning run. A planned order is sent to a plant and is an MRP request for the procurement of a particular material at a determined time. It specifies when the inward material movement should be made and the quantity of material that is expected. A planned order has the following characteristics:

 It is a procurement proposal in MRP for requirements coverage, that is, an internal

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

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

 Whether a material will later be produced in-house or procured externally is left open.

 For materials produced in-house, it represents the pegged requirement for dependent requirements and can be used in the capacity calculation.

 For materials produced in-house, it specifies the basic dates for production. Planned orders are converted into production orders for in-house production and into purchase requisitions for external procurement. In contrast to planned orders, production

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

certain period.

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

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:

 Order data (quantities, dates, account assignment, material data, procurement data, etc.), and

 Component overview.

Conversion of Planned Orders to Production Orders Planned orders are created in material requirements planning to meet production requirements. Planned orders represent a demand to procure or produce a material. Planned orders for materials that are to be produced in-house are converted to production orders. The material components required for production are contained as items in the planned order and are copied directly when the planned order is converted to a production order. Planned orders are internal planning elements for planning purposes and do not trigger any procurements. The system only triggers procurement, once planned orders are converted

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

into fixed receipt elements such as purchase requisitions or production orders. Planned orders can be converted individually (one at a time) or collectively (several simultaneously). For materials that are to be produced in-house, the planned order is converted into a production order. Production orders are a fundamental part of Production Planning and Control (PP). PP is fully integrated in the Logistics (LO) component and has, among others, interfaces to:

 Sales and Distribution (SD)

 Materials Management (MM)

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

 What is to be produced

 When production is to take place

 Which capacity is to process the order

 How much production costs

Production orders can be generated in the following ways:

 From a requirement generated in requirements planning (i.e., conversion of a planned

order to a production order)

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

 Using an assembly order

 Without any previous requirement, that is, by creating it manually

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

 A routing is selected and its operations and sequences are transferred to the order

 The bill of materials is exploded and the items in the bill of material are transferred to the order

 Reservations4 are generated for bill of material items held in stock

 The planned costs for the order are generated

 The capacity requirements5 are generated for the work centers

 Purchase requisitions are generated for non-stock items and externally-processed operations

A production order specifies which material is to be produced, where it is to be produced, which operations are required, and on which date production is to take place. It also defines how the order costs are to be settled. As described in this procedure, production orders can be created manually without being previously requested. Alternatively, they can be automatically created by converting a planned order. During requirements planning (MRP run), planned orders are created at every BOM level to cover requirements. For materials produced in-house, a secondary requirement is also generated when the BOM is exploded, which is necessary for producing the end product or assembly. For externally produced materials, an ordering transaction is initiated when a purchase requisition is generated. Planned orders generated in the MRP run can be converted individually into production orders from the current stock/requirements list. Planned orders can also be grouped together by the MRP run and converted into production orders together. These production orders can be released together. In a partial conversion, a planned order is reduced in partial quantities into several production orders. Partial conversion is described separately. If, when converting the planned order, changes are made to the required quantity or if the basic finish date is changed, then a planning file entry is generated. When material requirements planning is executed again, the material and its components are planned again.

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

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

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

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

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

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

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



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

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

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

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

 Monday through Friday are working days.

 Saturday, Sunday and public holidays are non-working days.

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

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

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

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

Chapter 4: Sales Logistics (SD) Sales logistics is the business process through which an entity secures and processes orders from customers (sales order processing), initiates the delivery of products or the provision of services (outbound logistics), and bills the customer for products shipped or services rendered (billing). In SAP this process is located in the Sales and Distribution (SD) module. In order to carry out the sales logistics process, SD must access data on customers, be integrated with Materials Management (MM) in order to establish product delivery, and be integrated with Financial Accounting (FI) in order to provide data on receivables due from billings generated. The graphic below illustrates the various steps and interactions necessary in the SD process. To reiterate a point that has been mentioned in previous chapters, the integration of data within SAP helps make value chain activities more efficient and effective, and increases the reliability of information generated.

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

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

sales organization a customer can be supplied through several distribution channels. In addition, the material master data relevant for sales, such as prices, minimum order quantity, minimum quantity to be delivered and delivering plant, can differ for each sales organization and distribution channel. Several divisions can be assigned to a sales organization which is responsible for the materials or services provided. In the SAP R/3 System you can define a division-specific sales organization. For example, a rocking chair company may wish to have a “standard” division that sells consumer rocking chairs and a “competitive” division that sells competitive graded rocking chairs. Product groups (i.e., divisions) can be defined for a wide-ranging spectrum of products. For every division you can make customer-specific agreements on, for example, partial deliveries, pricing and terms of payment. Within a division you can carry out statistical analyses or set up separate marketing procedures. The graphic below illustrates the relationships between sales organization, distribution channel, and division. A given sale would be processed by the sales organization through one of the distribution channels and through one of the divisions within that distribution channel. This would allow performance to be specifically tracked, for example, of the sales of competitive grade rocking chairs through the wholesale distribution channel. A particular linkage between a sales organization, a distribution channel, and a division is described, for statistical analysis purposes, as a sales area in SAP.

Company Code

Classic Rockers

Distribution Channel:

Retail

Classic Rockers

Sales Organization

Standard

Division

Competitive

Division

Distribution Channel:

Wholesale

Competitive

Division

Standard

Division

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

An additional organizational relationship must be created between the sales organization and one or more company plants. A plant is a place where either materials are produced, or goods and services are provided. As a retail or wholesale site, it makes merchandise available for distribution and sale. It can be subdivided into storage locations, allowing stocks of materials to be broken down according to predefined criteria (for example, location and materials planning aspects). Linking a sales organization to one or more plants is logical because the plant is the location from where the products being sold come. When there is only one plant producing one product line, the situation is obvious. However, consider a furniture company with multiple plants that produce many product lines (e.g., rocking chairs, coffee tables, dining room sets, etc.). If a given sales organization sold one or more of these product lines it would, therefore, have to be linked to the appropriate plant as a product source. In order to process the delivery or shipment of products in SD, independent organizational entities defined as shipping points are created which are responsible for scheduling and processing deliveries to customers, as well as replenishment deliveries to the company’s own warehouses. A delivery is always carried out by one shipping point only. The shipping point depends on the following criteria:

 Delivering plant

 Type of shipping (for example, train, truck)

 Loading equipment necessary

Master Data in Sales Logistics A number of master data records must be created in order to permit processing of transactions with the sales logistics process. These records include the customer master data, product or material data from the SD view, and sales prices for products. CUSTOMER MASTER RECORD: Data on customers6 is important for both sales and distribution logistics and the accounting/controlling support function. In order to avoid data redundancy, accounting data and sales and distribution data are stored in one master record, the customer master record. A customer master record is created for customers with whom the company has business contacts. This master record contains all data necessary for processing the business transactions. A customer master record contains all data needed for business transactions and correspondence with the customer. This includes address data, shipping data, sales data, and data for invoice creation. Maintaining the master data correctly can greatly reduce the work needed to process transactions. This is because the master data are automatically copied into the transactions by means of such application controls as closed-loop verification. This integration of data helps enhance the transaction-related control objective that a particular transaction is recorded accurately because it reduces transaction data entry and therefore potential errors.

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

employees.

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

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

 General data are maintained for every customer, such as name, address and telephone number, communication, etc. Such data are identifiable only via the customer number, not via the number of the company code or the sales area. Maintaining the data is possible from both the accounting view and the sales and distribution view.

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

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

Only after entering the sales and distribution data for a customer can you process sales and distribution transactions for the customer (for example, a sales order). Also, you can only send an invoice to the customer if the data on the payer has been maintained from the financial accounting view. A customer business partner can be a natural or legal person who is directly involved in a business transaction with you. The following partner functions are defined in the system:

 Sold-to party - Person or company that places an order for goods or services. The

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

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

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

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

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

If a customer fulfills all functions at the same time, only one master record is necessary, in which all data required for these functions is entered. In this case you create a master record for the sold-to party. If the functions are divided among different companies, a corresponding number of master records are needed. In one master record you enter, for example, the address of the sold-to party for correspondence, in another one the address of the ship-to party for the delivery. Only in the customer master record of the sold-to party is a link between the individual partners established, and this is done by entering the customer number of the respective partners. Materials with the same basic attributes are grouped together and assigned to a material type. The material types primarily involved in SD are trading goods, finished products, services, and packaging material. The material type represents certain features of materials in the system, and has important control functions: the material type is used, among other things, to group field selection functions for a material, or to define the screen sequence, the type of number assignment and number ranges during material master record maintenance. Depending on the material type, company areas maintain different data screens. This screen selection applying specifically to an application is called a "view.” Trading goods are movable goods intended for commercial exchange. Trading goods are always bought and re-sold by the company. The material master record for trading goods, therefore, always contains purchasing data and sales data. Finished products are goods that are produced in-house by the company in the manufacturing process. These goods are created from raw materials through the production logistics process. Services are represented and managed in the SAP System as materials. Services are non-material goods that differ from other goods, particularly in that their production and consumption coincide. Services are generally regarded as non-transportable and non-stockable. Typical services are commercial services, transport services, bank and insurance services, goods from cultural organizations and the mass media, as well as services provided by the public security forces or the education and health sectors. Since services cannot be stored, a material master record of this material type does not contain inventory data or inventory management data. No fields for gross weight, net weight or unit of weight are included in the basic data for a service, as are for other material types. Packaging material includes all materials needed for packaging, for example, boxes or crates. All data and information entered for a material is stored in the data structure of the material master record. For sales and distribution, general data and sales and distribution data in the material master record are relevant. General data in a material master record is identical for every sales organization, plant and storage location. General data contains, for example, the material number that identifies it, the material description, units of measure, value, weight, volume and divisions. Sales and distribution data in a material master record is defined for a specific sales organization and distribution channel. The delivering plant, the assignment to the sales group, grouping terms for price agreements and sales texts, for example, are included in sales and distribution data. The fact that a material is linked to a distribution channel allows the material to be sold with different conditions through the various distribution channels.

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

Sales and distribution data are divided into data that depend on the sales organization and data that depend on the plant. Sales organization/distribution channel data includes the delivering plant, the sales unit, the minimum order quantity and the minimum delivery quantity. Plant data applies to a plant and all its storage locations. Examples of plant data are Material Requirements Planning (MRP) data, such as the safety stock quantity, the reorder level, or the shipping processing time. A material can be stored, transported and sold in various units of measure. In the SAP R/3 System, you can therefore define various units of measure which are maintained in the sales and distribution screens. However, you only need to maintain the fields of the units of measure if they deviate from the base unit of measure. If no other fields with units of measure are maintained, the system automatically takes the base unit of measure as a basis for its calculations. Stocks of a material are managed in the base unit of measure. All quantity movements in other units of measure are converted automatically by the system into the base unit of measure. As soon as units of measures other than the base unit of measure are used in a material master record, the system prompts you in a dialog box to enter a calculation factor to the base unit of measure, the so-called alternative unit of measure. Several alternative units of measure can be defined. If, for example, a product is managed in the base unit of measure "Piece" but is sold in the sales unit "Box", you must define the conversion factor. The alternative unit of measure can define, for example, that 1 box of this material contains 12 pieces. The unit of measure in which materials are sold is referred to as a sales unit (for example, piece or bottle). The delivery unit refers to the unit in which materials can be delivered. Only exact multiples of the delivery unit can be delivered. For example, with a delivery unit of 30 bottles, 30, 60 or 90 bottles can be delivered, but not 100 bottles. In sales logistics two different quantity specifications are used: the minimum order quantity and the minimum delivery quantity. The minimum order quantity refers to the minimum quantity the customer must order. A warning message appears if the minimum order quantity is not reached during order entry. The order can be entered in spite of the warning message. The minimum delivery quantity refers to the minimum quantity you must deliver to the customer. The minimum delivery quantity is automatically checked during delivery processing. A warning message appears during delivery processing if you enter a delivery quantity lower than the minimum delivery quantity. The delivery can be created in spite of this warning message. In a company that has multiple plants, the delivering plant refers to the plant from which the goods are to be delivered to the customer, within a specific sales organization and distribution channel. The plant can be automatically proposed by the system when processing a sales order, if it has been maintained in one of the master records. In order to better serve customers, a customer material information record can be created. The data in this record includes the customer-specific material number, the customer-specific material description, and customer-specific data on deliveries and delivery tolerances. If, for example, one of your customers uses a number for a material which differs from the number your company uses to identify it, you can store the material number used by the customer in the customer material information record. During order entry, items can be entered by specifying the material number used by the customer. The system will then relate the

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

customer’s material number to the material number used in your company for that product and access all of the pertinent data for that material. The use of a customer material information record shows how the respective AIS between the vendor and customer can be integrated for improving the efficiency and effectiveness of conducting business with one another. While the integration of data improves the efficiency and effectiveness of the value chain within an organization, this type of integration improves the supply chain between vendor and customer. SALES PRICES: Sales prices are the amounts that customers will pay for the materials or products sold to them without any consideration of discounts. Sales prices are defined by sales organization and distribution channel. For example, sales prices for the retail distribution channel would not be the same as those for the wholesale distribution channel. Prices must be related, of course, to each specific trade good or finished product that will be sold to customers. In some cases, however, a specific customer may receive a special price known as a customer specific material price. Transactions with that particular customer will use these specific sales prices rather than the general prices charged to others. In many sales transactions, the company will offer a customer a discount based on any number of criteria. The customer discount is established by sales organization and distribution channel. In many cases the discount is a percentage based on the total order value.

Sales Logistics Transaction Processing Although there are many variations, the basic process involved with sales transactions is to obtain information from a customer that desires to purchase a product, approve the sale to the customer, process the data within the company to locate/obtain/manufacture the product, deliver the product to the customer, and bill the customer for the order. For the purposes of this case, the flow of activities in this process will involve an inquiry from a customer, creation/processing of a sales order to fulfill that inquiry, deliver the material ordered, and bill the customer. A customer inquiry is a customer’s request to a company that they provide a quotation or sales information without obligation thereby representing actually a request for a quotation. An inquiry can relate to materials or services, conditions and, if necessary, delivery dates. The sales area that accepts the inquiry becomes responsible for further processing. The inquiry contains one or more items that contain the quantity of a material or service that the customer asked for. The inquiry usually also includes a desired delivery date. The inquiry is may be based on a customer’s purchase order or just be an informal request for information on the customer’s part about a vendor’s product. If based on a purchase order, the purchase order number can be obtained and entered as part of the inquiry, thereby serving to help enhance the transaction-related control objective that a particular transaction is properly authorized. This is because the purchase order serves to prove that the inquiry should have occurred. When processing the inquiry, the availability of the desired product is checked to determine when it can be promised for delivery. The response to the inquiry is valid for a specific period of time (as set up when processing the inquiry). In processing the inquiry, the system

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

accesses both the customer master record and the material master record for related sales data. In cases where there are frequently occurring material combinations and common delivery quantities associated with customer orders, data can be stored as an item proposal. This proposal forms a “template” that can be used when customers place orders that meet the established material combinations and delivery quantities. The order entry can be processed more efficiently using item proposals when an order is placed by a customer. An item proposal, containing the materials a customer usually orders, can be assigned to one or more customers. When using item proposals in the sales document, this item proposal is then proposed for selection. A sales order is created in the SAP system when a customer places an order. If the sales order is created with reference to a preceding document such as an inquiry, the initial data are copied into the sales order, thereby enhancing the accuracy of data in the sales order. If created independently (for example, no previous inquiry), the sales order is typically created by reference to data on the customer’s purchase order, which again authorizes the activity of the vendor. A sales order is a contractual agreement between a sales organization and a customer to supply materials or services in certain quantities. Sales orders can be processed in the SAP R/3 System differently, depending on your specific needs. In the simplest case, you can enter a sales order with several items in a single screen. The system automatically proposes data from the relevant master records:

 From the customer master record of the sold-to party, the system proposes sales,

shipping, pricing, and billing data. In addition, the system copies customer-specific master data about texts, partners, and contact people at the customer site.

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

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

1) Whether the material is available for the requested delivery date and if necessary, transfers the requirements to materials planning. Shipping deadlines and shipping points are determined in delivery scheduling. Assuming the data entered for the order is accurate, this inventory and delivery check is a preventive control that helps enhance the transaction-related control objective that a particular transaction is properly authorized. This is because the comparison is making sure that the inventory desired by the customer can be provided, and in what timeframe. It also seeks to

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

reduce the threat of inventory stockouts or shortages by providing the ability to immediately schedule production to meet customer needs.

2) If the system is so configured, a check of credit limits for the customer can be performed at the time the sales order is created. The proposed sales order plus other outstanding sales orders plus the outstanding accounts receivable balance owed by the customer is compared to the credit limit established for the customer. The age of the outstanding accounts receivable balance is also considered (i.e., past due balances may prevent a customer from making further purchases until payment is made). This credit limit check helps enhance the transaction-related control objective that a particular transaction is properly authorized. As a preventive control, it seeks to reduce the risk of uncollectible receivables that would have to be written off.

When you enter a sales order, you can only confirm the delivery of the goods for the required delivery date if the goods are available for all the necessary processing activities which take place before delivery. To meet that date the shipping department must ensure that freight forwarding or another shipping company is advised early enough so that sufficient time remains for packing and loading to be carried out. In addition, the procurement department must ensure that the production and purchasing departments are advised of inadequate stock quantities so that goods can either be produced punctually or ordered. Sales transfers the information on materials ordered as requirements to material requirements planning (MRP). Requirements are planned outward movements of stock. The transfer of requirements informs production that goods must be produced, or advises purchasing that purchase requisitions have been created for which purchase orders must be created and sent to the suppliers. This aspect of the sales order process continues to reiterate the importance of integrated data within SAP for helping achieve efficient and effective operations. A sales order can also be created under the provisions of a customer scheduling agreement. A customer scheduling agreement is an outline agreement with a given customer containing delivery quantities and dates. These are then entered as schedule lines in a delivery schedule. You can either create schedule lines when you create the scheduling agreement or you can create them later. You fulfill a scheduling agreement by creating the deliveries in the schedule as they become due on the transportation scheduling date. The system determines from this date when transport activities must be started to ensure that the requested delivery date is met. You process deliveries for a scheduling agreement in exactly the same way as you process a normal delivery. After you have carried out the delivery, the system updates the Delivered quantity field in the scheduling agreement item with the delivery quantity. As soon as the material availability date or the transportation scheduling date for a schedule line is reached, the schedule line becomes due for shipping. When you create an outbound delivery, you initiate shipping activities such as picking, packing, and transportation scheduling. A delivery is processed through one shipping point. Which shipping point carries out the processing for a delivery can be determined automatically during order processing or you can specify it manually in the order. The system carries out the following activities when an outbound delivery is created:

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

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

 Determines the delivery quantity of an item and checks the availability of the material

 Calculates the weight and volume of the delivery

 Calculates work expenditure

 Packs the outbound delivery according to the reference order

 Checks the delivery situation of the order and any partial delivery agreements

 Redetermines the route

 Adds information relevant for export

 Checks delivery scheduling and changes deadlines (if necessary)

 Assigns a picking location

 Carries out batch determination (if material is to be handled in batches)

 Creates an inspection lot if the material must pass a quality check

 Updates sales order data and changes order status You can make changes in a delivery after it is created if the delivery situation changes in any way. In addition, you can confirm picked quantities using the change function, or use the display function to access shipping information in a delivery. Order items or schedule lines that have identical shipping criteria are combined in one delivery. If data varies between items, for example, if a different ship-to party is defined for each item, two deliveries must be created for the order. Order items from different orders can be grouped together in one delivery provided that they have identical shipping criteria and that the sold-to party agrees. During order entry, each schedule line for an item can contain a requested delivery deadline. The goods should arrive at the customer on this date. At the order processing stage, the system can automatically schedule when the essential shipping activities such as picking, loading and transporting must be started so that the requested delivery date can be kept. The picking process involves taking goods from a storage location and staging the right quantity in a picking area where the goods will be prepared for shipping. Regardless of how your company executes the picking process, you can make settings in the system so that picking is carried out as follows.

 Automatically

 Routinely at certain times

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

 Manually according to overviews of the day's workload that an employee has requested.

A picking status is recorded in each delivery item for the purpose of scheduling and monitoring the picking process. This status indicates where the item is in the picking procedure (picking has started for item A, for instance). In the system standard settings, it is a prerequisite for goods issue7 to be posted before the item relevant for picking can be picked completely. If not doing so, one’s available inventory for other customers would be overstated, thereby incurring the risk of stockouts and inventory shortages. Therefore, delivery quantity and picking quantity (picked quantity) in the outbound delivery should theoretically be equal (the word “theoretically” is used because there may be less items on hand than originally determined, so the picked quantity can be less). Depending on the picking procedure being used, you can either determine delivery-relevant data before picking or wait until after picking is completed to record it. Delivery-relevant data may be made up of the following:

 Which batches a material is picked from

 Which serial numbers are picked

 Which valuation types the stock is taken from Packing is part of delivery and shipment processing. When you process a delivery, you can select delivery items for packing and assign them to handling units (HUs). As an example, you could pack delivery items in boxes, pack the boxes on pallets for delivery to the customer, and load the pallets onto a truck. A goods issue is created when the goods are transferred to the carrier for actual shipment to the customer. This is the point at which the sale can be recognized (if shipping terms are FOB shipping point). A goods issue has the following results in the system:

 Material document is created

 Accounting document is created

 Stock is updated

 G/L accounts are updated

 Consumption is updated

 Reservation is updated

7 A goods issue is a term used in inventory management to describe a reduction in warehouse stock due, for instance, to a withdrawal of stock or the delivery of goods to a customer.

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

 Order is updated

When you post a goods issue, the system automatically creates a material document which serves as proof of the goods movement. Parallel to the material document, an accounting document is created. The accounting document contains the posting lines (for the corresponding accounts) that are necessary for the movement. The following stocks are reduced by the issued quantity: total valuated stock; unrestricted-use stock; reserved stock if the goods issue is entered with reference to a reservation or an order. When the goods issue is posted, the system automatically creates posting lines on the accounts of the accounting system. In addition to causing an inventory update in the material master record, a goods issue posting causes an update of the consumption statistics if the material is planned with MRP. If the withdrawal is unplanned, both total consumption and unplanned consumption are updated. With a goods issue that references a reservation or a sales order, the quantity withdrawn is updated in the reservation item. The reservation item is completed when the total reservation quantity has been withdrawn or when the final issue indicator is set manually at goods issue. In the case of a goods issue with reference to an order, the quantities withdrawn for the components are updated in the order. As stated in previous chapters, all of these automatic postings that are based on integrated data that are described in this and the prior paragraph helps enhance both transaction-related control objectives that a particular authorized, valid transaction is recorded and recorded accurately. Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing. During billing, you can decide whether you want to create an invoice for every delivery, or whether you want to send the customer an invoice every month. The billing process is integrated with the accounting/controlling support process. When you create a billing document, the system automatically creates all relevant accounting documents for:

o General Ledger

o Profit center

o Profitability Analysis

o Cost Accounting

o Accounting

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

 posts offsetting entries to the appropriate accounts (with the help of "account

assignment"), and

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

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

The integration with controlling consists of assigning costs and revenues to the appropriate sub-ledgers. As a reminder, all of these automatic postings that are based on integrated data help enhance both transaction-related control objectives that a particular authorized, valid transaction is recorded and recorded accurately. One feature of sales logistics processing in the SAP R/3 SD module is the document flow display. The document flow shows how far the sales document has been processed and creates a business transaction out of consecutive documents in the system. For example, a document flow could contain an inquiry, a sales order, delivery, the good issue, the invoice, and the accounting document for the journal entry to record the sale. The document flow indicates the number of each document, the date initiated or completed, and the current processing status of the particular processing step. If you displayed the document flow from the sales order, the inquiry would be a preceding document and the delivery and invoice would be subsequent documents. The document flow can be used to access the original document created in the system when each of the steps in the sales processing took place. In this manner, the document flow forms an “audit trail” that can be used to examine the supporting documents for a given transaction. As a reminder, an audit trail of activities is one of the two basic categories of control activities, along with proper separation of duties. The integration of data within and across processes of the value chain, as well as the automatic posting/updating of documents and records, shows the strong audit trail of activities within SAP.

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

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

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

there are a large number of those items, the company can create a “template” that contains the set of items (and quantities) that the customer usually orders. This “template” is known as an Item Proposal. When the customer places an order, the Item Proposal can be referenced in processing the order thereby avoiding reentry of the items over and over for customary orders and this saving sales order processing time. In many cases the beginning point of a sales transaction is an inquiry from the customer seeking information about the price of one or more materials. A sales representative can complete a record of this inquiry from the particular customer that contains the pertinent data regarding the customer number, quantities, prices, and other related data. If the customer decides to place the order, the sales order can be created by transferring the data form the inquiry to the sales order thereby reducing processing time and data entry errors (i.e., improving the accuracy of a particular transaction). When a customer order is filled, the items ordered must be delivered. Creating a delivery for a sales order brings the order to the point of determining the availability of the stock items and classifies the quantities of the items ordered as scheduled for delivery. These materials must by “picked” from the inventory stock of materials. The completion of this picking process initiates a materials delivery note that indicates that quantity of each item actually picked and which are to be delivered. Picked goods are moved to the shipping location in order to await pick-up for delivery to the customer. When the items in the order are actually dispatched to the customer, a Post Goods Issue is created to record the actual shipment and to transfer ownership to the customer. Once the Post Goods Issue is created, the customer can be billed for the goods ordered. An invoice is created that is sent to the customer requesting payment for the shipment and which references the customer’s purchase order number, quantity shipped, prices, and all other pertinent data regarding the sales transaction. The integration of data and automatic posting/updating of records helps enhance both the accuracy and recording of a particular transaction, thereby improving the reliability of information from SAP. The actual billing of the customer for a shipped sales order occurs in the Production Logistics process rather than in Accounting as may be assumed. A billing document with a unique number is created that will be used by Accounting to process the actual collection of funds from the customer when they are remitted.

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

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

In the SAP system, accounting and controlling exist as separate but highly related elements. Financial Accounting accomplishes the necessary processing and recording of accounting transactions along with the creation of financial statements and other reports for external users (e.g., individuals and entities outside of the company such as shareholders, government agencies, trade associations, etc.). Financial accounting is thus referred to in many instances as “external accounting” and as such must follow Generally Accepted Accounting Principles (GAAP) and external regulatory requirements. Controlling, on the other hand, takes care of the internal management uses of accounting information. Controlling provides the company with information for management decision-making. It facilitates coordination, monitoring and optimization of all processes in an organization. This involves recording both the consumption of production factors and the services provided by an organization. The major activity of Controlling involves the assignment of costs to products and to cost centers to permit cost and profitability analysis. Although Financial Accounting (FI) and Controlling (CO) are independent components in the SAP system, data flow between the two components on a regular basis. Therefore, all data relevant to costs automatically flow from Financial Accounting to Controlling.

Financial Accounting (FI) In carrying out its external accounting function, Financial Accounting involves basically three accounting functions: General Ledger Accounting, Accounts Receivable processing, and Accounts Payable processing. General Ledger Accounting provides a comprehensive picture for external accounting and accounts. Recording all business transactions (primary postings as well as settlements from internal accounting) in a software system that is fully integrated with all the other operational areas of a company ensures that the accounting data are always complete and accurate. General ledger accounting is the heart of financial accounting. Each accounting transaction (as defined under Generally Accepted Accounting Principles) is recorded directly or indirectly in the general ledger. The general ledger contains accounts that represent the detail for the major accounting classifications of assets, liabilities, equity, revenue, and expenses. The general ledger reflects the balance among these various accounts. The account balance data for the various accounts in the general ledger are the input for the company’s financial statements. Accounts Receivable processing records and administers accounting data of all customers. It is also an integral part of sales logistics and management. All sales (assuming they are on credit) must be recorded and tracked for receipt of payment by customer. All postings in Accounts Receivable are also recorded directly in the General Ledger. Different G/L accounts are updated depending on the transaction involved (for example, receivables, down payments, and bills of exchange). The system contains a range of tools used to monitor open

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

items such as account analyses, alarm reports, due date lists, and a flexible dunning program. The correspondence linked to these tools can be individually formulated to suit company requirements. This is also the case for payment notices, balance confirmations, account statements, and interest calculations. Incoming payments can be assigned to due receivables using screen functions or by electronic means such as EDI and data telecommunication. Accounts Receivable is not merely one of the branches of accounting that forms the basis of adequate and orderly accounting. It also provides the data required for effective credit management (as a result of its close integration with the Sales Logistics) as well as important information for the optimization of liquidity planning through its link to Cash Management. Accounts Payable processing records and administers accounting data for all vendors. It is also an integral part of purchasing logistics and management. Deliveries and invoices are managed according to vendors. The system automatically makes postings in response to the operative transactions. In the same way, the system supplies the Cash Management application component with figures from invoices in order to optimize liquidity planning. Payables are paid with a payment program. The payment program supports all standard payment methods (such as checks and transfers) in printed form as well as in electronic form (data medium exchange on disk and electronic data interchange). This program also covers country-specific payment methods.

Organizational Structure in Financial Accounting COMPANY CODE: The company code is the smallest organizational unit for which a complete self-contained set of accounts can be drawn up for purposes of external reporting. This includes the entry of all transactions that must be posted and the creation of all items for legal individual financial statements, such as the balance sheet and the profit and loss statement. It also involves recording all relevant transactions and generating all supporting documents for financial statements such as balance sheets and profit and loss statements. A company code can, for example, be a company or subsidiary. All data that are valid for a particular company code, as well as for the plants and storage locations assigned to it, are stored at company code level. This includes, for example, accounting data and costing data if valuation is at company code level. Before the Accounts Receivable, Accounts Payable, and General Ledger application components of SAP can be used, a company code must be created as a minimum structure. More than one company code can be set up per client, enabling accounting for several separate companies simultaneously. At least one company code must be created. A legally independent company is normally represented by one company code in the R/3 System. The definition of the company code, however, also states that it represents a dependent operating unit according to commercial law. This is necessary if this operating unit is based in another country and therefore has to meet the currency and tax-based requirements of this country.

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

In Financial Accounting, business transactions are always entered, saved and processed at company code level. Likewise, accounts are also always managed at company code level. Further levels can be created by using internal organizational structures. All company-specific specifications such as how payment transactions are to be carried out are made at company code level. Customer and vendor master records have a company code area, which contains data that are only relevant to one company code. This includes, for example, data representing the business relations between the company code and a customer or vendor. The terms of payment that apply to each customer or vendor are assigned in the company code area of the master record. CREDIT CONTROL AREA: The credit control area is an organizational unit that represents the area where customer credit is awarded and monitored. Credit and risk management takes place in this area. A credit control area can serve one or more company codes, but it is not possible to divide a company code into several credit control areas.

Master Data in Financial Accounting CUSTOMER MASTER RECORD: Both Financial Accounting and Sales Logistics use customer master records. By storing customer master data centrally, it can be accessed (integrated) throughout the organization and avoid the need to enter the same information twice. Maintaining the customer data centrally also avoids inconsistencies (i.e., enhances the transaction-related control objective of “all transactions are recorded accurately”). If the address of a customer changes, for example, this change will only have to be entered once and the accounting and sales departments will always have up-to-date information. The customer master record links primarily to the Accounts Receivable function within Financial Accounting. By definition an account receivable is an amount owed by a customer. The customer master data record is necessary, therefore, not only to make the sale but to also process the collection of the customer’s payment and recording that payment in accounts receivable. VENDOR MASTER DATA: Both Procurement Logistics and Financial Accounting use vendor master records. Storing the vendor data centrally allows access where needed throughout the organization without duplication of data. Central storage also avoids inconsistencies in data that is duplicated in numerous locations (i.e., enhances the transaction-related control objective of “all transactions are recorded accurately”). Vendor master data are necessary in Procurement Logistics in order to obtain needed materials and services from the appropriate vendor. Vendor master data are also needed in the Accounts Payable function of Financial Accounting so that the liability to vendor can be recorded, the payment rendered, and the liability cleared. GENERAL LEDGER: Essentially, the general ledger serves as a complete record of all business transactions. It is the centralized, up-to-date reference for the rendering of accounts. The main task of G/L accounting is the overall presentation of Financial Accounting. Transactions are recorded in and reports are generated from the general ledger based on accounts. An account is a structure which records value transactions within an

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

accounting unit (in this case a company code) as an element from a value grouping such as assets, liabilities, revenues, etc. The account contains transaction figures, which reflect the changes to the values in a summarized form per company code. Selecting a transaction in the general ledger and vouching backwards, including to the original source documents, helps support the transaction-related control objective of “all recorded transactions are valid”. Conversely, selecting a source document and tracing forward, including to the general ledger, helps support the transaction-related control objective of “all valid, authorized transactions are recorded”. The accounts are listed in a chart of accounts. The chart of accounts is a list of all G/L account master records that are used in one or several company codes. For every G/L account master record, the chart of accounts contains the account number (which is the primary key of the account), the account name and controlling information. Generally a company code utilizes one of the master charts of account that come with the SAP system. Accounts can be added to that master as the company so desires. Accounts in the general ledger are classified as assets, liabilities, equity, revenues, and expenses. ACCOUNTS RECEIVABLE SUBSIDIARY LEDGER: The Accounts Receivable Subsidiary Ledger is set up to account for the values from business transactions with customers. The accounts receivable ledger records values at company code level. When a sale is made to a customer (as processed and recorded in Sales Logistics), an entry is made in the accounts receivable ledger under that customer number (the primary key of a customer record) indicating that there is an amount owed by that customer to the company. The accounts contained within the accounts receivable ledger are of all customer numbers created in the company code. The sum of all amounts owed to those customers (i.e., the sum of the account amounts in the ledger) is the total amount owed by customers to the company. When a payment is received from a customer, the customer account in the accounts receivable ledger is reduced by the amount of the payment. Therefore, in transaction processing, sales to customers are recorded by customer number and payments received from customers are recorded by customer number. ACCOUNTS PAYABLE SUBSIDIARY LEDGER: The Accounts Payable Subsidiary Ledger accounts for the values of business transactions with vendors. The accounts payable ledger records values at company code level. When a purchase is made and goods are received from a vendor (as processed and recorded in Procurement Logistics), an entry is made in the accounts payable ledger under that vendor number, indicating that there is an amount owed to that vendor for the goods. For each vendor there is a sub-ledger account to which all amounts concerning this vendor are posted. A posting to the vendor account is not the same as a payment. For example, payment is only executed when the Financial Accounting department posts the vendor's payment to a bank account, for example. The accounts contained within the accounts payable ledger are of all vendor numbers created in the company code. The sum of all amounts owed to those vendors (i.e., the sum of the account amounts in the ledger) is the total amount owed by the company to all of its vendors. When a payment is made to a vendor, the vendor account in the accounts payable ledger is reduced by the amount of the payment. Therefore, in transaction processing, purchases from vendors are recorded by vendor number and payments made to vendors are recorded by vendor number.

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

RECONCILIATION ACCOUNTS: Transactions with customers are posted to customer accounts in the accounts receivable subsidiary ledger, which carry a unique customer number for each customer. Transactions with vendors are posted to vendor accounts in the accounts payable subsidiary ledger, which carry a unique vendor number for each vendor. The customer subsidiary ledger contains all of the customer accounts (and numbers), while the vendor subsidiary ledger contains all vendor accounts (and numbers). However, vendor and customer numbers are not part of the general ledger set of accounts, even though that ledger contains an account both for accounts receivable and for accounts payable. In order for the general ledger accounts for receivables and for payables to reflect the total of the accounts in the respective subsidiary ledgers, a linkage between the subsidiary ledgers and their respective general ledger accounts is created. The Accounts Payable Subsidiary Ledger and the General Ledger are related through the general ledger reconciliation account for accounts payable. The Accounts Receivable Subsidiary Ledger and the General Ledger are related through the general ledger reconciliation account for accounts receivable. Each of these general ledger reconciliation accounts is automatically updated when transactions are recorded in their respective associated subsidiary ledgers. This ensures that the developments in the subsidiary ledgers accounts are accurately reflected in the general ledger. Therefore, in the general ledger the amount shown for Accounts Payable is the total of all of the individual vendor accounts in the accounts payable subsidiary ledger, and the amount shown for Accounts Receivable is the total of all of the individual customer accounts in the accounts receivable subsidiary ledger. As a result, the accounts should be reconcilable to the respective subsidiary ledgers. THE GR/IR CLEARING ACCOUNT: In the business world, ordered materials may arrive either before or after the invoice for the goods is received from the vendor. If the goods are received prior to invoice receipt, the company would not want to delay entry of the goods into the material management system simply because no invoice had yet been received. To do so might delay production or other activities that are material dependent. Such delays reduce the efficiency and effectiveness of operations. However, since the invoice for these materials has yet to be received and the exact amount of the obligation determined, the company would not want to enter an assumed amount into the accounting system. A further concern is that the delay in entering the goods received into the system reduces the control over such goods, thereby making them more susceptible to loss or theft. The use of a GR/IR (goods receipt/invoice receipt) clearing account allows the organization to record the receipt of the materials and enter the materials into the materials management system but “suspend” the amount owed until the actual invoice is received. Thus, the GR/IR account functions like a traditional “suspense” account, helping making business operations more efficient and effective, as well as safeguarding assets from loss or theft. The GR/IR clearing account is an intermediate account between the warehouse stock account and the vendor account. At goods receipt, the cost of the goods is posted to the inventory stock account and the net invoice amount expected is posted to the GR/IR clearing account. When the invoice is received, the posting in the GR/IR account is then cleared by an offsetting entry to the vendor account, which updates Accounts Payable. Theoretically, the

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

balance of the GR/IR account should be zero because the posting of the goods received is a temporary liability until it is moved out of the account and into Accounts Payable when the invoice is received. The GR/IR account should be reviewed periodically (including monthly) for an outstanding balance. If the GR/IR account carries a balance, it is either due to a timing difference between goods receipt and invoice receipt, or the failure to meet one of the transaction-related control objectives due to an error/fraud. With respect to a timing difference, it could be due to either the goods having been received but the invoice having not been received as of yet, or the invoice having been received but the goods having not been received as of yet. In the first situation, the GR/IR account carries a temporary liability (credit balance). In the second situation the GR/IR account carries a temporary negative liability (debit balance) while Accounts Payable carries an offsetting liability (credit balance). In both situations, the accounting records are proper, assuming legal title to the goods does not change hands until received. In the first situation, the liability has been accrued, while in the second the offsetting balances net to zero, which is proper if legal title has not changed hands until received. From an error/fraud perspective, a balance in the GR/IR account could be due to an authorized transaction posted to the account; an invalid/non-occurring transaction posted to the account; the failure to post a transaction to the account; or an inaccurately posted transaction. It is therefore important to periodically reconcile this account as you would other accounts such as bank accounts, accounts receivable and accounts payable for the purpose of detecting errors and fraud.

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

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

Many of the data transactions involved in Financial Accounting involve the payment of invoices or the receipt of payments from customers. However, payments for invoices involving purchased goods must be approved by the invoice verification process in Procurement Logistics before payment can be authorized – i.e., a preventive control. Customers are billed as the final step in the Sales Logistics. Financial Accounting processes the payments from customers that are received as the result of the billing invoices from Sales Logistics. Just as payments to vendors are verified against posted invoices, so can payments from customers against billings.

Controlling (CO) Controlling involves the “internal’ accounting system used within the organization for management decision making. The information produced within Controlling is intended solely for internal use only. Controlling facilitates coordination, monitoring and optimization of all processes in an organization. This involves recording both the consumption of production factors and the services provided by an organization. The consumption of product factors and services provided are encompassed in the “costs” of those items. Although such costs are tracked in the Financial Accounting system, that tracking is primarily aimed at determining the value of ending inventory for the balance sheet and the cost of goods sold for the income statement for external reporting purposes. Therefore, these costs are not very useful for management decision-making, such as the minimum sales price for the product; which customers or distribution channels are most profitable; whether overhead costs under or out of control; etc. Controlling meets the information requirement for such considerations. Unlike Financial Accounting, Controlling is not governed by outside sets of rules such as GAAP. As well as documenting actual events in terms of costs, the main task of Controlling is planning. Controlling allows the determination of variances by comparing actual data with plan data. These variance calculations enable the company to control business flows. Income statements such as contribution margin accounting (not permitted for external reporting) are

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

used to control the cost efficiency of individual areas of an organization, as well as the entire organization. Controlling (CO) and Financial Accounting (FI) are independent components in the SAP system. The data flow between the two components takes place on a regular basis. Therefore, all data relevant to costs flow automatically to Controlling from Financial Accounting. At the same time, the system assigns the costs and revenues to different CO account assignment objects such as cost centers, business processes, projects or orders. The relevant accounts in Financial Accounting are managed in Controlling as cost elements or revenue elements. This enables the reconciliation of the values from Controlling and Financial Accounting. Within Controlling there are a number of features that provide different information sets for management decisions. Cost center accounting is used for the source-related assignment of overhead costs to the location in which they occurred. Activity-based costing can be used to analyze cross-departmental business processes in order to optimize overall organizational goals and to prioritize business flows. Internal orders are used to collect and control costs according to the job that incurred them. Product cost controlling calculates the costs that occur during manufacture of a product, or provision of a service; it enables the company to calculate the minimum price at which to profitably market a product. Profitability analysis within Controlling analyzes the profit or loss of an organization by individual market segments. The system allocates the corresponding costs to the revenues for each market segment. Profitability Analysis provides a basis for decision-making, for example, for price determination, customer selection, conditioning, and for selection of the distribution channel. Profit center accounting evaluates the profit or loss of individual, independent areas within an organization. These areas are responsible for their costs and revenues. Profit Center Accounting is a statistical accounting component of the SAP system that occurs on a statistical basis at the same time as “true” accounting. In addition to costs and revenues, the system can display key figures, such as return on investment, working capital or cash flow on a profit center.

Organizational Structure in Controlling CONTROLLING AREA: Controlling uses the company code in a manner similar to its use in Financial Accounting. In Controlling a second structure element, the controlling area, is linked to the company code in order to allow greater integration, tracking and analysis of data than in Financial Accounting. A controlling area is an organizational unit that represents a closed system used for cost accounting. A controlling area may contain one or more company codes which can operate in different currencies, if required. The company codes within a controlling area must all use the same operational chart of accounts. All internal allocation transactions refer only to objects from the same controlling area. Internal business transactions are portrayed in the controlling area. Primary costs are transferred from external accounting and classified according to managerial accounting perspectives. If the primary costs are direct costs (e.g., direct material or direct labor), then

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

they are assigned directly to cost objects such as production orders or sales orders. If primary costs are overhead costs, then they are assigned to cost centers or overhead cost orders. The system then allocates the costs using internal allocation techniques based on their source. When master data are created, the system always assigns the Controlling objects to a controlling area and a company code. PROFIT CENTERS: A profit center is an organizational unit in controlling that reflects a management-oriented structure of the organization for the purpose of internal control. Management can analyze operating results for profit centers for which they are responsible for using either the cost-of-sales or the period accounting approach. By also calculating the fixed capital, profit centers can be analyzed as investment centers. The analysis of profit center results is a detective control for determining whether errors and/or fraud have occurred. In profitability accounting at the profit center level, all costs and revenues from the profit- relevant logistic activities and other allocations are transferred as statistical postings to the relevant profit centers. Every profit center is assigned to the organizational unit Controlling Area. This assignment is necessary because Profit Center Accounting displays values in general ledger accounts. The system transfers all the data to Profit Center Accounting together with the general ledger account to which the data was originally posted. COST CENTERS: A cost center is an organizational unit within a controlling area that represents a defined location of cost incurrence. A cost center can be defined based on functional requirements (e.g., accounting, plant security, company cafeteria, etc.), allocation criteria (how costs are allocate to the unit such as by headcount of employees, square feet, etc.), physical location (e.g., the northern sales office, the southern sales office, etc.), or responsibility for costs. Cost centers are used for differentiated assignment of overhead costs to organizational activities, based on utilization of the relevant areas (cost determination function) and for differentiated controlling of costs arising in an organization (cost controlling function). Overhead costs are “collected” in a cost center and then allocated to the organizational units or functions that “use” the services provided by that cost center. Cost centers can be collected into groups according to various criteria. Those groups can be used to build cost center hierarchies, which summarize the decision-making, responsibility, and control areas according to the particular requirements of the organization. The individual cost centers form the lowest hierarchical level. For example, the vice president in charge of sales may have four regional sales cost centers that report directly to him/her. Each regional sales cost center may have numerous area sales cost centers within the region. Furthermore, each area sales cost center may have numerous local sales office cost centers within its area. Linking these various cost centers together would allow tracking and analysis of operations and costs throughout the overall sales organization, by region only, by area only, or by individual sales office. There must be at least one group that contains all cost centers and represents the entire business organization. This cost center group is described as the standard hierarchy. The user can assign additional cost center groups to the standard hierarchy if needed.

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

Any number of alternative groups of cost centers can be created. Groups can be structured, for example, by organizational and/or functional viewpoints. Cost center groups enable the user to perform evaluations for each decision-making, responsibility, or control area. These groups also support the processes during planning and internal allocations. Following the sales organization example, assume that each local sales office sells a particular line of the company’s products. Sales offices selling product line A could be grouped together in an alternative hierarchy along with all other local sales offices that sell the same product line regardless of the area or region. In this way, operations and cost could not only be followed by geographical location (under the standard hierarchy) but also by product line. Users can assign each cost center to only one group within the standard hierarchy, but to as many alternative groups as required. This allows for the information related to each cost center to be “sliced and diced” any way management desires. Just like profit center results, the analysis of cost center results is a detective control for determining whether errors and/or fraud have occurred.

Master Data in Controlling The major master data in Controlling involves cost elements that classify an organization’s valuated consumption of production factors within a controlling area. A cost element corresponds to a cost-relevant item in the chart of accounts. Cost elements document which costs (differentiated by category) are incurred within a settlement period, and the amount. They provide information concerning the value flow and the value consumption within the organization. The system distinguishes between two types of cost elements: primary costs and secondary costs. PRIMARY COSTS: A primary cost element is a cost item in the chart of accounts for which a corresponding general ledger (G/L) account exists in Financial Accounting (FI). The user can only create the cost element in Controlling if it has first been defined as a G/L account in the chart of accounts and created as an account in Financial Accounting. The SAP System verifies that a corresponding account exists in Financial Accounting. Examples of primary cost elements include material costs, personnel costs, and energy costs. Primary costs arise through the consumption of goods and services that originate from outside the company such as the cost of items purchased from vendors, employee salaries and wages, purchased services, costs of fixed assets (i.e., depreciation), etc. These costs are recorded as expenses in the appropriate accounts in the General Ledger in Financial Accounting. A link must be created in order for an item recorded as an expense in Financial Accounting to be treated as a primary cost in Controlling. Because a primary cost has a matching expense account in Financial Accounting, a posting to an expense account therefore results in a cost that can be traced directly to a particular cost object in Controlling. For example, the costs for an external activity provided by a supplier can be allocated directly to a cost object in Controlling. This requires the incoming invoice to be assigned to the cost object. When the incoming invoice is entered in Financial

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

Accounting (FI), the amount is immediately allocated to the cost object in Controlling as well as being recorded in the appropriate general ledger expense account in Financial Accounting. An example of a primary cost is a direct materials cost. When a raw material is withdrawn from inventory to be used in manufacturing a finished product, a posting is generated to an expense account in Financial Accounting. The relevant expense account in Financial Accounting is the Raw Materials Consumption expense. The withdrawal (a goods issue) is entered in the application component Production Logistics (i.e., Materials Management - MM). Such goods movements in Production Logistics automatically generate postings in Financial Accounting. For raw materials, the system debits Consumption of Raw Materials and credits Raw Materials. The direct materials costs are allocated to the cost object. The amount allocated is the same as the expense posted in FI. SECONDARY COSTS: Secondary costs are cost elements that represent the activity values produced during internal cost allocations. For example, the expenses accumulated in the operation of the company’s data processing center are collected and then allocated as secondary costs to the various internal organizational units that use the center. Therefore, secondary costs do not “originate” (in that they do not represent transactions with outside parties) but are “created” from internal allocations. Secondary cost elements can only be created and administered in Controlling. They portray internal value flows such as those found in internal activity allocation, overhead calculations and settlement transactions. When a secondary cost element is created, the SAP System verifies that a corresponding account exists in Financial Accounting. If one exists, it cannot be created as a secondary cost element in Controlling. A secondary cost does not have a matching expense account in Financial Accounting. Secondary costs are therefore valuated consumptions of internal activities (activities performed inside the company rather than purchased from outside.) Secondary costs are overhead costs.

Transaction Processing in Controlling Like Financial Accounting, the transactions in Controlling can be described as economic and financial data transactions. In the most basic format, Controlling transactions involve the assignment of costs to various cost objects such as products, cost centers, orders, etc. through an allocation process. ALLOCATION: You can periodically allocate amounts and quantities from sender objects to receiver objects using allocations. The two main types of allocations are assessments and distributions. Both plan and actual data can be allocated. Allocation is carried out using the allocation cycle function. Allocation rules are used to determine how amounts and quantities should be allocated from sender object to receiver object. It is possible to assess/distribute amounts and quantities according to a number of criteria that can be specified within the allocation rules.

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

DISTRIBUTION: A distribution allocation is used to allocate the primary costs of a cost center. In a distribution, the original cost element (the primary cost element) is retained. In addition, sender and receiver information (for example, the identities of the sender and receiver cost center/business process) is documented using line items in the CO document. A distribution is accomplished periodically (monthly, for example) in order to transfer the primary cost from a cost center where it has been collected to the cost centers that are consuming that primary cost. When the distribution is complete, the amount of the primary cost of the item being distributed by the cost center may be zero (if the entire amount is distributed) or reduced to only the amount of the cost consumed by that cost center. For example, assume that an office building is rented for $10,000 per month. The invoice for the monthly rental is received and recorded in Financial Accounting in the rent expense account. This account has been linked to Controlling as a primary cost element and as such requires a cost object to which it must be charged. For administrative simplicity, assume the company has set up the accounting department as the cost center to receive the entire amount of the rent cost in Controlling even though the accounting department occupies only part of the building. Also housed in the building are human resources, corporate sales, various vice presidents’ offices, and data processing. At the end of the month or at some other predetermined time, the rent cost charged to accounting must be allocated to all of the occupants of the building through a distribution. A distribution has been chosen for this allocation so that each receiving department will show a rent cost in its operating reports. This may have been decided so that if a department increases its share of the space in the building, it would be charged an increased rent cost. The distribution, therefore, has been set up based on the number of square feet occupied by a department as a percentage of the total square feet occupied by all departments. The table below indicates the various percentages of the total building space occupied by the departments. Accounting 15% Human Resources 10% Corporate Sales 20% Vice Presidents 30% Data Processing 25% When the distribution is executed by the system, Accounting will receive an allocation of $1,500, Human Resources $1,000, Corporate Sales $2,000, Vice Presidents $3,000, and Data Processing $2,500. Each of these units will display this amount in the Rent Distribution line on its operating reports. In this way, each unit knows exactly how much it is charged for rent and that the charge is transferred from the Accounting department. For accounting, the entire $10,000 will be eliminated from its Rent Cost collection account (resulting in $0 in that account) but it will indicate a distribution of Rent of $1,500. Distributions can be based on square footage, employee headcount, number of telephones, or other criteria found to be meaningful by management. These various criteria are known as statistical key figures. These statistical key figures can be fixed value (for which the values are carried forward from one period to the next) or total value (for which the values must be recorded for each period independently). Fixed values are used for elements that remain relatively stable from period to period such as square feet occupied in a building. Total values are appropriate for items that fluctuate from period to period such as employee headcount.

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

ASSESSMENTS: An assessment is an additional way through which costs are allocated. Assessment is a method of internal cost allocation by which the company allocates (transfers) the costs of a sender cost center to receiver CO objects (orders, other cost centers, etc.) under an assessment cost element. The method works according to the keys defined by the user. Unlike Distribution, where only primary costs can be allocated, an assessment is a method of allocating both primary and secondary costs. In Assessment the original cost elements are assigned cumulatively, or in groups, to assessment (secondary) cost elements. The original cost elements are not recorded in the receivers’ accounts but are recorded as an assessment from the sender cost center. Also, sender and receiver information (sender cost center, receiver cost center, or business process) appears in the Controlling (CO) document. Allocation through assessment is useful when the composition of the incoming costs is unimportant to the receiver. For example, the assessment of cafeteria costs to a cost center need not be itemized in the receiving cost center’s records. Assume a company operates a subsidized cafeteria. The cafeteria incurs expenses for food, wages, electricity, etc. during operations. The cafeteria may also receive secondary cost charges such as maintenance, electricity, rent occupancy, etc. The amount of total cafeteria expenses not covered by revenue from food sales is to be charged to the cost centers whose employees use the cafeteria. Assessment will accomplish the allocation of both these expenses (primary costs) and secondary costs to other cost centers in the company. The company can assess the costs from the cost center "Cafeteria" to receiver cost centers in proportion to the statistical key figure "Employees" for each cost center. Receiver cost center I has 10 employees, while receiver cost center II has 90. In this case, the system would assess 10% of the costs from the cost center "Cafeteria" to receiver cost center I and 90% to receiver cost center II. The credit entered in the sender cost center "Cafeteria" and the debits entered in the receiver cost centers are all assigned by the assessment cost element. Depending on the system settings, the system can assess all the costs of the sender cost center "Cafeteria" or only part of those costs. Under Assessment, the receiving cost centers or other objects receive the amount assessed with only a general description of what is being assessed. For example, the receiver cost centers in the example above will receive their assessment as “Cafeteria Assessment’ with no indication of the nature of the expenses within the cafeteria. As some final comments about the two methods of allocation (distributions and assessments), the formalized method by which certain costs can be assigned helps enhance the reliability of financial reporting in a number different ways. As noted previously, the analysis of profit and cost centers results is an important detective control for identifying errors and fraud. If costs are only to be recorded through allocations, any recorded activity to a cost center that is not recorded through an allocation may indicate either a lack of transaction authorization or an invalid/non-occurring transaction. Further, if there is an expectation of costs being allocated to a cost center, but none are allocated, it may indicate the failure to record such costs and/or perform the allocation. Also, the formalization of the allocation process reduces data entry repetition, thereby helping improve the accuracy of data entered into the system.

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

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

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

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