Optimizing Value Flows with SAP ERP

Andrea Hölzlwimmer

Optimizing Value Flows with SAP

ERP

Bonn

�

Boston

298 Book_TIGHT.indb 3 12/4/09 3:47:29 PM

Contents at a Glance

1 Introduction ................................................................ 17

2 The Concept of Integrated Value Flows ...................... 25

3 Basic Principles of Integration in SAP ERP ................. 41

4 Procurement Process ................................................... 85

5 Sales and Distribution Process ................................... 159

6 Production Process ..................................................... 221

7 Closing and Reporting in SAP ERP .............................. 299

8 Reporting with SAP NetWeaver BW .......................... 353

9 Optimizing Value Flows by Implementing the

SAP General Ledger — A Real-Life Example ............... 379

A Sample Closing Procedure Document ......................... 401

B Transactions and Menu Paths ..................................... 407

C The Authors ................................................................. 425

298 Book_TIGHT.indb 5 12/4/09 3:47:29 PM

Contents

Acknowledgments ....................................................................... 13

Foreword ..................................................................................... 15

1 Introduction ................................................................. 17

1.1 Content and Structure ................................................... 18

1.2 Lederwaren-Manufaktur Mannheim .............................. 20

2 The Concept of Integrated Value Flows ...................... 25

2.1 Explanation of the Term “Integrated Value Flow” .......... 25

2.1.1 Value Flow ....................................................... 26

2.1.2 Integration ....................................................... 28

2.2 Models for Representing Enterprise Processes ............... 30

2.2.1 Porter’s Value Chain Model .............................. 30

2.2.2 SCOR Model .................................................... 31

2.3 Extending the SCOR Model .......................................... 36

2.4 Interaction Between Process Design and

Controlling Approach .................................................... 37

2.5 Summary ...................................................................... 39

3 Basic Principles of Integration in SAP ERP ................. 41

3.1 Structure of SAP Systems .............................................. 42

3.2 Entity Model ................................................................. 43

3.2.1 Organizational Elements in the SAP System ...... 44

3.2.2 Organizational Elements and Enhancements

of the Standard SAP System ............................. 51

3.2.3 Excursus: The SAP General Ledger and

Changes to the Organizational Structure ........... 52

3.3 International Requirements ........................................... 53

3.3.1 Parallel Accounting using the Classic

General Ledger ................................................. 54

3.3.2 Options of the SAP General Ledger for the

Parallel Rendering of Accounts ......................... 56

298 Book_TIGHT.indb 7 12/4/09 3:47:29 PM

Contents

3.4 Value Flow-Oriented Master Data Concept ................... 58

3.4.1 General Ledger Account and Cost Element ....... 59

3.4.2 Chart of Accounts ............................................. 63

3.4.3 Material Master ................................................ 65

3.4.4 Requirements Class .......................................... 71

3.5 CO-PA as a Central Reporting Tool ................................ 73

3.5.1 Forms of CO-PA ............................................... 74

3.5.2 Structure of Costing-Based CO-PA .................... 75

3.6 Summary ...................................................................... 83

4 Procurement Process ................................................... 85

4.1 Procurement Process in the SCOR Model ...................... 86

4.2 Vendor Master as an Integrative Element ...................... 89

4.3 Purchase Order as the Basis of the

Procurement Process .................................................... 92

4.3.1 Purchase Requisition ........................................ 92

4.3.2 Purchase Order ................................................ 92

4.4 Updating Commitments ................................................ 98

4.5 Integration of MM and Financial

Accounting/Controlling ................................................. 104

4.5.1 Basic Settings ................................................... 105

4.5.2 Valuation Class Settings .................................... 109

4.5.3 Determining Transactions ................................. 114

4.5.4 Rebuild Process for Account Determination ...... 123

4.6 Goods Receipt .............................................................. 128

4.7 Invoice Verication ....................................................... 130

4.7.1 Invoice Verication Process .............................. 131

4.7.2 Considering Tolerances ..................................... 138

4.7.3 Automatically Releasing Blocked Invoices ......... 141

4.8 GR/IR Account .............................................................. 142

4.8.1 Posting to the GR/IR Account ........................... 142

4.8.2 Clearing the GR/IR Account .............................. 143

4.9 Integration of Accounts Payable Accounting ................. 147

4.9.1 Invoice Receipt Without MM Integration ......... 148

4.9.2 Outgoing Payments .......................................... 149

4.10 Mapping the Tax on Sales/Purchases ............................. 154

4.11 Summary ...................................................................... 157

298 Book_TIGHT.indb 8 12/4/09 3:47:29 PM

Contents

5 Sales and Distribution Process .................................... 159

5.1 Sales and Distribution Process in the SCOR Model ........ 160

5.2 Sales Order as the Basis of Further Account

Assignment ................................................................... 162

5.2.1 Prot Center Derivation ................................... 163

5.2.2 Deriving a Segment .......................................... 164

5.3 Price Determination as the Basis of Value

Determination .............................................................. 166

5.3.1 Conditions and Costing Sheet ........................... 166

5.3.2 Price-Determining Elements ............................. 170

5.3.3 Costing-Based Elements ................................... 173

5.3.4 Special Business Transactions ............................ 175

5.4 Goods Issue .................................................................. 178

5.5 Presentation of Receivables .......................................... 182

5.5.1 Customer Account ............................................ 183

5.5.2 Determining the Reconciliation Account .......... 186

5.5.3 Integration of SD and Accounts Receivable ...... 193

5.5.4 Mapping of Secondary Businesses .................... 194

5.5.5 Dunning ........................................................... 195

5.5.6 Incoming Payment ........................................... 196

5.6 Mapping Sales Revenues ............................................... 204

5.6.1 Time of the Revenue Recognition ..................... 204

5.6.2 Presentation of Sales Revenues ......................... 205

5.6.3 Transfer to Overhead Cost Controlling .............. 216

5.6.4 Troubleshooting for Revenue Account

Determination .................................................. 218

5.7 Summary ...................................................................... 219

6 Production Process ...................................................... 221

6.1 Production Process in the SCOR Model ........................ 223

6.2 Basic Product Cost Controlling Data .............................. 225

6.2.1 Logistical Master Data ...................................... 225

6.2.2 Prerequisites in Controlling ............................... 229

6.2.3 Basic Product Cost Controlling Settings ............ 231

6.3 Product Cost Planning ................................................... 241

6.3.1 Types of Product Cost Planning ........................ 241

298 Book_TIGHT.indb 9 12/4/09 3:47:30 PM

Contents

6.3.2 Material Cost Estimate with

Quantity Structure ............................................ 244

6.3.3 Simulation and Base Planning Object ............... 251

6.4 Cost Object Controlling ................................................ 257

6.4.1 Cost Object Controlling Functions in SAP ERP ... 257

6.4.2 Period-End Closing ........................................... 262

6.4.3 Period-Related Product Controlling .................. 281

6.4.4 Order-Related Product Controlling ................... 287

6.4.5 Product Cost by Sales Order ............................. 292

6.5 Summary ...................................................................... 297

7 Closing and Reporting in SAP ERP .............................. 299

7.1 Innovations in SAP General Ledger ............................... 300

7.1.1 Activating Different Scenarios ........................... 300

7.1.2 Effect of Real-Time Integration of Controlling

with Financial Accounting ................................ 302

7.2 HR Data Transfer ........................................................... 312

7.3 Inventory ...................................................................... 315

7.4 Activities in Asset Accounting ....................................... 317

7.4.1 Settlement of Assets Under Construction .......... 317

7.4.2 Depreciation Posting Run ................................. 320

7.4.3 Periodic APC Values Posting ............................. 323

7.4.4 Asset Accounting Inventory .............................. 324

7.4.5 Technical Processing ......................................... 324

7.4.6 Creating the Asset History Sheet ....................... 325

7.5 Period Control .............................................................. 326

7.5.1 Period Closing for the Material Master ............. 327

7.5.2 Opening and Closing Posting Periods ............... 327

7.6 Foreign Currency Valuation ........................................... 329

7.7 Reclassication of Receivables and Payables .................. 333

7.8 Value Adjustment to Receivables .................................. 334

7.9 Balance Carryforward .................................................... 335

7.10 Manual Postings ........................................................... 336

7.11 Assessments and Distributions ...................................... 338

7.12 Reconciliation ............................................................... 341

7.12.1 Accounting Reconciliation ................................ 341

7.12.2 Intercompany Reconciliation ............................ 342

298 Book_TIGHT.indb 10 12/4/09 3:47:30 PM

Contents

7.12.3 Reconciliation Between Financial Accounting

and Inventory Management ............................. 343

7.12.4 Reconciliation Between Financial Accounting

and Controlling ................................................ 344

7.13 Reporting ..................................................................... 345

7.13.1 Reporting in General Ledger Accounting .......... 345

7.13.2 Reporting in Open Item Accounting ................. 349

7.13.3 Reporting in Controlling ................................... 349

7.14 Summary ...................................................................... 351

8 Reporting with SAP NetWeaver BW ........................... 353

8.1 Basic Principles of Business Intelligence ........................ 353

8.1.1 Business Explorer Suite—Reporting with

SAP NetWeaver BW ......................................... 361

8.1.2 Business Content .............................................. 364

8.2 Data Acquisition Examples ............................................ 369

8.2.1 Financial Reporting .......................................... 369

8.2.2 Protability Analysis ......................................... 373

8.3 Summary and Outlook .................................................. 378

9 Optimizing Value Flows by Implementing the

SAP General Ledger — A Real-Life Example ............... 379

9.1 Project Charter .............................................................. 379

9.1.1 Preliminary Considerations ............................... 380

9.1.2 Actual Project Scope ........................................ 384

9.2 Project Plan .................................................................. 385

9.2.1 Project Plan ...................................................... 387

9.2.2 Test Phases ....................................................... 388

9.3 Redesigning Value Flows ............................................... 391

9.3.1 Concept for Segment Derivation ....................... 391

9.3.2 Value Flows in the Procurement Process ........... 393

9.3.3 Value Flows in the Sales Process ....................... 394

9.3.4 Value Flows in Financial Accounting and

Controlling ....................................................... 396

9.4 Project Review .............................................................. 397

9.5 Summary ...................................................................... 397

298 Book_TIGHT.indb 11 12/4/09 3:47:30 PM

Contents

Appendices ........................................................................ 399

A Sample Closing Procedure Document ..................................... 401

B Transactions and Menu Paths ................................................. 407

B.1 Controlling .................................................................... 407

B.1.1 Application ...................................................... 407

B.1.2 Customizing ..................................................... 410

B.2 Financial Accounting ..................................................... 413

B.2.1 Application ...................................................... 413

B.2.2 Customizing ..................................................... 416

B.3 Materials Management ................................................. 419

B.3.1 Application ...................................................... 419

B.3.2 Customizing ..................................................... 419

B.4 Production .................................................................... 421

B.4.1 Application ...................................................... 421

B.4.2 Customizing ..................................................... 422

B.5 Sales and Distribution ................................................... 422

B.5.1 Application ...................................................... 422

B.5.2 Customizing ..................................................... 423

B.6 SAP NetWeaver BW – Customizing in SAP ERP ............. 424

B.7 Miscellaneous ............................................................... 424

C The Authors ........................................................................... 425

Index ............................................................................................. 429

298 Book_TIGHT.indb 12 12/4/09 3:47:30 PM

Three critical processes run in an enterprise. This chapter analyz-

es the rst important process, the purchasing process. You should

not underestimate its signicance, because the products you gen-

erate can only be as good as the materials you purchase.

Procurement Process4

The focus of business value added is usually on production, which requires

various input factors such as material and labor. From the logistics perspec-

tive, the procurement process should provide the correct input factors in

the correct quality and quantity at the correct location at the correct time.

Although the tasks of procurement can be summarized in a plain and sim-

ple sentence, it comprises numerous aspects. This chapter discusses the

different aspects of the procurement process as well as the related effects

on the enterprise’s value ows.

First, it describes how the procurement process is integrated with the

operational performance. In this context, the extended SCOR model plays

a signicant role. Afterward, you learn how to statistically update and

trace commitments in cost accounting during the procurement process to

allow for early budget controlling. Additionally, this chapter focuses on

account determination from Materials Management (MM account deter-

mination) because this considerably affects the interface between logistics

and accounting. The descriptions on the goods receipt and invoice receipt

then lay the foundation for discussing “genuine” value ows.

The explanations on mapping and further processing the resulting pay-

ables in accounting conclude the integration with logistics. Usually, the

payables are what are called payables for goods and services (PGS). An out-

look on the closing process rounds off this chapter.

We will now take a look at the steps and different design options in the

procurement process. For this purpose, the adapted SCOR model from

Chapter 2, Section 2.2.2 is used again as an example.

298 Book_TIGHT.indb 85 12/4/09 3:47:53 PM

Procurement Process

Procurement Process in the SCOR Model4.1

Within the SCOR model the “purchasing” part (source) that comprises the

ordering process and warehouse management is also the part that includes

the procurement process. Depending on the production approach, the

SCOR model differentiates between three basic procurement process types

(see Figure 4.1).

Procurement

Scheduling

Goods Receipt

Goods

Receipt

Quality

Check

Stocked

Goods

Sales-Order-

Production

Engineer-to-

Order

Production

* Not Part of the Original SCOR Model.

Release

of the

Payment

Scheduling

Goods Receipt

Goods

Receipt

Quality

Check

Release

of the

Payment

Vendor

Selection and

Scheduling

Goods

Receipt

Quality

Check

Placement

in Storage

Payment*

Release

of the

Payment

Placement

in Storage

Placement

in Storage

Payment*

Procurement Process in the Adapted SCOR ModelFigure4.1

As you can see, we added the payment process to the standard model (see

Figure 2.5 in Chapter 2, Section 2.2.2, SCOR Model). Regarding logistics,

it would be sufcient to consider the process complete after the payment

for the invoice has been released. However, because this book focuses on

the value ow, it is supposed to guide you through the complete ow, that

is, up to paying the vendor invoice.

In addition to this aspect, Figure 4.1 shows that the SCOR model differ-

entiates between three procurement process types, which depend on the

organization of the production:

Procurement for make-to-stock production



Procurement for sales-order-related production



Procurement for projected sales-order-related production



It is apparent that the three process types only differ in the rst module.

For make-to-stock production and sales-order-related production, the pur-

chasing department is responsible for scheduling the goods receipt in the

SCOR model

Process types in

the SCOR model

Vendor selection

298 Book_TIGHT.indb 86 12/4/09 3:47:53 PM

Procurement Process in the SCOR Model 4.1

continuous process. For project production, this also includes the task of

selecting the vendor, which also needs to be done for the rst two pro-

cess types. The difference is that selecting the vendor is only necessary

for make-to-stock and sales-order-related production if new or modied

products are used. For continuous replenishment orders, the purchasing

department usually collaborates with known vendors with whom outline

agreements may have been worked out.

For us, it is not relevant if and to which extent the purchasing department

has to select the corresponding vendors for individual ordering processes

because this does not generate value ows. It is also not important what

kind of event has triggered the purchase requisition: reaching a minimum

amount of raw materials in stock, a sales order, or the completion of proj-

ect planning. From the perspective of accounting and cost accounting, this

is not a transaction you can express in values.

However, the process type affects the procedure in cost accounting. This

involves the question of which objects are used to assign the accounts for

purchase orders, goods receipt, and invoice receipt. For more information,

refer to Section 4.3.2, Purchase Order.

You already know that vendor selection is not relevant for the value ow.

You can take adequate measures in cost accounting only if a purchase req-

uisition or a purchase order is being created. You can now account the

open purchase requisitions to possible existing budgets to be able to iden-

tify overruns at an early stage.

In most cases, the goods receipt is the rst event you have to include in the

nancial statement. Here, you must post a receipt in stock or, for goods

that are not subject to inventory management, an expense. From the logis-

tics view, the goods receipt consists of several substeps. After you have

received the goods, you have to check the quality of the procured goods

or repack them until they can be stored. From the accounting and cost

accounting view, only the process of entering the stock in the system is rel-

evant because it results in Financial Accounting and Controlling postings.

In an SAP system, you usually do not post the goods receipt to payables

but to the goods receipt/invoice receipt account (GR/IR account). Received

invoices are also posted to this account. This means that it serves as a buf-

fer between the two processes (goods receipt and invoice receipt) and

consequently enables you to separate the ow of goods from the value

ow. This also provides additional benets, which are discussed in detail

in Section 4.8, GR/IR Account. It is not until the vendor invoice is received

Reducing budgets

for purchase orders

Goods receipt

Invoice receipt

298 Book_TIGHT.indb 87 12/4/09 3:47:53 PM

Procurement Process

and posted that the open item is created in accounts payable accounting.

Depending on the specic case, you must additionally post currency dif-

ferences or other deviations.

The open item is usually cleared within a payment run. From the account-

ing perspective, this is the last operation of the value ow in the procure-

ment process.

The different stages of the procurement process may lead to values in

Financial Accounting and Controlling. Figure 4.2 provides an overview of

the possible documents.

Goods Receipt Doc.

–Stock Posting

Invoice

–Payable

–Tax

–Expense/Stock

CO-OM Document

– Update

Commitment

CO-OM Document *

–Material Costs

Ordering Process Goods Receipt Invoice Receipt Outgoing Payment

CO-OM Document *

–Material Costs

Outgoing Payment

–Cash Disbursement

–Clearing of the

Payables

CO-OM Document *

–Cash Discount

–Expense

Reduction

Goods Receipt Doc.

–Stock Posting

–Stock Change

* Optional

Invoice Receipt

in MM

Value Flow of the Procurement ProcessFigure4.2

The updates of commitments within the ordering process takes on a spe-

cial role in Figure 4.2. Here, in contrast to all other processes, only statistic

values and no actual values are updated.

Before discussing the details of the procurement process, we will take a

look at the involved master data. First, there is the material master. Because

it is not only critical in procurement but also in production and sales and

distribution, it was already described in Chapter 3, Section 3.4.3, Material

Master. The use of the vendor master, which is detailed in the following

section, is usually restricted to the procurement process. It is indispensable

for both logistics and accounting.

Outgoing

payments

Creation of values

298 Book_TIGHT.indb 88 12/4/09 3:47:54 PM

Vendor Master as an Integrative Element 4.2

Vendor Master as an Integrative Element4.2

To meet the different requirements of the purchasing department and

accounts payable accounting, the SAP system splits up the vendor master

into three parts:

General part



Accounting view



Purchasing data



For every vendor for which the system should map business relationships,

at least the general part must be created. This part stores all information

that is relevant and clear for both the purchasing department and account-

ing. Here, you can nd the vendor number, the name and address of the

vendor, the corresponding tax information as well as all bank details. The

benet is that you have to maintain the bank details only once, even if the

vendor exists in several company codes.

In the accounting view, you maintain all data based on the company code.

The example of the reconciliation account clearly illustrates the benet of

this procedure.

The reconciliation account is the link between accounts payable account-

ing and general ledger accounting. In general ledger accounting, it maps

the payables. As soon as a posting is made for a vendor, the posting is also

implemented on the reconciliation account in general ledger accounting

(see Figure 4.3).

In the example, an invoice of EUR 1,190.00 shipment costs (gross) from

vendor 90100 is received. To generate a posting to the vendor account, a

reconciliation account must to be dened in the vendor master to ensure

integration with the general ledger. In this case, account 160000 is speci-

ed in the vendor master. If you now specify the vendor number when

entering the incoming invoice, the system generates a posting item of

EUR 1,190.00 on the vendor account and on reconciliation account 160000.

For an offsetting account assignment to the input tax account and freight

account, the document in the general ledger balances to zero. In accounts

payable accounting, only the open item for vendor 90100 in the amount

of EUR 1,190.00 is shown.

General part

Accounting view

“Reconciliation

account” example

298 Book_TIGHT.indb 89 12/4/09 3:47:54 PM

Procurement Process

Accounts Payable Accounting

General Ledger Accounting

Customer: 90100

Reconciliation

Account: 160000

Invoice Receipt: EUR 1,190.00 for Delivery Costs

160000 PGS 154000 Input Tax

Vendor 90100

231100 Freights

EUR 1,190.00

EUR 1,000.00EUR 190.00

Posting Techniques for Reconciliation AccountsFigure4.3

A typical structuring for the mapping of payables in general ledger account-

ing is the following:

Payables for goods and services, third-parties, domestic



Payables for goods and services, third-parties, foreign



Payables for goods and services, afliated enterprises, domestic



Payables for goods and services, afliated enterprises, foreign



Mapping Payables in the Reconciliation Account of Lederwaren-

Manufaktur Mannheim

Let us take our sample enterprise Lederwaren-Manufaktur Mannheim as an

example and assume that all required ostrich leather is procured exclusively

from one wholesaler in Frankfurt, Germany. The purchasing department has a

decentralized organization; that is, each of the producing plants (Mannheim,

Milan, and Brussels) has created the German wholesaler as a vendor.

For the German plants, the vendor is a domestic vendor; for all other plants,

it is a foreign vendor. Whereas the German plant denes account 160000

(domestic vendor payables) in the vendor master, account 161000 (foreign

vendor payables) must be specied for Belgium, France, and Italy.

Because you maintain the reconciliation account separately for each

company code, this differentiation can be made without any problem.

Additional accounting view data includes the terms of payment and the

payment method. The accounting terms of payment are only relevant if

the vendor invoice is directly entered in accounting and not via the MM

component.

Mapping of

payables

298 Book_TIGHT.indb 90 12/4/09 3:47:55 PM

Vendor Master as an Integrative Element 4.2

In the SAP world, payment methods are the different methods you can use

to pay—for example, check or bank transfer—and you can assign more

than one payment method to a vendor. This is useful, for example, if you

want to pay large invoices via check and all invoices up to EUR 10,000.00

via bank transfer.

Check Function for Duplicated Invoices or Credit Memos

The accounting view of the vendor master also contains an indicator you

can use to have the system check for invoices or credit memos that have

been entered twice. If the indicator is set, the SAP system checks whether

the document already exists when you enter an invoice or credit memo. It

assumes that the document has been entered twice if elds such as the ex-

ternal document number, vendor, and amount correspond to the elds of an

already existing document.

If this is the case, the system outputs a message to inform the user of the risk

of a duplicate entry. You can customize this message using Transaction OBA5,

for example. However, it should be an informational message and not an er-

ror message and should only inform the user of the risk of a duplicate entry

and not prohibit entering the invoice.

If you want to use this system support, you have to dene the Check For

Duplicate Invoice indicator as a mandatory eld in the Customizing of the

vendor master.

The purchasing data of the vendor stores all information that you require

for a smooth purchasing process but that does not affect the accounting

processes. Here, you maintain the purchase order currency and the term

of payment, for example, that are should be used for purchase orders for

this vendor by default.

For vendors that are only required in accounting but for which no purchase

order is entered in the system, you only have to create the general and the

accounting view. Examples include employees to which travel expenses

were paid via bank transfer. You also do not have to provide an account-

ing view for vendors that are required for the purchasing process but not

for accounting. This includes, for example, potential vendors from which

you request a quotation but for which no purchase order is generated. Of

course, the purchasing department does not obtain a quotation for its own

sake. Usually, a requirement is determined within the enterprise, for exam-

ple, in production, in materials planning, or in stock. When the purchasing

department receives the requirement, the ordering process starts.

Payment methods

Purchasing data

Required views

298 Book_TIGHT.indb 91 12/4/09 3:47:55 PM

Procurement Process

Purchase Order as the Basis of the 4.3

Procurement Process

In the context of the ordering process, this section focuses on two docu-

ments: purchase requisition and purchase order.

Purchase Requisition4.3.1

You can transfer the requirements either manually without system sup-

port or, particularly if the SAP system works with MRP procedures, auto-

matically. In the SAP world, the document that triggers the purchase order

later on is called purchase requisition. Depending on the method of how

the purchasing department is informed about a requirement, a purchase

requisition can be entered directly; that is, manually, or indirectly; that is,

via another SAP component.

A purchase requisition already contains all of the necessary information for

the purchasing department. First, it denes a requisitioner. For every item,

it also species the purchase order quantity and, preferably, the material

number. Alternatively, a material group can be maintained.

Material Group

A material group is a grouping of materials for which no material may exist.

You can derive the account assignment from the material group; that is, it

supports automated processing.

A purchase requisition is an internal document. It is a request to the purchas-

ing department to procure a material or service. After its release, you can ful-

ll a purchase requisition with a purchase order or an outline agreement.

You may have to determine a source of supply before creating a purchase

order. Here, the SAP system also supports the purchaser: You can create

requests and enter the quotation afterward as well as access existing pur-

chase orders and conditions in the system. By comparing the different

quotations in the SAP system, you can determine the best vendor and then

create the purchase order.

Purchase Order4.3.2

Like many other documents in the SAP system, a purchase order consists

of a header that is supplemented with individual items. Except for the

stock transfer order, all purchase orders are sent to a vendor. The respec-

Determining the

source of supply

Header data of the

purchase order

298 Book_TIGHT.indb 92 12/4/09 3:47:55 PM

Purchase Order as the Basis of the Procurement Process 4.3

tive vendor number is entered in the purchase order header. As a result,

the system proposes various values from the vendor master, as follows:

Ordering address, invoice address, and delivery address



Terms of payment



Incoterms (terms of freight)



More interesting than the header information are the purchase order items.

Their behavior—as well as the required information for each item—is con-

trolled by what is called an item category . The type and attributes of the

item category determine critical de nitions (see Figure 4.4).

Item Category De nitionsFigure4.4

First of all, you have to de ne whether the corresponding purchase order

item allows for, enforces, or prohibits specifying a material number or

additional account assignments (see

Material Required  eld group in

Figure 4.4). For materials, you can additionally select whether inven-

tory management is possible (

Inventory Management  eld group). This

de nes whether the material is stock material for which you may want to

know at a later stage whether and how much material is in stock.

Here, you can also specify critical de nitions for the goods receipt. You

can de ne whether goods receipt is expected and whether this setting can

be changed in the purchase order maintenance. You can also determine

whether the goods receipt is non-valuated and also whether this setting

can be changed (

Control: goods receipt  eld group). For example, for

Purchase order

item—item

Other Transfer Posting

Link Between Transaction and Movement IndicatorTable4.2

This is different for the movement type, which is another important

account determination element. Its primary task is the presentation of the

material ows in the enterprise.

Reduced to its key aspects, every goods movement leads to a goods

receipt, a goods issue, or—for stock transfers—both. However, to control

the numerous goods movements, this information is not detailed enough.

Therefore, the movement type supports you because it is responsible for a

more detailed specication of the movement.

To perform this task, you have to implement various denitions for each

movement type. You dene individually which transactions provide the

movement type and which elds can or have to be populated. The move-

ment type also species whether the incident leads to quantity and/or

value updates. The system proposes movement types in many MM trans-

actions. If the SAP system does not propose a movement type, you can

also enter one manually.

When entering a goods movement, you also dene whether the transac-

tion affects special stock. If so, a special stock indicator is required. This

indicator enables you to manage certain stock separately from normal

stock for a material. Common examples include customer stock (goods are

reserved for the customer) or consignment stock (goods are received by

you, but are still the property of the vendor). The consignment stock topic

in particular affects value updates to a large extent: As long as the goods

are still the property of the vendor, you are not allowed to map the goods

as values in the nancial statement.

Movement type

Special stock

indicator

298 Book_TIGHT.indb 116 12/4/09 3:48:06 PM

117

Integration of MM and Financial Accounting/Controlling 4.5

Another indicator you usually cannot in uence is the consumption post-

ing indicator. The system sometimes sets this indicator automatically and

sometimes has to determine it. For example, movements with purchase

order reference are provided with a value of this indicator from the account

assignment category of the purchase order item. The SAP system offers the

following values for the consumption posting indicator:

A asset



V consumption



E settlement through sales order



U unknown



P settlement for project



Finally, there is the receipt indicator , which is used for MM account deter-

mination. It speci es the type of the goods receipt or of the stock transfer

but can only adopt one of the following three values:

[BLANK] normal receipt



X stock transport order



L borrowed empties



From the combination of all of these indicators—movement indicator,

movement type, special stock indicator, quantity and value update, con-

sumption posting, and receipt indicator—the SAP system determines what

is called a value string . You can consider this string a posting rule that de nes

how you have to transfer a material document to Financial Accounting/

Controlling. This context can be best understood at the table level.

Excerpt of Table T156Figure4.26 SY

(Quantity/Value Update Movement Type: System Table; as of Rel. 4.6A)

Figure 4.26 shows an example of movement type 101 (“Goods receipt for

purchase order in stock”). In all three rows, both the value and quantity

are updated. They are not special stock movements, as you can see from

the missing entries in the

S column (special stock indicator). The B move-

ment indicator in the

Movement column indicates that this transaction is

Consumption

posting

Receipt indicator

Value string

298 Book_TIGHT.indb 117 12/4/09 3:48:06 PM

118

Procurement Process

a goods movement for a purchase order. The fact that the receipt indica-

tor (

Receipt column) is missing means that it is a usual receipt. Up to this

point, the three rows are identical.

The only difference occurs in the

Consumption column (consumption

posting). You can see that it is not relevant whether it is a consumption

or a consumption for an asset because both cases refer to the WE06 value

string. Only the fact that the rst entry does not include a consumption

posting leads to a deviating value string (WE01).

You can then use the value string to determine a transaction. Because some

transactions require a more detailed subdivision of the account determina-

tion, the SAP system provides account grouping.

Account grouping enables you, for example, to further break down the

“Offsetting entry for inventory posting” transaction (GBB transaction

key). Various account groupings enable you, for example, to control goods

issues for cost centers (movement type 201) and goods issues for sales

orders (movement type 231) for different consumption accounts. In addi-

tion to the “Offsetting entry for inventory posting” transaction, you can

also use account groupings for price differences (PRD) and consignment

liabilities (KON). Transaction OMWN enables you to customize the account

grouping.

You can also dene your own account groupings. This is useful if your

reporting requirements are specic. A common example can be that you

are unsatised with the VBR (consumption) account grouping because you

want to display withdrawals for orders separately from withdrawals for

cost centers. In this context, MM uses two different movement types any-

way: 201 for withdrawals for cost centers, and 261 for withdrawals for

orders. This means that you have to create only two additional account

groupings. Afterward, you must adapt the mapping of the 201 and 261

movement types to the new entries.

The standard SAP system already provides numerous transactions. The

documentation prepared by SAP has considerably improved over the last

years but is still rather confusing. Therefore, the following sections detail

the most critical default transactions:

Expenditure/income from consignment material consumption (AKO)



Transaction AKO is used when material is withdrawn from consign-

ment stock. The withdrawal can be due to consumption or due to a

transfer to your own stock.

Transaction and

account grouping

Creating custom

account groupings

Transactions in the

SAP standard

298 Book_TIGHT.indb 118 12/4/09 3:48:06 PM

119

Integration of MM and Financial Accounting/Controlling 4.5

Expenditure/income from transfer posting (AUM)



Transaction AUM is used for transfer postings of material to material. If

the price of the issuing material is different from the price of the receiv-

ing material, this results in price differences. These price differences are

posted with AUM.

Stock change (BSV)



Transaction BSV is only possible for materials that are produced exter-

nally using subcontracting. You use BSV for goods receipt or subse-

quent allocations to subcontract orders.

This is one of the situations where the SAP system cannot derive useful

Controlling account assignment. If you still want to dene the assigned

account as a cost element, you have to dene standard account assign-

ments, for example, using Transaction OKB9.

Dening Standard Account Assignments

Postings always exist that you cannot provide with useful Controlling account

assignments or that always have to be assigned to the same cost center/order.

In these situations, you have two options to link a cost element to a xed

cost center or order:

You can enter the Controlling account assignment in the cost element mas-



ter record itself.

You can use Transaction OKB9, which enables you to dene a xed cost



center, order, business area, or prot center for a cost element.

The advantage of Transaction OKB9 is that it displays an overview of all stan-

dard account assignments. However, you should ensure that you select one

of these two methods to be able to understand how a Controlling account

assignment has been determined.

Stock posting (BSX)



Transaction BSX addresses the material stock accounts in the nancial

statement. It is always relevant when the material stock changes. Exam-

ples of this are goods receipts or issues in your own stock or an update

of the moving average price when price differences occur in invoice

verication.

The specications for reconciliation accounts also apply to material stock

accounts: You should not post them manually. This is the only way to

ensure that the MM inventory management corresponds to accounting

regarding values.

298 Book_TIGHT.indb 119 12/4/09 3:48:06 PM

120

Procurement Process

Mapping of delivery costs



In orders, you can specify different kinds of delivery costs. To post these

costs for the goods or invoice receipt, different transactions are available:

Freight clearing (FR1)



Provisions for freight charges (FR2)



Customs clearing (FR3)



Provisions for customs clearing (FR4)



Offsetting entry to the stock posting (GBB)



Transaction GBB is the most important and comprehensive transaction

in the standard SAP system. Both from an accounting and controlling

view, it is not sufcient to say that a posting item is the offsetting entry

to the stock posting. Consequently, Transaction GBB in particular is fur-

ther structured through the intensive use of account groupings.

The standard version provides the account groupings shown in Table 4.3.

Account

Grouping

Usage

AUA

Settlement of orders

AUF

Goods receipts for orders if no genuine Controlling account

assignment is provided and for order settlement if the AUA

account grouping is not maintained

BSA

Initial entries of stock balances

INV

Expenditure or income from inventory differences

VAX

Goods issues for sales orders without account assignment

object (the account is not a cost element)

VAY

Goods issues for sales orders with account assignment

object (the account = cost element)

VBO

Consumption from stock provided to vendor

VBR

Internal material withdrawals, for example, for internal

order/cost center

VKA

Sales order account assignment

VKP

Project account assignment

VNG

Scrapping or destruction

VQP

Sample without account assignment

Account Groupings for Transaction GBB Table4.3

298 Book_TIGHT.indb 120 12/4/09 3:48:06 PM

121

Integration of MM and Financial Accounting/Controlling 4.5

Account

Grouping

Usage

VQY

Sample with account assignment

ZOB

Goods receipts without purchase order (movement type 501)

ZOF

Goods receipts without production order (movement types

521, 531)

Table4.3 Account Groupings for Transaction GBB (Cont.)

Purchase order with account assignment (KBS)



Transaction KBS is an entry that is required for technical reasons only. In

purchase orders with account assignment, the MM account assignment

does not have to identify a G/L account because the account assignment

is already dened in the purchase order. Transaction KBS therefore only

serves to specify the posting keys for the goods receipt posting.

Exchange rate rounding differences for Materials Management (KDR)



An exchange rate rounding difference can occur when an invoice in

foreign currency is received. If a balance is created when the invoice is

converted to the local currency, the system automatically generates a

posting line for exchange rate rounding differences.

Small differences in Materials Management (DIF)



Transaction DIF is used in invoice verication when you dene a toler-

ance limit for small differences and the balance of the invoice does not

exceed the tolerance.

Price differences (PRD)



Price differences occur for materials with a standard price for all move-

ments and invoices that are valuated at a price other than the standard

price. You will face price differences in the following examples:

Goods receipts for purchase orders if the purchase order price differs



from the standard price

Goods issues if an external amount is entered



Invoices when the invoice price differs from both the purchase order



price and the standard price

Price differences can also occur for invoices for materials with a moving

average price when there is insufcient stock coverage for the quan-

tity invoiced. For goods movements that would result in negative stock

balances, the moving average price does not change; instead, possible

price variances are posted to a price difference account.

298 Book_TIGHT.indb 121 12/4/09 3:48:06 PM

122

Procurement Process

Depending on the settings for the posting rules for Transaction PRD,

you can work with or without account grouping. If you work with

account grouping, the standard SAP system uses the groupings shown

in Table 4.4.

Account

Grouping

Usage

[BLANK]

Goods/invoice receipts for purchase orders

PRF

Goods receipts for production orders and order settlement

PRA

Goods issues and other movements

PRU

Price differences in the context of transfer postings

Account Groupings for Transaction PRD Table4.4

Delivery cost provisions (RUE)



Provisions for delivery costs are created when a condition type for pro-

visions is entered in the purchase order.

Unfortunately, the SAP system does not support provision clearing

against actual costs; therefore, this has to be done manually.

Income/expenditure from revaluation (UMB



)

Transaction UMB is used both in inventory management and in invoice

verication when the standard price of a material has changed and a

goods movement or an invoice is posted to the previous period (at the

previous price). You can only post in previous periods if period closing

for material masters is set accordingly. For more information on this

topic, refer to Chapter Section 7.5.1, Period Closing for the Material

Master.

Unplanned delivery costs



(UPF)

In the ideal case, the purchasing department has already entered the

conditions for the delivery costs in the purchase order. Unplanned

delivery costs are costs that are included in the vendor invoice (such

as freight or duty costs) but not specied in the purchase order. You

can either distribute these costs across the invoice items or post them

to a separate account. For the second variant, Transaction UPF must be

maintained in account determination.

GR/IR clearing (WRX)



Postings to the GR/IR clearing account occur when goods and invoices

are received for purchase orders. For more information on the GR/IR

account, refer to Section 4.8, GR/IR Account.

298 Book_TIGHT.indb 122 12/4/09 3:48:07 PM

123

Integration of MM and Financial Accounting/Controlling 4.5

Additional transactions are available, for example, regarding the material

ledger. However, the transactions listed here are the transactions you will

use most often.

To understand how MM account determination works is only one side of

the coin. It is just as important to understand what to do to rebuild account

determination.

Rebuild Process for Account Determination4.5.4

If you want to rebuild account determination in a result-oriented way, you

should perform the following steps:

Dene the a company code or plant as the valuation level.1.

Create a valuation grouping code and link it to the valuation areas.2.

Dene and assign valuation classes.3.

Dene G/L accounts and check whether cost elements are created for 4.

the relevant transactions.

Correct reported errors for the goods movements.5.

The rst step, dening the valuation level, involves an easy decision: If

you use PP or want to calculate products in Controlling, you must use the

plant as the valuation level.

The valuation classes are also usually not a problem. The critical question

is: Which material stock accounts does the accounting department want

to map in the nancial statement? One valuation class is required for each

material stock account. The resulting list of valuation classes should then

also be discussed with the cost accounting department because it may want

to be able to evaluate specic materials separately, for example, because

high stock values are expected for these materials or because extreme price

uctuations are likely, which are supposed to be analyzed separately. Track-

ing becomes easier if you use separate accounts for the mapping of stock,

expenditure, and income.

Afterward, you should dene a G/L account for the most important trans-

actions. Which transactions are critical depends on the business activities

of your enterprise. In a rst step, you could maintain the following trans-

actions and account groupings, for example:

Transaction BSX



Transaction GBB



With the AUA/AUF, VAX/VAY, and VBR account groupings

Dening the

valuation level

Dening the

valuation class

Dening G/L

accounts for

critical transactions

298 Book_TIGHT.indb 123 12/4/09 3:48:07 PM

124

Procurement Process

Transaction DIF



Transaction PRD



Transaction WRX



Learning by Mistakes

When rebuilding the MM account determination, you can spend a lot of

time with theoretical discussions about transactions, valuation classes, and

accounts in advance. Alternatively, you can deploy the “learning by mistakes”

method and directly start with the implementation.

This means: Congure the basic account determination that covers the mate-

rial stock accounts, the critical offsetting account assignments, and the GR/IR

accounts. All transactions of which you are not sure whether they are needed

or how they should be mapped in accounting are not maintained.

You then have to wait for error messages in Logistics. With each message on a

missing account determination, you can enhance the account determination.

However, for this procedure, short response times in the event of error mes-

sages are essential. Otherwise, you cannot test the Logistics components.

Usually, this procedure is of interest for everyone involved, because it shows

which transactions are posted in Logistics. Sometimes interesting technical

discussions about how to handle materials and their mapping in the nancial

statement may arise in this context.

Experience has shown that tables are best suited for the mapping of the MM

account determination. Among other things, the horizontal axis shows the

valuation classes. The vertical axis can list the movement types and transac-

tion keys with possible account groupings. In the matrix data area, you can

then dene the corresponding G/L accounts, separated by debit and credit

if required. If you need to map several parallel account determinations, you

should create a table for every VGC. Table 4.5 shows an example.

Tabular mapping of

the MM account

determination

Transaction

Movement

Types

Transaction/

Account

Grp.

VGC

Valuation Classes

Raw

Semi

Finish

Pack.

Goods receipt

101, 102, …

BSX

0001

39000

39100

39200

39300

Inventory

difference

701, 702

GBB INV

0001

35000

35020

35010

Inventory

difference

701, 702, …

GBB INV

0002

35040

35020

35010

Structure of a Microsoft Excel Table for the MM Account Determination Table4.5

(Excerpt)

298 Book_TIGHT.indb 124 12/4/09 3:48:07 PM

125

Integration of MM and Financial Accounting/Controlling 4.5

Finally, you have to clarify who is responsible for maintaining the MM

account determination. As with all interface topics, you can only achieve

the goal to set up reasonable account determination if the logistics,

accounting, and cost accounting departments work in close coordination.

Nevertheless, the accounting and/or cost accounting departments should

be responsible for maintaining the account determination because they

receive the data and have to meet the requirement that the material stock

and income statement accounts are correctly debited and credited for

goods movements.

You may not always be sure which posting is generated for an MM move-

ment type. For these situations, SAP provides an MM account determina-

tion simulation for experts. You can navigate to this simulation using the

Simulation button in Transaction OMWB.

In the

Simulate Inventory Management: Entry of Simulation Data

input screen, you must enter the plant, the material, and a movement type

(see Figure 4.27).

Simulation of the MM Account Determination—SelectionFigure4.27

In Figure 4.27, 101 is speci ed for the Movement Type in the selection

 eld. The system displays or updates the list below this  eld, which shows

the different goods receipts, when you con rm the entry of the movement

type with

(Enter). Select a variant from the list by double-clicking on it. It

is then highlighted in blue. The

Account Assignments button takes you

to the evaluation of the simulation (see Figure 4.28).

MM account

determination

simulation

298 Book_TIGHT.indb 125 12/4/09 3:48:07 PM

126

Procurement Process

Simulation of the MM Account Determination—EvaluationFigure4.28

The top  eld groups in Figure 4.28 show that the following information

has been derived from the plant:

Company code and thus chart of accounts.



Valuation area and thus valuation grouping code.



The valuation class is determined from the material.



The system uses the material type to check whether value updating is



enabled in this case.

The lower part of the screen displays all transactions that could be relevant

for the selected movement type. The list ranges from inventory manage-

ment to GR/IR account and purchase account determination. It indicates

which account is determined or if—as in this example—the account deter-

mination is not maintained for the purchase account and purchase offset-

ting account.

298 Book_TIGHT.indb 126 12/4/09 3:48:08 PM

127

Integration of MM and Financial Accounting/Controlling 4.5

The Check Screen Layout button (see Figure 4.28) enables you to navigate

to additional useful functions, namely, the comparison of the  eld groups

of movement type and G/L account. Both elements—movement type and

G/L account—individually de ne which  elds are ready for input or even

which  elds are mandatory entry  elds. However, it is possible that the

movement type in MM does not allow for transferring a cost center in the

material posting and at the same time, the cost center is a mandatory entry

for a G/L account that has been determined for the movement type in the

account determination. In this situation, the system outputs an error mes-

sage because the G/L account does not receive all necessary information.

The reconciliation function enables you to compare the  eld controls of

movement types and of the G/L accounts that have been determined in the

MM account determination.

Figure 4.29 shows this kind of comparison. A yellow minus indicates that

the  eld is hidden. A circle stands for an optional entry. Mandatory  elds

are illustrated by a plus.

Comparing the Field Controls of Movement Type and G/L AccountFigure4.29

You only need these two functions—simulation and  eld comparison—

when the system outputs an error message. In that situation, however,

they are very useful.

You have now met all requirements for a smooth integration of logistics

and accounting. All MM transactions that are relevant for the value  ow

Comparing the

 eld control

298 Book_TIGHT.indb 127 12/4/09 3:48:09 PM

128

Procurement Process

should now be transferred without any problems. Let us recall Figure 4.1

with the illustration of the adapted SCOR model. According to this model,

the goods receipt is the next process step after the purchase order.

Goods Receipt4.6

The decision whether goods receipts are necessary is already made in the

purchase order. The system generates a proposal on this using the account

assignment category, which you already know from Section 4.3, Purchase

Order as the Basis of the Procurement Process. The item category controls

whether you can overwrite this proposal.

The rst decision—whether the goods receipt should be posted in the

system—is rather easy. For stock material that is delivered at the gate with

a delivery note, you expect a goods receipt and can also post it accordingly.

For a drop shipment, the vendor delivers the goods directly to your cus-

tomers. This means that you do not post a goods receipt.

More complicated is the decision about whether the goods receipt should

be valuated or non-valuated. If you dene in the purchase order that the

goods receipt should be non-valuated, the valuation does not take place

until the invoice is received.

The best example of consequences of a decision about a valuated or non-

valuated goods receipt is the acquisition of an asset. This is an example

that is also frequently discussed in day-to-day work. For an asset acquisi-

tion, the time of the valuation denes when the asset is posted for the

rst time.

For a non-valuated goods receipt, the goods value is initially posted to a

clearing account only. When the invoice is received, the clearing account is

credited against the capitalized asset. This means that the relevant event for

the asset capitalization is not the goods receipt but the invoice receipt.

For a valuated goods receipt, the goods value is directly posted to the

asset when the goods are received. If it is a capitalized asset, the deprecia-

tion calculation begins when the goods are received. This is the common

method.

We will now take a look at an example with a purchase order for an asset.

For this purpose, a valuated goods receipt and an invoice receipt were

posted, as you can see in the purchase order status in Figure 4.30.

Are goods receipts

necessary?

Valuated/

non-valuated

goods receipt

“Asset acquisition”

298 Book_TIGHT.indb 128 12/4/09 3:48:09 PM

129

Goods Receipt 4.6

Purchase Order StatusFigure4.30 —Valuated GR for an Asset

The fact that both a quantity and an amount are speci ed in the Deliv-

ered

line (see Figure 4.30) also indicates that this is a valuated goods

receipt. This means that the purchase order has been delivered completely

and invoiced in the meantime. To view the date on which the goods and

invoice receipt were posted, you have to look at the history of the purchase

order item (see Figure 4.31).

Purchase Order HistoryFigure4.31 for the Asset Item

Here, you can see that the goods receipt was posted on 04/01/2009 while

the invoice was entered much later, on 04/26/2009. For a valuated goods

receipt, the asset has to use the date of the goods receipt. This is indicated

by the

Capitalized on  eld in the asset master in Figure 4.32.

From the value  ow perspective, the goods receipt does not include fur-

ther special aspects. For materials that are managed on a quantity and

value basis, the stock is built-up at this point and thus the stock value in

the  nancial statement increases.

The stock value may not be increased if you are not the owner of the goods.

An example of this is the vendor consignment stock. In this case, only an

MM document but no Financial Accounting document is generated when

the goods are received. Moreover, the goods are still the property of the

vendor. Regarding quantity, you have to enter the stock for your plant so

that you can include it in your production process.

Stock material

receipt

Vendor

consignment stock

298 Book_TIGHT.indb 129 12/4/09 3:48:09 PM

130

Procurement Process

Capitalization Date in the Asset MasterFigure4.32

Invoice Verification4.7

The term invoice veri cation can refer to different processes: to the techni-

cal veri cation and to the formal veri cation of an incoming invoice. This

ensures that a vendor invoice meets the legal requirements and can be

posted. An incoming invoice must include the following speci cations, for

example, to pass the invoice veri cation:

Name and address of the providing enterprise and of the debiting party



Tax number of the providing enterprise



Unique sequential invoice number



Issue date of the invoice (invoice date)



Quantity and standard description of the delivery or type and scope of



the service provided

Net amount for the delivery or service



Tax rate and amount (if the delivery or service is tax-exempt, this needs



to be speci ed explicitly)

Formal invoice

veri cation

298 Book_TIGHT.indb 130 12/4/09 3:48:10 PM

131

Invoice Verication 4.7

Any reduction of the amount to be paid that was agreed in advance,



such as discounts

Time of the delivery and service



Invoice and Delivery Date are Identical

You have to identify both dates, even if the invoice and delivery date are

identical. In this case, it is usually sufcient to refer to the delivery note num-

ber or make a note that the invoice and delivery dates are identical.

The goal here is not to check whether the invoice is factually justied but

whether it meets all legal requirements.

In addition to the formal verication, incoming invoices also need to be

factually veried. In this context, you should primarily clarify whether the

invoice amount is correct and whether the vendor has correctly provided

or delivered the agreed service or goods.

SAP systems cannot support formal invoice verication. Instead, software

solutions with handwriting recognition and the respective check routines

can be used instead. The problem is that vendor invoices have different

structures so that the support of a third-party system often does not have the

desired result. Enterprises with a high volume of incoming invoices tend to

outsource this schematic verication to countries with low wage levels.

For factual invoice verications, however, the SAP system provides a very

good tool: Logistics Invoice Verication. It is characterized by a high inte-

gration with MM and Financial Accounting/Controlling. Posting invoices

with Logistics Invoice Verication should be a standard process and is

therefore discussed in detail in this section.

Invoice Verication also Includes Credit Memos

At this point, it should be mentioned that we are still referring to invoices

and that the function is called Logistics Invoice Verication. However, you can,

of course, also post credit memos.

Invoice Verification Process4.7.1

Whether the system expects an invoice is dened by the account assign-

ment category in the purchase order—as is the case for the goods receipt. If

you dene here that you do not expect an invoice for an external purchase

order—that is, a purchase order that is provided to an external vendor—

the system assumes that the delivery is free of charge. Usually, however,

an invoice receipt is dened in the purchase order.

Factual invoice

verication

System support

Logistics Invoice

Verication

298 Book_TIGHT.indb 131 12/4/09 3:48:10 PM

132

Procurement Process

Another critical speci cation for invoice veri cation is made in the pur-

chase order. You de ne against what the invoice is checked: the purchase

order or the goods receipt (GR). You make this decision via the

GR-Based

Invoice Veri cation

checkbox. You can  nd this checkbox in the detail

view of the purchase order item on the

Invoice tab (see Figure 4.33).

Invoice Receipt Speci cations in the Purchase OrderFigure4.33

Let us take a closer look at the consequences of this decision using two

examples:

The invoice is received before the goods are received.



A partial delivery is received and the invoice is received afterward.



In the example, two purchase orders with 10 m2 of box calf leather are

created. In the  rst purchase order, the indicator for the GR-based invoice

veri cation is not selected; in the second purchase order, the indicator is

selected.

Let us assume that the vendor issues the invoice faster than delivering the

goods. The following section details what happens next.

Purchase Order Without GR-Based Invoice Veri cation

The invoice is checked against the purchase order. The SAP system gener-

ates a warning that no quantities have been posted yet (see Figure 4.34).

Message if the Invoice is Received Before theFigure4.34

Goods are Received—Without GR-Based Invoice Veri cation

However, this message is only a warning and does not prevent you from

posting the document. Nevertheless, in this case, the system automatically

blocks the document for payment because there is a quantity variance

because of the missing goods.

GR-based invoice

veri cation

“Invoice receipt

speci cations”

example

IR before GR

298 Book_TIGHT.indb 132 12/4/09 3:48:11 PM

133

Invoice Veri cation 4.7

Purchase Order with GR-Based Invoice Veri cation

The system behaves differently with GR-based invoice veri cation. Because

no goods receipt has been posted yet, the SAP system cannot verify the

invoice. It therefore prevents you from entering the invoice (see Figure

4.35).

Message for GR-Based Invoice Veri cation and Invoice Receipt Figure4.35

Before Goods Receipt

Although these messages are not actual error messages, they make it impos-

sible to enter the invoice with reference to the purchase order.

This system behavior indicates the  rst consequence of the

GR-Based

Invoice Veri cation

indicator: If it is selected, you cannot enter the

invoice until the goods receipt has been posted. For purchase order items

for which you do not expect timely postings of the goods receipt—for

example, for the weekly beverage delivery for the of ce—you should avoid

using GR-based invoice veri cation. Alternatively, you have to consider-

ably increase the discipline applied for posting the goods receipts.

Let us take a different situation as an example: First, the goods receipt and

then the invoice is posted. Because real life is not always as ideal as we

would like it to be, let us add another detail. According to the principle

“trust is good, control is better,” a proper incoming inspection also entails

counting the actual quantity and it is possible that only a partial delivery is

received instead of the entire ordered quantity. It is also possible that the

vendor is honest and has made a partial delivery due to delivery problems

on his end, for example. Therefore, let us assume that the vendor in the

example has production problems and can therefore only deliver 8 instead

of 10 m2 of leather. Unfortunately, the ordered 10 m2 were invoiced.

In both cases—with and without GR-based invoice veri cation—the sys-

tem provides only a quantity of 8 m2 for selection when you want to enter

the invoice using Transaction

MIRO (see Figure 4.36).

Item Proposal in the Invoice Receipt for Partial DeliveryFigure4.36

We will overwrite this proposal and post 10 m2 of our material at a net

price of EUR 2,000.00. The only consequence is an automatically set payment

GR with partial

delivery before IR

298 Book_TIGHT.indb 133 12/4/09 3:48:11 PM

134

Procurement Process

block due to the quantity variance between invoice and goods receipt. As

an alternative to the purchase order history, you can also have the system

display the status of the purchase order (Figure 4.37).

Purchase Order Status for Partial Delivery and Complete Invoice ReceiptFigure4.37

It is obvious that the vendor has invoiced more than delivered. You can

also see that it makes little difference whether you work with or without

GR-based invoice veri cation. Only the case where the invoice is received

before the goods receipt is posted is handled more restrictively for GR-

based invoice veri cation.

You were already introduced to the Logistics Invoice Veri cation settings

that are implemented by the purchasing department in the purchase order.

These settings include the de nition whether an invoice is expected at all

and against which material document—purchase order or goods receipt—

the invoice is checked. Let us take a step back and have a look at the

parameters that the invoice veri cation itself provides. You can  nd all cor-

responding settings in the Implementation Guide under

Materials Man-

agement

•

Logistics Invoice Veri cation.

The fact that Logistics Invoice Veri cation also creates both an MM doc-

ument and a Financial Accounting document often leads to discontent

among invoice veri cation clerks, particularly in the event of SAP imple-

mentations. One of the reasons for this is an admittedly unfavorable pro-

cedure in the SAP standard: When an invoice is posted, the SAP system ini-

tially only displays the MM document number. However, this document

number is usually rather uninteresting because—as for any other Financial

Accounting transaction—the system shows the Financial Accounting docu-

ment number in the line item display of the vendor account. There are two

solutions to this situation:

The MM document number is also used as the Financial Accounting



document number.

In the message that indicates that a document has been posted, the sys-



tem displays the Financial Accounting document number in addition to

the MM document number.

Customizing of the

Logistics Invoice

Veri cation

Document number

assignment

298 Book_TIGHT.indb 134 12/4/09 3:48:11 PM

135

Invoice Veri cation 4.7

In the early Logistics Invoice Veri cation years, only the  rst variant was

available. You had to provide external number assignment for the Financial

Accounting number range to have the system use the MM document num-

ber. Additionally, you had to deactivate the buffering of the MM number

assignment, which also leads to an improved posting performance. How-

ever, because the buffer is rebuilt regularly, independently of whether it

has been used to its full extent, gaps between the numbers occur. These

gaps also continue to exist in the Financial Accounting component, which

is not permitted regarding revision.

Procedure for Deactivating the Buffering

SAP Note 62077 (Info: Internal Number Assignment is Not Continuous) de-

scribes the detailed procedure for deactivation of buffering. This is a modi -

cation of the system, which should usually be avoided, because modi cations

entail additional work in the event of release changes.

In this case, however, the modi cation is not critical and therefore also justi-

 able from the point of view of the IT.

In the meantime, SAP has developed an easier solution, which you can

completely implement in the standard SAP system. For this purpose, you

only have to expand the parameters in the user master. Users can maintain

their master using the

System

•

User Pro le

•

Own Data menu path (see

Figure 4.38).

Changing the User Pro le for Logistics Invoice Veri cationFigure4.38

Next, you have to specify the IVFIDISPLAY entry on the Parameter tab and

add a large X. After you have saved the settings, the system reports both

document numbers when you post incoming invoices (see Figure 4.39).

Display with MM and Financial Accounting Document NumberFigure4.39

With this information, you considerably facilitate the work of invoice veri-

 cation clerks without having to implement modi cations.

Buffering

deactivation

Adapting the

information

message

298 Book_TIGHT.indb 135 12/4/09 3:48:12 PM

136

Procurement Process

Material Document Number in a Reference Field

The standard SAP system writes the number of the material document to the

Reference Key  eld in the accounting document header. Therefore, if you

want to view Financial Accounting and MM document numbers in the line

item display of accounts payable accounting, you have to permit the BKPF-

AWKEY  eld in the line item display.

You can initiate this in the Implementation Guide, for example, under

Financial Accounting (new)

•

Accounts Receivable and Accounts Payable

•

Vendor Accounts

•

Line Items

•

Display Line Items

•

De ne Additional

Fields for Line Item Display.

We will now proceed with the Logistics Invoice Veri cation posting

technologies.

Logistics Invoice Veri cation uses MM account determination. Section

4.5.3, Determining Transactions, already described that there is a speci c

transaction key for unplanned delivery costs and that there are two posting

options. You can make the following decisions:

Whether you divide the additional costs between the purchase order



items

Whether you want to post a special G/L account line



For materials with moving average price, the  rst variant ensures that the

price will be adjusted. For materials with a standard price, a posting is made

in the price variances. You cannot make this decision for each case individu-

ally because it is a permanent speci cation at the company code level. You

implement the corresponding setting in the Implementation Guide under

Materials Management

•

Logistics Invoice Veri cation

•

Incom-

ing Invoice

•

Con gure How Unplanned Delivery Costs Are Posted.

Unplanned delivery costs are a special invoice veri cation case. They are

posted at the header level and not at the posting item level to allow for a cost

distribution across the purchase order items if required (see Figure 4.40).

Posting Unplanned Delivery CostsFigure4.40

You have to post unplanned delivery costs on the Details tab. The follow-

ing sections describe two posting examples.

Unplanned

delivery costs

298 Book_TIGHT.indb 136 12/4/09 3:48:12 PM

137

Invoice Veri cation 4.7

Posting Unplanned Delivery Costs with Distribution

Figure 4.41 displays the Financial Accounting document of an invoice

receipt.

Distribution of Unplanned Delivery CostsFigure4.41

This document contains two purchase order items that were posted to the

GR/IR account (items 2 and 4). Furthermore, you can also see that a post-

ing to the raw materials account was made twice (see

and

in Figure

4.41). This indicates that the ordered materials have a moving average

price because materials with a standard price would be posted to a price

difference account. The unplanned delivery costs of EUR 200.00 are there-

fore directly added to the stock value of the two materials.

Posting of Unplanned Delivery Costs in a Separate Line

This is different for the Financial Accounting document when you do not

distribute the unplanned delivery costs but instead post them in a separate

line (see Figure 4.42).

Special Posting of Unplanned Delivery CostsFigure4.42

Here, you can see that the EUR 200.00 of unplanned delivery costs were

posted in their entirety to account 231600. The prices of the two ordered

materials are consequently not increased, and the entire amount is posted

as expenditure. However, you can easily recognize the problem with this

posting: The system cannot derive a useful Controlling account assignment.

This means you can either treat account 231600 as a neutral account by

creating no cost elements for it or, alternatively, de ne a standard account

assignment, for example, via Transaction OKB9.

298 Book_TIGHT.indb 137 12/4/09 3:48:13 PM

138

Procurement Process

In real life, you will often come across invoices that do not refer to a pur-

chase order. In these cases, you can post the invoice without integration

with MM, which is discussed in Section 4.9.1, Invoice Receipt Without

MM Integration. Or you can use Logistics Invoice Verication. For this

purpose, however, you have to enable this kind of posting rst. You can

nd the corresponding Customizing in the Implementation Guide under

Materials Management

•

Logistics Invoice Verication

•

Incom-

ing Invoice

•

Enable Direct Posting to G/L Account and Material

Accounts.

Transaction MIRO provides the corresponding tabs only when

you enable the functions here.

Considering Tolera4.7.2 nces

The procurement process can include numerous variances. Some of them

can be tolerated such as differences of a few cents in an invoice due to the

summation of all invoice items.

Other variances are not acceptable such as an obvious price difference

between purchase order and invoice. To set a limit for variances you are

willing to accept, you have to dene tolerance limits in Customizing.

Depending on your individual situation, you can maintain various toler-

ances. The standard SAP system provides the following tolerances:

AN amount for item without purchase order reference



AP amount for item with purchase order reference



BD form small differences automatically



BR percentage OPUn variance (IR before GR)



BW percentage OPUn variance (GR before IR)



DQ exceed amount: quantity variance



DW quantity variance when GR quantity = zero



KW variance from condition value



LA amount of blanket purchase order



LD blanket purchase order time limit exceeded



PP price variance



PS price variance: estimated price



ST date variance (value * days)



VP moving average price variance



Posting without

purchase order

reference

Acceptable

variances

Individual

tolerance limits

298 Book_TIGHT.indb 138 12/4/09 3:48:13 PM

139

Invoice Verication 4.7

You cannot add custom tolerances to this list of what are called tolerance

keys.

Normally, all tolerance settings have the same structure. You can dene

an upper and a lower limit for the variance; additionally, the variance is

dened in absolute amounts and in percentages.

The denition of upper and lower limits enables you, for example, to pre-

vent vendors from considerably exceeding or going below the price that

has been agreed in the purchase order. By setting an absolute tolerance in

amounts and additionally a tolerance in percentages, you avoid that you

dene unwanted high tolerance limits.

Specifying Tolerance Limits in Absolute Amounts and in Percentages

If you dene the percentage for the price overrun at ve percent, this would

be EUR 5.00 for an invoice item of EUR 100.00. For an invoice item of

EUR 100,000.00, the tolerance would be EUR 5,000.00, which is probably

not what you want.

You can prohibit this system behavior by dening that a maximum of

EUR 10.00 variance is allowed. With this setting, you would tolerate a price

variance of EUR 5.00 in the rst case and of EUR 10.00 in the second case.

You implement the Customizing of tolerance limits in the Implementation

Guide under

Materials Management

•

Logistics Invoice Verication

•

Invoice Block

•

Set Tolerance Limits. Figure 4.43 displays the denition

of the tolerance limits for price variances in the Lederwaren-Manufaktur

Mannheim company code as an example.

As you already know, there are numerous tolerance limits that can be

checked, however, you do not have to use them all. For example, the AN

and AP tolerance keys are often deactivated for the check of the permitted

maximum amount for each document item.

The BD tolerance key enables you to accept that an invoice document ini-

tially does not balance to zero. This can happen especially if the taxes for

the individual items lead to a smaller amount than the tax calculation for

the total net amount. To be able to post the invoice without problems in

such situations, you should allow for a small tolerance of approximately

EUR 2,00.

Denition of upper

and lower limits

AN and AP

tolerance keys

The BD

tolerance key

298 Book_TIGHT.indb 139 12/4/09 3:48:13 PM

140

Procurement Process

Tolerance Limits for Price VariancesFigure4.43

Figure 4.43 displayed the PP tolerance keys for basic price variances. How-

ever, there is also a speci c tolerance key (the KW tolerance key) for price

variances for delivery costs.

Furthermore, there is the PS key for price variances for estimated prices.

With this, the purchasing department can insert a note in the purchase

order if the purchase order price is estimated. In this case, you would allow

for larger variances than for normal purchase orders with  xed prices/

prices agreed upon with the vendor.

Setting the PS Tolerance Key by Default

Unfortunately, some purchasers set the “estimated price” indicator regularly

because they know about higher tolerance limits. This reduces the number

of questions the purchaser receives from the invoice veri cation department.

Thus, you should think twice before setting higher tolerance limits.

Finally, SAP also supports you in verifying blanket purchase orders by

enabling you to de ne tolerances for the amount (LA key) and schedule

ful llment (LD key).

The VP tolerance key is also quite interesting. It compares the moving

average price before the invoice receipt with the moving average price

PP, KW, and PS

tolerance keys

LA and LD

tolerance keys

The VP

tolerance key

298 Book_TIGHT.indb 140 12/4/09 3:48:14 PM

141

Invoice Verication 4.7

after the invoice receipt. If the difference is too large, the system blocks

the invoice for payment.

If the amount exceeds or falls below all mentioned tolerances, the SAP sys-

tem indicates the reason for the variance in the document and blocks the

open vendor item for invoice. The system also supports you in releasing

blocked invoices as you will see next.

Automatically Releasing Blocked Invoices4.7.3

To automatically release blocked invoices, you use Transaction MRBR

(Release Blocked Invoices). If you start the report with the automatic

invoice release option, the system checks for every automatically blocked

invoice if the invoice blocking reason still exists. If not, the system releases

the payment block.

Releasing the Payment Block

For example, if no goods have been received, the system blocks the invoice

due to quantity variances. After the respective goods receipt has been posted,

you can pay the invoice.

If there is a price difference, you have to inform the purchasing department

after having entered the invoice. This can be done manually or automatically

using a workow. If the purchasing department adapts the purchase order af-

ter having claried the price issue, the invoice can be released for payment.

Regardless of the elimination of the invoice blocking reason, you can also

delete the invoice blocking reason manually using Transaction MRBR. For

this purpose, you have to start the report using the

Release Manually

option.

Scheduling Transaction MRBR

Schedule the transaction every night using the Automatic Release option

and send the result list to the printer of the responsible accountant. This

ensures that all invoices are released as soon as the reason for the payment

block is eliminated.

This concludes our discussion of entering incoming invoices. In this con-

text, we also came across the GR/IR account, which is described in further

detail in the following section.

Outside of

tolerances

Automatic release

Manual release

298 Book_TIGHT.indb 141 12/4/09 3:48:14 PM

142

Procurement Process

GR/IR Account4.8

You already know that the goods receipt and the invoice receipt involves

the GR/IR account if the corresponding goods receipt and the invoice

receipt refers to an invoice.

Posting to the GR/IR Account4.8.1

To allow for high automation, GR/IR accounts are also dened in the MM

account determination. This was explained in detail in Section 4.5.3, Deter-

mining Transactions. You normally use the GR/IR account independently

of valuation classes. Many times, only one GR/IR account is used.

From the accounting perspective, the GR/IR account is a balance sheet

account that is not mapped in the nancial statement because it is just a

clearing account. This is discussed in more detail later on. Then what is the

reason for this account?

In college, you learned the following posting record:

Material Stock

Tax

Payables

In real business life, however, you will have noticed that this posting

record does not exist in this form. In this posting record, the goods move-

ment and the accrual of the payables are posted simultaneously. From the

business perspective—and also according to the SCOR model—these are

two different transactions: rst goods receipt and then invoice receipt.

This separation of goods and invoice receipt is implemented using the GR/

IR account. Figure 4.44 shows a posting example.

90100 Leather Supplier Greiner 300000 Raw Material Stock

191100 GR/IR

(1) EUR 2,000.00

(2) EUR 2,000.00 (1) EUR 2,000.00

(2) EUR 2,000.00

Posting Example—GR/IR AccountFigure4.44

The WRX

transaction

Purpose of the

GR IR account

298 Book_TIGHT.indb 142 12/4/09 3:48:14 PM

143

GR/IR Account 4.8

Let us take the previous purchase order of 10 m2 of box calf leather with

EUR 200.00 each as an example—you can  nd the goods receipt (10 m

) of

EUR 2,000.00 and the invoice receipt (10 m

) of EUR 2,000.00.

As agreed, the vendor delivered 10 m

of leather. These are posted to the

material stock account for raw materials. The GR/IR account is the offset-

ting account. The value can be derived from the price according to the

purchase order, multiplied by the actual quantity of goods received.

With the invoice receipt, the vendor account is debited. For the offsetting

account assignment, the GR/IR account is used. The following is the ideal

situation: The purchase order was delivered in full and invoiced and there

are no quantity or price variances. Therefore, the GR/IR account is cleared

for this purchase order. But the clearing cannot be implemented directly,

neither through the goods nor through the invoice receipt. Instead, it is

part of the GR/IR account maintenance, which must be done with urgency

and on a regular basis—at the latest, when preparing closing operations.

Clearing the GR/IR Account4.8.2

For clearing, use the function for automatic clearing of G/L accounts in

Financial Accounting. You can  nd this function in the user menu under

Accounting

•

Financial Accounting

•

General Ledger

•

Periodic Pro-

cessing

•

Automatic Clearing

•

Without Speci cation of Clearing

Currency

(or directly via Transaction F.13). In this case, the system tries

to clear open items on the account according to de ned rules. You de ne

the rules in Customizing under

Financial Accounting (New)

•

Gen-

eral Ledger Accounting (New)

•

Business Transactions

•

Open Item

Clearing

•

Prepare Automatic Clearing. Here, you can specify which

 elds of the open items have to match so that the items can be grouped.

Figure 4.45 displays the default settings.

Default Settings—Automatic ClearingFigure4.45

The de nitions are made for each account type and at intervals if required.

In our case, the ZUONR (assignment number), GSBER (business area), and

VBUND (trading partner number)  elds must match. In our small sample

enterprise, the check whether these three  elds match is suf cient. In real

Automatic clearing

298 Book_TIGHT.indb 143 12/4/09 3:48:15 PM

144

Procurement Process

life, however, you should additionally de ne the purchasing document

number (EBELN) and item (EBELP) for the GR/IR account. The system

groups all documents that contain identical entries. If the grouped doc-

uments balance to zero, the system proposes or implements automatic

clearing.

Let us have another look at the example from Section 4.7.1, Invoice Veri -

cation Process, and consider this situation for clearing via Transaction F.13.

Three items are found on the GR/IR account of which two match in the

relevant  elds (according to the Customizing shown in Figure 4.45) so that

the system identi es that they belong together. Because the group balances

to zero, the system clears the open items (see Figure 4.46).

Clearing the GR/IR Account Using Automatic ClearingFigure4.46

The two document items highlighted in green are cleared. The system

also displays the number of the resulting clearing document. Due to the

SAP General Ledger and the activation of document splitting, there is one

essential innovation for the clearing document (see Figure 4.47).

Clearing Document from the GR/IR Account MaintenanceFigure4.47

Clearing

transaction

Clearing document

298 Book_TIGHT.indb 144 12/4/09 3:48:16 PM

145

GR/IR Account 4.8

As you can see in Figure 4.47, the document now includes line items. Prior

to the introduction of the SAP General Ledger and its document splitting,

the document consisted of a document header only and no document

items were posted.

Transaction F.13 provides two additional functions we used in our exam-

ple: You can consider implementing tolerance limits and reduce the criteria

for the grouping of documents on the GR/IR account.

Considering implementation of tolerances



Considering the implementation of tolerances for exchange rate differ-

ences and rounding differences enables you to clear documents despite

small variances in the amount. The system then posts the difference to

the respective expense or revenue account.

Reducing criteria for the grouping of documents on the GR/IR account



Alternatively, you can also reduce the rules for the grouping of docu-

ments. In the standard, the link is implemented via the purchase order

number and item. For GR-based invoice verication, you can also

implement the grouping via the material document. This is only useful

if the link via the purchase order is not meaningful for, for example,

scheduling agreements.

However, Transaction F.13 does not provide support for deviating goods or

invoice receipts—for example, if no goods or invoice receipts are expected

for a purchase order or if the existing documents cannot be cleared due to

quantity variances. You can clear them in the GR/IR account maintenance

using Transaction MR11. You can nd this transaction in the user menu

under

Logistics

•

Materials Management

•

Logistics Invoice Veri-

cation

•

GR/IR Account Maintenance

•

Maintain GR/IR Clearing

Account

You can start the program automatically or manually. In automatic opera-

tion, the system can write off open items for which the delivery quantity

is larger than the quantity invoiced or for which the quantity invoiced

exceeds the delivery quantity. If all expected goods and invoices have been

received but the purchase order quantity has not been reached, you have

to clear the items manually.

For these transactions, you do not have to congure a specic account

determination. The system works with the settings that are also used for

Transaction F.13

GR/IR Account

Maintenance with

MR11

Automatic or

manual start

Posting

congurations

298 Book_TIGHT.indb 145 12/4/09 3:48:16 PM

146

Procurement Process

the invoice receipt. The possible posting records depend on the price con-

trol of the materials or on the purchase order. The following posting con-

gurations are likely:

Purchase orders with account assignment



The offsetting entry is posted to the account assignment that is dened

in the purchase order.

Material



with standard price

The offsetting entry is posted to the price difference account.

Material



with moving average price

If the stock level is greater than/equal to the difference quantity, the

posting is made to the material stock account (this corresponds to a

revaluation). If the stock level covers the difference quantity, the offset-

ting entry is posted to the price difference account, as is the case for

materials with a standard price.

It has already been mentioned that the GR/IR account is not mapped in

the nancial statement. However, to ensure that the nancial statement is

correct, all values on the GR/IR account that exist at the time the nancial

statement is created need to be reposted to other accounts. This repost-

ing is implemented at the period key date and reversed in the subsequent

period. Both is done using Transaction F.19. When the posting is made,

however, the GR/IR account is not addressed directly to set a zero bal-

ance. Rather, the zero balance is set using an adjustment account, which is

mapped in one item in the balance sheet structure together with the GR/IR

account. This means that the zero balance is not set on the GR/IR account

but on the corresponding balance sheet item. The repostings are usually

implemented on two accounts:

An account that maps invoice receipts for which no goods have been



received

An account for goods receipts for which the vendor has not yet issued



an invoice

The account determination here is not part of the MM account determina-

tion, because the postings are exclusively made in the G/L. You can nd

the corresponding settings in the Implementation Guide under

Financial

Accounting (New)

•

General Ledger Accounting (New)

•

Periodic

Processing

•

Reclassify

•

Dene Adjustment Accounts for GR/IR

Clearing.

Figure 4.48 shows an example.

Mapping in the

nancial statement

using F.19

298 Book_TIGHT.indb 146 12/4/09 3:48:16 PM

147

Integration of Accounts Payable Accounting 4.9

Account Determination for the Reclassi cation of the GR/IR AccountFigure4.48

Here, you can see Transaction BNG (Invoiced but not yet delivered).

For our 191100 GR/IR account, the 191199 adjustment account has been

de ned as the account to which the posting is made instead of the GR/IR

account. The 191101 account is the target entry, which is mapped along

with the stocks in the  nancial statement. It should be mapped in the

 nancial statement because goods have been received for the received

invoice, which means that a material value exists. In the other case—

material has been delivered, but not invoiced—Lederwaren-Manufaktur

Mannheim makes the posting to the 191102 account (

Delivered but not

yet invoiced

). Here, you have to maintain Transaction GNB. The  nan-

cial statement maps the 191102 account in other provisions. The GR/IR

account and the 191199 adjustment account balance to zero, which means

that the adjustment account must be mapped in the not assigned accounts,

along with the GR/IR account.

Account Control of the GR/IR Account

For GR/IR accounts, the balance indicator must only be set for the local cur-

rency. Otherwise, there may be problems when you clear open items with

foreign currencies.

From a business perspective, this is not a problem because foreign currencies

are not relevant for GR/IR accounts.

Let us now turn our attention from general ledger accounting to the sub-

sidiary ledger—that is, accounts payable accounting.

Integration of Accounts Payable Accounting4.9

In accounting, the FI-AP subcomponent (Accounts Payable) maps all trans-

actions that affect vendors. FI-AP is accounts payable accounting with an

integration into general ledger accounting, and its account assignment

298 Book_TIGHT.indb 147 12/4/09 3:48:16 PM

148

Procurement Process

object is the vendor master. In addition to the entry of incoming invoices

via Logistics Invoice Verication, which was described in Section 4.7.1,

Invoice Verication Process, you can also directly enter invoices and credit

memos in Accounts Payable.

Invoice Receipt Without MM Integration4.9.1

The lack of integration with MM and Purchasing is a problem when the

data should be directly entered in FI-AP. It means that you cannot access

purchase orders. You also cannot post materials that are subject to inven-

tory management. This method is particularly suited for “minor” invoices,

such as for the ower pot that is paid from the department’s kitty. These

transactions are often called secondary businesses.

These kinds of documents are usually not posted with the RE document

type, but—if you use the standard SAP system—with the KR document

type for invoices and the KG document type for credit memos. Unlike

the document types from Logistics Invoice Verication, these document

types do not use the same number range. This—as well as the necessity of

an additional input screen and the missing verication against a purchase

order or goods receipt—is often the reason why invoice verication clerks

do not fully accept this screen variant. You can address this by providing

an option in Logistics Invoice Verication for postings to G/L accounts.

This enables invoice verication clerks to enter all incoming invoices with

a standardized transaction. For more information, you can also refer to the

descriptions in the context of Logistics Invoice Verication in Section 4.7,

Invoice Verication.

The direct posting of invoices to Accounts Payable is useful, however, if

you have to enter recurring documents at regular intervals. A prominent

example of this is rent. In this case, the amount, account assignment, and

due dates are known over a longer period and normally stay the same. To

facilitate the regular posting of such documents for user departments, the

SAP system provides what are called recurring entries. They work exactly

like standing orders at a bank. You dene the posting with the complete

account assignment, the amounts, the start date, and the end date as well

as the desired cycle (for example, monthly, weekly). This information is

then stored in a recurring entry original document, which is an accounting

document that does not trigger updating the transaction gures. You can

consider it a template for the actual postings. At regular intervals, usually

Lack of integration

Deviating

document type

and number

Recurring entries

298 Book_TIGHT.indb 148 12/4/09 3:48:16 PM

149

Integration of Accounts Payable Accounting 4.9

monthly, the system starts a job that checks all original documents and

generates the respective posting if required.

This tool has the following advantages:

Reduction of the work involved in accounting because you do not have



to re-enter documents every time they recur

Reduction of error sources because the number of manual entry opera-



tions has been reduced

The “Recurring Entries are Selected Incorrectly” Error Message

At the beginning of a new scal year, the Financial Accounting component

administrators are frequently addressed even by experienced colleagues

with the following cry for help: “I’ve entered a new original document, but

the system does not post it! The job does not select our recurring entries

correctly!”

The solution to this is usually quite simple: In the selection criteria of the

processing program, a scal year or a variable has been dened. As a result,

the system veries the scal year of the original document, but not the scal

year of the documents that are supposed to be posted. The simple solution is

to not enter a scal year at all!

Regardless of how invoices get into an SAP system—they have to be paid

sometime. This is the task of the payment run.

Outgoing Payments4.9.2

The payment run is an accounting tool that enables you to trigger all exist-

ing payments automatically. In many enterprises, the majority of payments

refer to due vendor invoices. However, you can also pay credit memos to

customers or fulll other payment obligations. SAP supports the common

methods such as payments via bank transfers, checks, bills of exchange,

or lockbox procedures. These procedures are called payment methods in

the SAP world.

The behavior of an individual payment run depends on different factors

such as the Customizing of the payment program, the information from

vendor master and single document, or the parameters of the current pay-

ment run (see Figure 4.49).

Functional scope

of the payment run

298 Book_TIGHT.indb 149 12/4/09 3:48:16 PM

150

Procurement Process

Behavior of the Payment Run:

– What Will Be Paid?

– Which Media are Used for Payment?

Information from the

Vendor Master

Information from the

Single Document

Customizing of the

Payment Program

Parameters of the

Current Payment Run

Inuencing Factors of a Payment RunFigure4.49

You can nd the Customizing of the payment program in the Implementation

Guide under

Financial Accounting (New)

•

Accounts Receivable and

Accounts Payable

•

Business Transactions

•

Outgoing Payments. Here,

for every company code that should map outgoing payments, you have to

dene the valid payment methods. For each payment method, you specify a

minimum and a maximum amount, for example. Additionally, you dene

whether payments in foreign currencies or to foreign banks are allowed and,

if required, which forms have to be printed. Furthermore, you dene for

each payment method which information is required, for example, the ven-

dor address for payments by check or the bank details for bank transfers.

Because enterprises today typically have more than one bank account and

often at different banks, bank determination needs to be congured. Here,

depending on the payment methods and currencies, you can dene a rank-

ing of the house banks and accounts. In the standard SAP system, the bank

determination is part of Customizing. An option for changing the ranking

of house banks and accounts in the course of day-to-day operations is not

provided. However, many users want to keep the option for possible short-

term adjustments open. You can meet this user department requirement

by dening tables T042A and T042D as current settings.

SAP Notes on Bank Determination

For further information on the exact procedure for bank determination, re-

fer to SAP Notes 77430 (Customizing: Current Settings), 69642 (Planned

Amounts [T042D] Cannot be Maintained), and 81153 (Bank Selection as a

Current Setting).

You have two options for selecting the payment method that should be

used for an individual open item: by denition in the company code-spe-

cic data of the vendor master or directly in single documents. Normally,

the payment method is dened in the vendor master. You should select

the option of assigning the payment method at the document level only

Customizing of the

payment program

Bank

determination

Information from

the vendor master

and single

document

298 Book_TIGHT.indb 150 12/4/09 3:48:17 PM

151

Integration of Accounts Payable Accounting 4.9

if you want to use a speci c payment method for individual documents.

If a payment method is speci ed twice, the more speci c de nition wins;

that is, the single document. You can always de ne more than one pay-

ment method in the

Payment Methods  eld. If there are several entries,

the priority of the entries decreases from the left to the right—that is, the

 rst entry from the left usually wins.

Figure 4.50 shows an example. Here, three entries are maintained in the

Payment Methods  eld: U for domestic bank transfer, S for payment by

check, and

L for foreign bank transfer. A payment run that provides for all

three payment methods pays open items of vendor K1100 via domestic

bank transfer because this payment method comes  rst. A payment run

that only allows for payment by check or foreign bank transfer, in contrast,

would pay the vendor invoices with a check.

The vendor master also contains the bank details.

Using the Partner Bank Type

Lederwaren-Manufaktur Mannheim has a leather supplier that supplies both

the German and the Belgian production. The invoices of the supplier are

directly paid by the respective branch of ce. Let us assume that the supplier

has a German and a Belgian bank account. To minimize costs, the transfers

should be made nationally: Brussels makes it payments to the Belgian vendor

bank account and Mannheim to the German vendor bank. You can imple-

ment this using the partner bank type.

First, create the two bank accounts in the general vendor master view. For ex-

ample, the Belgian account obtains the BE partner bank type and the German

account the DE partner bank type. All invoices of this supplier that specify

the BE partner bank type are now paid against its Belgian bank account and

all with the DE partner bank type against the German account.

If the document does not de ne a partner bank type, the system always uses

the  rst bank in the vendor master.

Payment Methods in the Vendor MasterFigure4.50

298 Book_TIGHT.indb 151 12/4/09 3:48:17 PM

152

Procurement Process

The payment run also allows you to set parameters you can use to con-

 gure the payment of open items. To do so, navigate to the payment run

using Transaction F110 or in the user menu via

Accounting

•

Financial

Accounting

•

Accounts Payable

•

Periodic Processing

•

Payments.

Here, you have to specify a scheduled execution day as well as an alpha-

numeric ID. It is important to know that the day of the execution is not

relevant for the open items that are supposed to be selected or the value

date of the payment. These are de ned in the payment run.

De nition of the Parameters in the Payment RunFigure4.51

Figure 4.51 shows an example of the parameter de nition in a payment

run. Here, you can  nd the posting date that is used for the accounting

documents. You use the

Documents entered up to and Customer items

due by

 elds to de ne which documents should be considered. In addi-

tion, you must enter various vendor and/or customer accounts that the

payment run should take into account.

The payment run de nes for which

Company Codes payments are made

and which

Payment Methods are considered. In this case also, the rule

applies that the payment method on the very left has a higher priority

than the one on its right. Via the date in the

Next posting date  eld, the

SAP system determines which open items that are not yet due have to be

paid. Let us look at an example of an open item that is due on 08/15 (see

Table 4.6).

Payment run

parameters

298 Book_TIGHT.indb 152 12/4/09 3:48:18 PM

153

Integration of Accounts Payable Accounting 4.9

Payment Run

Date

Next Posting

Date

Behavior

08/10

08/12

The document is not paid because

the next payment run takes place

before the due date (08/15).

08/10

08/18

The document is paid because it

would be overdue for three days in

the next payment run (08/18).

Due Date and PaymentTable4.6

However, you can also set grace days for yourself in Customizing. For

example, if you dene three grace days for this example, the open item

will not be paid on 08/10 in the second case.

Activating the Additional Log

The SAP system allows for easy logging of the payment run, which enables

you to easily track why the SAP system has (or has not) paid an open item or

why a discount is used (or not).

For this purpose, you need to activate enhanced logging for the payment run

on the Additional Log tab. This is strongly recommended for all vendors and

customers considered in the payment run.

During the further course of the payment run, the system creates a pay-

ment proposal. You can modify it by blocking items for payment or releas-

ing blocked items for payment. However, this blocking (or releasing) of

invoices applies only to this specic payment run. If you want to perma-

nently block an invoice payment, you have to directly navigate to the doc-

ument using Transaction FB02 and set a permanent payment block there.

Permanent Payment Block Overrides Bank Account Determination

Especially in medium-sized enterprises, the decision of which invoices will be

paid and which will not be paid is made without system support. The enter-

prises often suspect that invoices could be paid “by mistake.” However, you

cannot block all invoices for payment by default because a payment block in

the document prevents the system from determining the paying bank in the

payment run. This means that if you release the payment block when mo-

difying the payment proposal, you have to manually select the bank account

from which you want to make the payment.

It is only during the update run that the system makes a posting “vendor

to bank clearing” and thus clears the open item. In the last step, you can

Grace days

Payment proposal

298 Book_TIGHT.indb 153 12/4/09 3:48:18 PM

154

Procurement Process

send a payment medium le to the bank or print payment advices, checks,

bills of exchange, and so on.

After your bank has executed the payment request, the purchasing process

is complete from the accounts payable accounting view. But there is still

another leg of the value ow, which leads you from the invoice receipt

directly to G/L accounting and maps the taxation of purchases.

Although numerous tax types are involved when purchasing goods

or services, we want to focus on a widely used type: the tax on sales/

purchases.

Mapping the Tax on Sales/Purchases4.10

In the SAP system, the tax code is the central object for mapping tax on

sales/purchases. It denes the type as well as the calculation and posting

of taxes.

Tax codes enable you to map the input and output tax. There are also tax

codes for the handling of withholding taxes, which are particularly critical

in Southern Europe. They will not be discussed in further detail here.

You can nd the settings for the tax on sales/purchases centrally in the

Financial Accounting component. Customizing takes place in the Implemen-

tation Guide under

Financial Accounting (New)

•

Financial Account-

ing Global Settings (New)

•

Tax on Sales/Purchases. The standard SAP

system provides country-specic pricing procedures, called tax procedures,

which meet country-specic basic taxation conditions. However, you should

always check the settings for any new SAP system implementation.

You need to assign a tax procedure to every country in which you perform

business transactions that are subject to taxes on sales/purchases. In turn,

the tax procedure is assigned a tax code. This means that tax procedures

must include all required tax types and rates in the form of tax codes. For

example, if accounts need to be assigned for Belgian taxes on sales/pur-

chases for an incoming invoice in Germany, a code is required that enables

you to determine the Belgian tax correctly and clearly identify it for the

tax return later on.

You maintain the tax codes using Transaction

FTXP. The system indirectly

determines which tax code is used by initially querying the country. Let

us continue with the VN tax code, which was already used in the sample

postings (see Figure 4.52).

Tasks of the

tax code

Attributes of a tax

procedure

Scope of tax

procedures

Maintaining

tax codes

298 Book_TIGHT.indb 154 12/4/09 3:48:18 PM

155

Mapping the Tax on Sales/Purchases 4.10

Maintaining the VN Tax CodeFigure4.52

This example shows the input tax code for a taxation of 19 percent. To

determine the tax amount, the system uses only active lines of the proce-

dure. You can identify them because they are highlighted in blue writing.

In this example, it is level 120.

The account determination is also de ned at the tax code level. This means

that you only have to specify the tax code in the posting process. The sys-

tem can then assume the determination and posting processes. Both in

the procurement process and in the sales and distribution process, this

provides for signi cant advantages for the upstream MM and SD compo-

nents. They only have to identify the correct code; the Financial Account-

ing component then assumes further processing. The tax procedure also

de nes the basic screen, including the lines.

Figure 4.53 provides a schematic overview of the Customizing.

Transferring the Sales Tax Code

Sales tax codes have the disadvantage that they may not be correctly trans-

ferred to the target system. The SAP system therefore provides a download

and upload function for which the target client needs to be modi able. When

you create individual codes, the direct maintenance is usually less time-con-

suming in the target system.

Account

determination

298 Book_TIGHT.indb 155 12/4/09 3:48:19 PM

156

Procurement Process

Country Key

Tax Procedure

Assigned

Tax Keys

Assigned

Determined

– Base Amount

– Tax Rate

– Posting Key

– Account Determination for Posting

of Taxes on Sales/Purchases

Schematic Illustration of the Customizing for the Tax on Sales/PurchasesFigure4.53

When creating new sales tax codes, there is an additional step you need to

perform. You have to permit the new code for what are called Enjoy trans-

actions. In contrast to older transactions, for example FB01 (General Post-

ing), these transactions—such as FB50 (Enter G/L Account Document) and

FB60 (Enter Invoice)—enable you to enter all specications in one screen.

You register the tax codes using Transaction OBZT (Tax Code Selection

for Transactions), which you can nd in the Implementation Guide, for

example, under

Financial Accounting (New)

•

Accounts Receivable

and Accounts Payable

•

Business Transactions

•

Incoming Invoices/

Credit Memos

•

Incoming Invoices/Credit Memos - Enjoy

•

Dene

Tax Code per Transaction

Here, depending on the country keys (required for determining the tax

procedure) and tax codes, you can dene for which posting procedures a

code is available in the Enjoy transactions. The following posting proce-

dures are available:

(Logistics) invoice verication



Invoice receipt for nancial accounting



Invoice issue for nancial accounting



All transactions



You usually should not use the “all transactions“ selection because this

way, for example, you also provide tax codes for the output tax to users

who want to enter incoming invoices. You must assign the input tax codes

Enjoy transactions

298 Book_TIGHT.indb 156 12/4/09 3:48:19 PM

157

Summary 4.11

both to the invoice verication and to the invoice receipt in Financial

Accounting to allow for the use in Logistics Invoice Verication and within

Accounts Payable.

If you forget this setting, you created the sales tax code but the system can-

not use it in operational business.

Summary4.11

This chapter explained that the purchasing process is characterized by high

integration of inventory management in the MM component with Finan-

cial Accounting and Controlling. You already have to dene many aspects

in a purchase requisition or purchase order that control the remaining

value ow.

If commitments management is enabled, Controlling is already supplied with

information when a purchase requisition or purchase order is created. By

creating a commitment, you can identify potential budget overruns before

the actual value ow—that is, when the goods or invoices are received.

MM account determination is the central element for controlling the

value ow in the purchasing process. It is quite complex but also ensures

high automation in the process ow. If you do not want to congure

account determination manually, you can use the account determination

wizard. This wizard asks the most important questions, which were also

introduced in this context. While the goods receipt usually does not pose

any problems regarding the integration, the invoice receipt covers special

cases. MM account determination is used here as well, for example, to

map exchange rate differences or small price differences. Invoice verica-

tion enables you to set tolerances to block factually incorrect invoices for

payment.

You usually link the goods receipt and the invoice receipt via a GR/IR

account. Its maintenance is critical for correct mapping in the nancial

statement but is often neglected in real life.

However, the invoice receipt ensures the integration with accounts pay-

able accounting by creating an open item on the vendor account that can

be paid later on.

Except for commitments management, MM account determination, and

goods receipts for purchase orders with account assignment, the topic is

driven by accounting rather than cost accounting and the focus will prob-

ably be on invoice verication.

298 Book_TIGHT.indb 157 12/4/09 3:48:19 PM

429

Index

Access sequence, 168, 211

KOF1, 211

PR00, 169

Account assignment, 93

Incorret account assignment, 95

Account assignment category, 72, 95,

212

Account assignment group, 207

Customer, 207

Material, 207

Account assignment manual, 396

Account assignment object

Classic, 260

Custom, 51

Account balance, 346

Account category reference, 110

Assign, 112

Define, 111

Account control

GR/IR account, 147

Account determination, 155

Account determination for real-time

integration, 306, 309

Adjustment account, 331

Configure, 331

MM, 124

Rebuild, 123

SD, 205

Secondary cost element, 306

Account determination procedure, 213

Account determination type, 211

Account group, 183

Account grouping, 114, 118

Accounting, 333

Indicator, 83

International, 321

Accounting principle, 54

Assign, 332

Accounting reconciliation, 341

Account key, 172, 214

Account origination, 161

Accounts

Neutral, 62

Parallel, 55

Accounts Payable, 148

Accounts Receivable, 182

Post bills, 194

Account symbol, 199

Accrual/deferral, 336

Accrual Engine, 338

Acquisition and production costs (APCs),

320

Activation date, 386

Activity price, 231

Maintain, 231

Activity type, 229

Define, 230

Activity Type

Plan, 231

Ad-hoc costing, 244

Adjustment account

Account determination, 331

Use, 330

Adjustment posting

Reverse, 330

After-image delta method, 371

Allocation, 338

Maintain, 340

Allocation structure, 277

Define, 277

APC values posting

Periodic, 323

Application Link Enabling (ALE), 314

Assembly, 225

Assessment, 338

Asset, 96

Capitalized, 96

Asset Accounting

Function, 317

Asset acquisition, 128

Asset history sheet, 325

Asset under construction (AuC), 96, 317

Distribution rule, 318

Settle, 317

298 Book_TIGHT.indb 429 12/4/09 3:50:22 PM

430

Index

Authorization group, 328

Automatic clearing, 143

Automatic release, 141

Availability control, 102, 103

Tolerance, 103

BAdI

ACC_DOCUMENT, 323

FAGL_COFI_ACCIT_MOD, 305

FAGL_COFI_LNITEM_SEL, 304

FAGL_DERIVE_SEGMENT, 164

Balance carryforward, 335

Balance sheet, 346

Balance sheet and P&L statement/

cashow, 346

Balance sheet structure, 372

Create, 348

Bank determination, 150

Base planning object, 251

Base planning object and simulation

costing, 242

Benchmarking, 32

Best practice analysis, 32

BEx Analyzer, 362

BEx Query Designer, 361

BEx Suite, 361

BEx Web Application Designer, 363

Billing document, 161

Bill of material, 225

BOM, 295

BOM explosion, 227

Branch ofce, 185

Budget, 87, 98

Monitoring, 98

Buffering

Deactivate, 135

Business area, 45

Business Area, 301

Business Content, 364, 368

SAP ERP, 364

SAP NetWeaver BW, 367

Business intelligence, 353, 354

Business perspective, 28

Business process categories, 32

Business process reengineering, 32

Business transaction

Periodic, 188

Special, 175

Calculation

Base, 238

Data volume, 384

Determine base, 238

Capitalized asset, 96

Category, 271

Change management, 396

Characteristic, 76

Assign, 78

Create, 77

Derivation rule, 79

Select, 375

Update, 74

Characteristics item, 383

Characteristic value

Derive, 79

Chart of accounts, 63

Additional, 63

Country-specific chart of accounts, 65

Group chart of accounts, 64

Hierarchy, 63

Operating, 64

Clearing

Automatic, 143

Document, 144

Closed loop process, 356

Closing

Early, 58

Closing procedure document, 312

Closing procedure document, 401

Commission, 173

Commitment, 98, 190

Blocks, 100

Calculation, 101

Change, 100

Cost center, 99

Management, 98

298 Book_TIGHT.indb 430 12/4/09 3:50:22 PM

431

Index

Order, 99

Reduce, 101

Update, 98

Company, 45

Company code, 45

Cross-company-code transactions, 310

Global transactions, 48

Parallel, 54

Condition

Assign, 81

Condition exclusion, 171

Procedure, 172

Condition record, 167, 168

Condition table, 210

Condition technique, 210

Condition type, 167

Customizing, 168

PR00, 167

RA01, 170

Consolidation

Preparation, 300, 342

Consumption posting, 117

Contribution margin accounting, 82

Contribution margin scheme, 377

Control

Extended, 268

Controlling

Operative, 349

Controlling approach, 37

Controlling approaches, 37

Controlling area, 47

General, 47

CO-PA, 73

Account-based, 74

Costing-based, 74, 75

Value field, 81

Co-product, 278

Cost accounting, 262

Cost Center Update, 300

Cost component split, 233

Cost component structure, 232

Customizing, 233

Cost element, 59, 60, 82, 230

Category, 61

Category 90, 62

G/L account, 60

Group, 277

Number, 61

Primary, 61

Secondary, 61

Cost element calculation

For each recipient type, 278

Costing, 70

Ad-hoc costing, 244

Base object and simulation costing,

251

Base planning object and simulation

costing, 242

Current, 236

Inventory costing, 235

Modified standard cost estimate, 236

Order BOM cost estimate, 295

Period-end closing, 262

Simultaneous, 261

Without quantity structure, 243

With quantity structure, 243, 244

Costing-based element, 166, 173

Costing procedure, 242

Costing run, 244

Create, 244

Operation, 245

Status development, 247

Costing sheet, 166, 169

Pricing, 167

Costing type, 234

Costing value

Transfer, 294

Costing variant, 231, 252

Cost object, 287

Controlling, 223, 257, 281

Hierarchy, 259

Node, 259

Cost object controlling

Periodic, 258

Cost-of-sales accounting, 46, 346

Cost-of-Sales Accounting, 301

Cost-of-sales accounting ledger, 46

Country-specic chart of accounts, 65

Create

Balance sheet structure, 348

Credit control area, 47

Credit limit calculation, 190

298 Book_TIGHT.indb 431 12/4/09 3:50:22 PM

432

Index

Crystal Reports, 364

Cube

Virtual, 371

Current costing, 236

Current setting, 150

Custom account assignment object, 51

Custom DataSource, 373

Customer account, 183

Company code data, 185

General part, 183

Reconciliation account, 186

Sales data, 183

Customer enhancement, 80

Customer hierarchy access, 80

Customer-specic table, 392

Customer with a credit balance, 333

Customizing, 196

Data acquisition, 356, 357

Data modeling, 357

Data provisioning layer, 357

Data retention, 357

DataSource, 357

Activate, 370

Custom, 373

DataStore object, 357, 359

Data structure, 357

Data transfer, 240

Data volume, 381

Calculate, 384

Data Warehousing Workbench, 367

Date control, 248

Decision

Strategic, 221

Dene

Activity type, 230

Allocation structure, 277

Credit, 239

Distribution cycle, 339

Line identification, 270

Segment, 339

Standard value key, 228

Dene credit, 239

Delivery, 161

Delivery cost provisions (RUE), 122

Delivery costs, 136

Unplanned, 122

delta compatibility, 365

Delta method, 371

Depreciation, 320

Depreciation key, 320

Depreciation posting run, 320

Function, 320

Derivation option, 164

Derivation procedure, 393

Derivation rule, 79

Design level, 35

De-taxation, 175

Deviating document number, 148

Deviating document type, 148

Discount, 170, 171

Distribution, 338

Distribution cycle

Define, 339

Distribution rule (AuC settlement), 318

Document ow, 27

SD, 180

Document/journal entry report, 345

Document number

Deviating, 148

Document number assignment, 134

Document splitting, 59, 60

Document summarization, 305

Document type, 194

Deviating, 148

Down payment, 188

Dummy account assignment, 395

Dunning, 195

Dunning charge, 195

Bill, 196

Dunning interests, 195

Duplicated CO-PA record, 165

Duplicated invoice, 91

Early closing, 58

Earnings Before Interests and Taxes

(EBIT), 61, 182

298 Book_TIGHT.indb 432 12/4/09 3:50:22 PM

433

Index

Easy Cost Planning, 244

Electronic bank statement, 196

Account symbol, 199

External transaction code, 198

Number logic of the bank accounts,

200

Posting rule, 198

Transaction category, 198

Element

Costing-based, 166

price-determining, 170

Price-determining, 166

Engineer-to-order, 224

Controlling approach, 37

Enjoy transaction, 156

Entity model, 43

Exchange rate rounding differences for

Materials Management (KDR), 121

Execution processes, 34

Expenditure/income from consignment

material consumption (AKO), 118

Expenditure/income from transfer

posting (AUM), 119

Explosion type, 240

Extended control, 268

Extractor, 357

General ledger balances, leading

ledger, 369

Fast close, 57

Feeder system, 357

Field control, 127

Final costing, 264

Financial statement, 48

First In - First Out (FIFO), 70

Fiscal year change, 325

Fixed account assignment, 179

Flat-rate value adjustment, 335

Foreign currency valuation, 329

Function, 329

Full settlement (FUL), 286

Functional area, 46

Overwriting, 47

Functional area derivation, 46

General controlling area, 47

General ledger account, 59

G/L account, 59, 60

Goods issue

Valuate, 181

Goods issue posting, 178

Goods receipt, 87, 93, 128

Non-valuated, 128

Valuated, 128

Grace day, 153

GR/IR account, 142

GR/IR clearing (WRX), 122

Gross discount, 171

Gross schema, 175

De-taxation, 175

SAP standard, 175

Group

Cost element, 277

Group chart of accounts, 64

Head ofce, 185

House bank, 150

Human Resources, 312

Implementation level, 36

Income/expenditure from revaluation

(UMB), 122

Incoming payment, 161, 196

Individual value adjustment, 335

InfoCube, 357

InfoObject, 357

InfoProvider, 357

Information

Inherit, 340

Information broadcasting, 364

Information ow, 27

Information message

Adapt, 135

298 Book_TIGHT.indb 433 12/4/09 3:50:22 PM

434

Index

Information system, 353

Integrated value ow, 25

Definition, 25

Integration, 28

Financial Accounting and Controlling,

Information flow and material flow,

In SAP ERP, 41

Interest group, 28

Lack of, 148

Missing, 42

MM and Financial Accounting/

Controlling, 102, 104

SD and Accounts Receivable, 193

Intercompany clearing account, 310

Intercompany reconciliation, 342

Interface, 172

Internal invoicing, 312

International accounting, 321

International Accounting Standards

(IAS), 54

International Financial Reporting

Standards (IFRS), 54

Inventory, 315

Asset Accounting, 324

Continuous, 315

Deferred, 315

Periodic inventory, 315

Procedures subject to permission, 316

Sample-based physical inventory, 315

Inventory costing, 235

Invoice

Cuplicated, 91

Invoice receipt, 87, 94

Invoice verication, 130

GR-based, 132

Logistics, 131

Process, 131

Technical, 131

Invoicing

Internal, 312

Item category, 93, 97, 253

Lack of integration, 148

Last In - First Out (LIFO), 69

Lease Accounting Engine (LAE), 317

LeatherWorks Manufacturing, 20

Ledger

Compare Financial Accounting and

EC-PCA, 344

Cost-of-sales accounting ledger, 46

Parallel, 57

Post to, 56

Special, 54

Update, 300

Legal entity, 45

Level of integration, 221

Life cycle, 241

Limitation

Planned revenues, 294

Line identication, 270

Assign, 271

Define, 270

List of stock values, 343

List screen, 253

Logistical master data, 225

Logistics Invoice Verication, 131

Lowest value principle, 69

Maintain

Allocation, 340

Make-to-order, 224

Make-to-stock, 224

Controlling approach, 37

Management reporting, 350

Manufacturing order, 259

Manufacturing process, 223

Mapping of delivery costs, 120

Masking, 233

Master data

Logistical, 225

Master data concept

Value flow-oriented, 58

Master data report, 345

298 Book_TIGHT.indb 434 12/4/09 3:50:22 PM

435

Index

Master recipe, 229

Material ow, 26

Material group, 92, 95

Material ledger, 224

Material master, 65

View, 66

Material type, 110, 112, 113

New, 113

Mickey Mouse model, 55

Migration date, 385

Migration scope, 386

Migration to the SAP General Ledger, 44

MM account determination, 104, 105

Simulation, 125

Structure, 105

Transaction, 114

MM document, 104

Modied standard cost estimate, 236

Movement indicator, 115

Movement type, 114, 116

Moving average price, 67

Net discount, 171

Net schema, 175, 176

Non-valuated goods receipt, 128

Noted items, 189

Offsetting entry to the stock posting

(GBB), 120

Open item control, 59

Operating chart of accounts, 64

Operating concern, 49, 76

Error message, 79

Operative controlling, 349

Order BOM cost estimate, 295

Order-related cost object controlling,

258

Order status, 290

Order type

Commitment update, 99

Organizational structure, 44, 51

Changing, 51

Organizational unit

Controlling, 50

Financial Accounting, 50

Outgoing payments, 88

Overhead, 262

Overhead application, 262

Overhead cost controlling, 262

Overhead Cost Controlling, 216

Parallel accounting

Classic general ledger, 54

Parallel accounts, 55

Parallel company codes, 54

Parallel ledger

Migration, 57

Parallel ledgers, 56

Parallel rendering of accounts, 53

SAP General Ledger, 56

Partial payment, 203

Partner role, 193

PA transfer structure, 81, 278

Payable, 90

Payer, 193

Payment block

Permanent, 153

Payment difference, 201

Large variance, 203

small difference, 201

Payment method, 91, 150, 196

Payment on account, 203

Payment proposal, 153

Payment run, 149

Percentage rate

Define, 239

Performance management, 37

Period accounting, 346

Period closing program

Settings, 327

Period control, 326

Period-end closing, 285, 289, 297

Periodic APC values posting, 323

298 Book_TIGHT.indb 435 12/4/09 3:50:22 PM

436

Index

Periodic business transaction, 188

Periodic cost object controlling, 258

Periodic settlement (PER), 286

Periodic unit price, 68

Period-related product controlling, 281

Permanent payment block, 153

Perspective

Business, 28

Value-based, 28

Physical inventory prices, 68

Plan

Activity type, 231

Planning, 32

Planning processes, 33

Plant level, 106

Porter‘s value chain model, 30

Posting

Automatic, 268

WIP posting, 268

Posting period, 327

Close, 327

Open, 327

Posting Procedure, 191

Posting rule, 198

Preliminary costing, 283, 289, 294

Price

Update, 106

Price control, 67

Price determination, 166, 209

Price-determining element, 166

Article, 171

Customer, 171

Sales and distribution, 170

Price differences (PRD), 121

Price update, 250

Pricing

Costing sheet, 167

Trigger, 177

Pricing procedure, 236

Primary activity, 30

Primary cost element, 61

Process

Integration, 43

Process category, 161

Process design, 37

Procurement, 32

Procurement process, 85

Product controlling

Period-related, 281

Resource-related, 258

Sales-order-based, 258

Product cost by sales order, 258, 292

Product cost collector, 259, 282

Product cost controlling, 225

Basic setting, 231

Time schedule, 261

Product cost planning, 241

Type, 241

Product Cost Planning

Type, 242

Production, 32

Production cost planning, 222

Production process, 221

Production typology, 260

Protability analysis, 373

Prot and loss statement (P&L

statement), 346

Capitalization, 317

Return, 317

Prot center, 48, 163

Matrix organization, 163

Prot Center Accounting, 380

Prot center assignment

Change, 53

Prot center derivation, 49, 163

Derivation rules, 384

From the material master, 163

Substitution, 164

Prot center/segment link, 50

Prot Center Update, 301

Pro forma invoice, 214

Project

Charter, 379

Dry run, 397

Financial Accounting/Controlling

value flows, 396

Initial situation, 379

Phases, 387

Plan, 385, 387

Preliminary considerations, 380

Redesigning value flows, 391

Review, 397

298 Book_TIGHT.indb 436 12/4/09 3:50:23 PM

437

Index

Scope, 384

Segment, 391

Value flows in sales process, 394

Value flows in the procurement

process, 393

Purchase order, 92, 128

Purchase order history, 129

Purchase order status, 129

Purchase requisition, 92

Purchasing data, 91

Purchasing info record, 94

Quantity eld, 80

Quantity elds, 177

Quantity ow

MM, 180

Quantity update, 112

Query, 359

Real-time integration, 58, 302

Account, 308

Account determination, 306, 309

Variant specification, 304

Real-time integration (RTI), 396

Rebate, 174

Receipt indicator, 117

Receivable, 182

Reclassication, 333

Reconciliation, 341

Accounting, 341

Financial Accounting and inventory

management, 343

Financial Accounting ñ Controlling,

344

Financial Accounting ñ EC-PCA, 344

Financial Accounting ñ FI-AA, 324

Reconciliation account, 89, 186, 333

Changeable, 188, 341

Vendor, 89

Reconciliation ledger, 302

Recurring entry, 148

Reference variant, 240

Release

Automatic, 141

RemoteCube, 372

Replacement value, 70

Report

RGUIST01, 384

Reporting, 345, 349

Reporting and analysis option, 353

Requirement

International, 53

Requirements class, 71, 212

Derivation, 72

Requirements type, 72

Resource, 227

Results analysis, 297

Key, 72, 266

Version, 266

Retained earnings account, 335

Parallel financial reporting, 336

Returns, 33

Revaluate, 256

Revaluation, 256

Revenue, 217

Cost-reducing, 217

Revenue account determination, 206

Account determination procedure, 213

Account determination type, 211

Condition technique, 210

Customer account assignment group,

207

Material account assignment group,

207

Prerequisites, 206

Rebuild, 217

Troubleshooting, 218

Revenue planning, 294

Revenue recognition, 204

Method, 204

Time, 204

Time of service performance, 204

Sales and distribution, 33

298 Book_TIGHT.indb 437 12/4/09 3:50:23 PM

438

Index

Sales document item, 259

Sales order, 162

Profit center account assignment, 181

Sales order controlling, 38, 74

Sales order costing, 294

Sales revenue, 204

SAP BusinessObjects, 364

SAP ERP

Value flow model, 42

SAP General Ledger

Account determination, 331

SAP Management Cockpit, 364

SAP NetWeaver BW, 353

Additional information, 377

SAP Note

69642, 150

77430, 150

81153, 150

213444, 192

SAP system

Components, 43

Historically grown, 42

Organizational element, 44

Structure, 42

Scenario, 300

Scheduling, 240

SCOR model, 31, 86, 160, 223

Business process category, 32

Configuration level, 33

Design level, 35

Extend, 36

First level, 33

Link levels, 34

Production model, 35

second level, 33

Secondary activity, 30

Secondary business, 194

Debit-side, 194

Vendor, 148

Secondary cost element, 61

Segment, 49, 164

Define, 339

Financial statements, 57

Segmentation, 301

Segment derivation, 164

BAdI, 165

Select

Characteristic, 375

Value field, 375

Service, 371

Setting

Current, 150

Settlement, 275, 297

Control, 279

Profile, 72, 276, 318

Rule, 72

Simulation and base planning object,

251

Simulation costing, 251

Simultaneous costing, 261, 284, 289,

295

Single document

Transfer, 58

Small differences in Materials

Management (DIF), 121

Source, 82

Source of supply, 92

Source structure, 278

Special business transaction, 175

Special G/L indicator, 189

Create, 189

Down payment request, 191

Property, 190

Special G/L sales, 190

Special G/L transaction

Integrated with SD, 192

Special G/L transactions, 188

Special ledger, 54

Special stock, 116

Split valuation, 109

Standard account assignment, 119

Standard cost estimate, 235

Standard price, 121

Standard value key

Define, 228

Stock change account, 181

Stock change (BSV), 119

Stock issue

Account determination, 181

Stock posting (BSX), 119

Storage

Final, 255

Temporary, 255

Strategic decision, 221

298 Book_TIGHT.indb 438 12/4/09 3:50:23 PM

439

Index

Structural change, 51

Substitution, 164

Subtotal, 170

Supply chain, 26

Supply Chain Council (SCC), 32

Support processes, 34

Surcharge, 170, 171

Symbolic account, 313

Tab

Additional Log, 153

Basic Data, 228

Control, 282, 287

Cost Accounting, 282

Costing, 66, 228, 229

Costing 1, 163

Costing1, 70

Costing 2, 70

Dates, 244

Details, 136

Financial Accounting, 66

Header, 283

Invoice, 132

Overhead Costs, 236

Parameter, 135

Payment Transactions, 202

Sales General/Plant, 70, 163

Sales sales org. 1, 70

Valuation, 244

Table

ANLC, 324

BKPF, 382

BSEG, 382

Customer-specific, 392

FAGLFLEXA, 382

FAGLFLEXT, 369, 382

T042A, 150

T042D, 150

T156SY, 117

Totals table, 381

Table access, 79

Target costs, 257

Calculate, 257

Target ledger group, 332

Task list, 396

Tax code, 154

Maintain, 154

Tax on sales/purchases, 154

Tax procedure, 154

Terms of payment, 186

Test phase, 388

Tolerance, 138

Tolerance group, 202

Tolerance key, 139

AN, 139

AP, 139

BD, 139

KW, 140

LA, 140

LD, 140

PP, 140

PS, 140

VP, 140

Tolerance limit, 138

Totals table, 381

FAGLFLEXT, 306

Transaction, 114, 118

0KEM, 164

3KEH, 49

ABST2, 324

AJAB, 325

AJRW, 325

AO90, 320

ARAL, 325

ASKB, 323

CK11N, 251

CK24, 251

CK40N, 244

CKMATSEL, 244

Clear, 144

CO01, 282, 287

CO02, 289

CR01, 228

CS01, 225

CS11, 227

Enjoy transaction, 156

F.03, 341

F.07, 336

F.13, 143, 144, 145

F.19, 146

F110, 152

298 Book_TIGHT.indb 439 12/4/09 3:50:23 PM

440

Index

FAGLBW03, 369

FAGLF101, 334

FAGLGVTR, 335

FB01, 156

FB02, 153

FB50, 156

FB60, 156

FTXP, 154

GCAC, 344, 388

KAH1, 82

KALC, 58, 302

KEA0, 78

KEA5, 76

KEA6, 80

KEAT, 344

KEAW, 344

KEND, 51

KI12, 262

KKAX, 272

KKE1, 251

KKEB, 256

KKF6N, 282, 283

KKS2, 275

KOT2_OPA, 99

MB5L, 343

ME21, 68

MF30, 283

MIGO, 115

MIGO_GI, 115

MIGO_GO, 115

MIGO_GR, 115

MIGO_TR, 115

MIRO, 133, 138

MR11, 145

MRBR, 141

OB52, 327

OB58, 348

OBA5, 91

OBZT, 156

OKB9, 119, 137, 179, 203

OKG1, 266

OKG8, 267

OKGB, 271

OKKP, 98

OKO7, 318

OKP1, 328

OME9, 98

OMWB, 125

OMWN, 118

OV25, 210

OVF3, 179

OVZG, 71

RSA1, 367

SA38, 384

SAP standard, 118

SBIW, 365, 374

V/08, 167

VA03, 179

VA44, 297

VF03, 218

VOFA, 194

Transaction category, 198

Transaction code

external, 198

Transaction key, 114

Transfer control, 240

Transfer posting

Manual, 308

Transformation, 358

Turning action into data, 36

Unit costing, 251

United States Generally Accepted

Accounting Principles (US-GAAP, 54

Unplanned delivery costs (UPF), 122

Post, 137

Update material price, 242

Updating

Material price, 242

Valuated goods receipt, 128

Valuation

Split, 109

Valuation area, 107

Group, 107

Valuation class, 66, 109, 123

Assign, 112

298 Book_TIGHT.indb 440 12/4/09 3:50:23 PM

441

Index

Create, 112

Customizing, 110

Valuation grouping code (VGC), 107

Assign, 108

Valuation level, 106, 123

Valuation variant, 236, 248, 273

Valuation view, 236

Value-based perspective, 28

Value creation

Increase, 31

Value eld, 80, 177

Assign, 83

Create, 80

fill, 80

Value ow, 26

Integrated, 25

Order-related product controlling, 291

Period-based product controlling, 285

Sales-order-related product

controlling, 295

Sales process, 162

Start in sales order, 161

Value ow model

In SAP ERP, 42

Value string, 117

Value update, 112

Variance calculation, 273

Variance Calculation, 275

Variance category, 83

Variance key, 273

Variance variant, 274

Vendor consignment stock, 129

Vendor management and vendor

controlling, 38

Vendor master, 89

Accounting view, 89

General part, 89

Vendor secondary business, 148

Vendor selection, 86

Vendor with a debit balance, 333

View, 91

Virtual cube, 371

Wage type, 313

Web browser, 363

Work in process (WIP), 264

Customizing, 272

Posting, 268

Updating, 270

Worklist, 244

Year-end closing, 325

298 Book_TIGHT.indb 441 12/4/09 3:50:23 PM