0% found this document useful (0 votes)
143 views94 pages

Optimizing Value Flows With Sap Erp

Uploaded by

hfgh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
143 views94 pages

Optimizing Value Flows With Sap Erp

Uploaded by

hfgh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 94

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 Verification  ........................................................ 130
4.7.1 Invoice Verification 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 Profit 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 Reclassification 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

10

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

11

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

12

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


Three critical processes run in an enterprise. This chapter analyz-
es the first important process, the purchasing process. You should
not underestimate its significance, because the products you gen-
erate can only be as good as the materials you purchase.

4 Procurement Process

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 flows.
First, it describes how the procurement process is integrated with the
operational performance. In this context, the extended SCOR model plays
a significant 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 flows.
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.

85

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


4    Procurement Process

4.1 Procurement Process in the SCOR Model


SCOR model 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

Stocked Placement Release


Scheduling Goods Quality
of the Payment*
Goods Goods Receipt Receipt Check in Storage
Payment

Sales-Order- Placement Release


Scheduling Goods Quality
Related of the Payment*
Goods Receipt Receipt Check in Storage
Production Payment

Engineer-to- Vendor Placement Release


Goods Quality
Order Selection and in Storage of the Payment*
Production Receipt Check
Scheduling Payment

* Not Part of the Original SCOR Model.

Figure 4.1  Procurement Process in the Adapted SCOR Model

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 sufficient to consider the process complete after the payment
for the invoice has been released. However, because this book focuses on
the value flow, it is supposed to guide you through the complete flow, that
is, up to paying the vendor invoice.
Process types in In addition to this aspect, Figure 4.1 shows that the SCOR model differ-
the SCOR model entiates between three procurement process types, which depend on the
organization of the production:
EE Procurement for make-to-stock production
EE Procurement for sales-order-related production
EE Procurement for projected sales-order-related production

Vendor selection It is apparent that the three process types only differ in the first module.
For make-to-stock production and sales-order-related production, the pur-
chasing department is responsible for scheduling the goods receipt in the

86

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 first 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 modified
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 flows. 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 flow. Reducing budgets
You can take adequate measures in cost accounting only if a purchase req- for purchase orders
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 first event you have to include in the Goods receipt
financial 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 Invoice receipt
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 flow of goods from the value
flow. This also provides additional benefits, which are discussed in detail
in Section 4.8, GR/IR Account. It is not until the vendor invoice is received

87

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


4    Procurement Process

and posted that the open item is created in accounts payable accounting.
Depending on the specific case, you must additionally post currency dif-
ferences or other deviations.
Outgoing The open item is usually cleared within a payment run. From the account-
payments ing perspective, this is the last operation of the value flow in the procure-
ment process.
Creation of values 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.

Ordering Process Goods Receipt Invoice Receipt Outgoing Payment

MM Goods Receipt Doc. Invoice Receipt


– Stock Posting in MM

FI Goods Receipt Doc. Invoice Outgoing Payment


– Stock Posting – Payable – Cash Disbursement
– Stock Change – Tax – Clearing of the
– Expense/Stock Payables

CO CO-OM Document CO-OM Document * CO-OM Document * CO-OM Document *


– Update – Material Costs – Material Costs – Cash Discount
Commitment – Expense
Reduction

* Optional

Figure 4.2  Value Flow of the Procurement Process

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.

88

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


Vendor Master as an Integrative Element    4.2

4.2 Vendor Master as an Integrative Element


To meet the different requirements of the purchasing department and
accounts payable accounting, the SAP system splits up the vendor master
into three parts:
EE General part
EE Accounting view
EE Purchasing data

For every vendor for which the system should map business relationships, General part
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 find the vendor number, the name and address of the
vendor, the corresponding tax information as well as all bank details. The
benefit 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. Accounting view
The example of the reconciliation account clearly illustrates the benefit of
this procedure.
The reconciliation account is the link between accounts payable account- “Reconciliation
ing and general ledger accounting. In general ledger accounting, it maps account” example
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 defined in the vendor master to ensure
integration with the general ledger. In this case, account 160000 is speci-
fied 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.

89

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


4    Procurement Process

Customer: 90100
Reconciliation
Account: 160000

Invoice Receipt: EUR 1,190.00 for Delivery Costs

General Ledger Accounting


160000 PGS 154000 Input Tax 231100 Freights
EUR 1,190.00 EUR 190.00 EUR 1,000.00

Accounts Payable Accounting


Vendor 90100
EUR 1,190.00

Figure 4.3  Posting Techniques for Reconciliation Accounts

Mapping of A typical structuring for the mapping of payables in general ledger account-
payables ing is the following:
EE Payables for goods and services, third-parties, domestic
EE Payables for goods and services, third-parties, foreign
EE Payables for goods and services, affiliated enterprises, domestic
EE Payables for goods and services, affiliated 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 defines account 160000
(domestic vendor payables) in the vendor master, account 161000 (foreign
vendor payables) must be specified 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.

90

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 Payment methods
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 fields such as the ex-
ternal document number, vendor, and amount correspond to the fields 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 define the Check For
Duplicate Invoice indicator as a mandatory field in the Customizing of the
vendor master.

The purchasing data of the vendor stores all information that you require Purchasing data
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 Required views
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.

91

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


4    Procurement Process

4.3 Purchase Order as the Basis of the


Procurement Process
In the context of the ordering process, this section focuses on two docu-
ments: purchase requisition and purchase order.

4.3.1 Purchase Requisition


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 defines a requisitioner. For every item,
it also specifies 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-
fill a purchase requisition with a purchase order or an outline agreement.
Determining the You may have to determine a source of supply before creating a purchase
source of supply 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.

4.3.2 Purchase Order


Header data of the Like many other documents in the SAP system, a purchase order consists
purchase order 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-

92

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:
EE Ordering address, invoice address, and delivery address
EE Terms of payment
EE Incoterms (terms of freight)

More interesting than the header information are the purchase order items. Purchase order
Their behavior—as well as the required information for each item—is con- item—item
category
trolled by what is called an item category. The type and attributes of the
item category determine critical definitions (see Figure 4.4).

Figure 4.4 Item Category Definitions

First of all, you have to define whether the corresponding purchase order Account
item allows for, enforces, or prohibits specifying a material number or assignment
additional account assignments (see Material Required field group in
Figure 4.4). For materials, you can additionally select whether inven-
tory management is possible (Inventory Management field group). This
defines 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 definitions for the goods receipt. You Goods receipt
can define 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 field group). For example, for

93

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


4    Procurement Process

vendor consignments, if the goods receipt is non-valuated, the invoiced


value of goods is directly indicated as an expense (and not as stock) in the
financial statement.
Invoice receipt The item category also states whether an invoice is expected and whether
this invoice is binding. You can also determine whether this setting can be
changed in the purchase order (Control:invoice receipt field group).
You cannot configure item categories; that is, you cannot create new or
modify existing categories. The only option you have is to assign an exter-
nal item category (a category that is visible to the user) to the internal item
category of the SAP system. Table 4.1 contains a list of the most important
item categories.

Item Description Usage


Category
Int. Ext.

0 Standard EE Externally procured goods


purchase order EE GR and IR possible
1 B Limit purchase EE Definition of a max. value
order EE Neither quantity nor delivery data is
defined
EE IR is mandatory
2 K Consignment EE Material required
order EE Procurement based on consignment
EE GR is mandatory
3 L Subcontracting EE Ordering finished products at ven-
dors
EE Non-valuated GR is mandatory
4 S Third-party EE Purchase order triggered by enter-
prise, delivery to customer
EE No GR, but IR mandatory
7 U Stock transfer EE Initiating a stock transfer from plant
to plant

Table 4.1  Item Categories with Descriptions

Purchase order A purchaser must also specify the agreed price of the purchase order item.
item—purchasing This process can be automated using purchasing info records. These records
info record

94

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


Purchase Order as the Basis of the Procurement Process    4.3

link vendors and materials, and its critical elements are the purchase order
and price conditions. A purchasing info record always refers to only one
vendor and one material. This enables you to maintain different purchase
prices for a material for each vendor. The purchasing info record is addi-
tionally characterized by its high level of integration within the SAP sys-
tem. You can also use it for product cost controlling, for example.
Because material numbers are not always available, the material group is Material group
very useful and serves various purposes in materials management. In the
basic view, a material group is assigned to a material master; the material
group serves to combine materials with similar properties. In reporting,
you can then carry out evaluations according to these material groups.
For the integrated value flow, however, the fact that you do not have to
enter a material master in the purchase order if you specify a material
group in the purchase order item is much more interesting. This option is
useful for low-value consumption goods (such as coffee for the employee
break room) for which no material master exists.
When the purchaser creates a purchase order without material, he must
generally decide to which expense account the purchase order item should
be assigned. Using material groups is the solution because they can be
linked to MM account determination, which allows for automated assign-
ment of G/L accounts. This means that the purchaser does not have to
determine the account manually, a process that often leads to posting
errors.

Risk of Incorrect Account Assignments with Manual Input


If the system does not automatically determine the G/L account, the risk of
an incorrect account assignment increases considerably! The reason is that
you cannot reduce the G/L accounts the system lists for selection.

Purchase orders with a material master record in the purchase order items Purchase order
that are not delivered to stock but directly provided for consumption are with account
assignment
referred to as purchase orders with account assignment. Here, an account
assignment category that requires the specification of a respective account
assignment for the item is assigned to a purchase order item.
The following are the most important account assignment categories in a Account
purchase order: assignment
categories
EE Internal order
EE Cost center

95

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


4    Procurement Process

EE Project
EE Asset
EE Production order
EE Sales order
EE Customer individual stock

The account assignment categories for internal orders, cost centers, proj-
ects, production orders, sales orders, and sales order stock are not unique;
they require the specification of the respective account assignment object.
This object must exist and be valid when the purchase order is entered.
Here, the common rules for the use of Controlling account assignments
apply. This means that you can define only one genuine account assign-
ment object.
Asset account To assign an account to an asset, you need a main asset number and an
assignment asset subnumber. This is the problem with this category: The asset number
category
must be available even before the asset is available. There are two solutions
to this problem:
EE Access via a dummy asset
EE The purchaser/creator of the purchase requisition creates the asset

Access via When using the access via a dummy asset, you usually work with an
“asset under asset under construction (AuC) with line item settlement to which all asset
construction“
acquisitions are assigned. Using an AuC has the advantage that line items
posted to this asset can be settled individually to a capitalized asset or to
an expense account.
Access via Alternatively, you can also directly use a capitalized asset for account assign-
capitalized assets ment. For new acquisitions, this also means that the purchasing depart-
ment is allowed to create capitalized assets. However, when creating a
capitalized asset, you must make decisions regarding the mapping in the
financial statement, for example, on the asset class and consequently on
the account assignment and on depreciation parameters. If you decide to
use this account assignment variant for assets, you should ensure that your
employees are able to create the assets properly, for example, by providing
training and the corresponding documentation.
You can also have the purchasing department request a new asset number
from the asset accounting department in these cases. The asset account-
ing department would then have the corresponding competence to make
a decision about the correct assignment of the asset, create a number, and

96

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


Purchase Order as the Basis of the Procurement Process 4.3

forward the number to the purchasing department. However, this vari-


ant may require time-consuming internal communication, which can be
a problem.
When using purchase requisitions, you should create the asset when creat-
ing the purchase requisition and not when issuing the purchase order. This
way, you reach the highest level of integration. This also means that the
creator of the purchase requisition must already possess the know-how to
create the asset properly.
Because these two solutions for the account assignment of assets can lead Prohibiting the
to specific problems, you can consider prohibiting this account assignment item category
category as a third solution.
Technically, you can easily implement this constraint by simply not pro-
viding this category. This is possible because Customizing defines for each
order type which account assignment categories are allowed and which are
not allowed. You can find this setting in the Implementation Guide under
Materials Management • Purchasing • Purchase Order • Define Doc-
ument Types. If you want to use this variant, post the invoice receipt to a
clearing account. Then, the asset accounting department must make man-
ual transfer postings for the values from the clearing account to an asset.
In addition to the decision of which account assignments can or must Further definitions
be transferred, you can make further decisions under Define Document in the account
assignment
Types. Figure 4.5 shows an example.
category

Figure 4.5 Account Assignment Category Definitions

97

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


4    Procurement Process

Here, you can see the Customizing for the Asset account assignment cat-
egory to which you can also navigate via Transaction OME9 (Change
Account Assignment Category).
As for the item category, here, you also define whether and what type of
goods and invoice receipt is required for the account assignment category.
Sections 4.6, Goods Receipt, and Section 4.7, Invoice Verification, describe
the corresponding effects of these definitions in more detail. Goods receipt
and invoice receipt are the first events in the procurement process that
affect Financial Accounting.
Budget monitoring From the cost accounting perspective, however, it would be negligent to
start monitoring the budget only when the invoice has been received. If
you determine at this stage that a budget has been exceeded, it is too late
to take action. Ideally, you therefore start monitoring the budget when
you create the purchase requisition or, at the latest, when you create the
purchase order. As you could already see in Figure 4.2, the Controlling
document for the commitment update is the only document that is already
generated when the purchase requisition and purchase order are created.

4.4 Updating Commitments


Commitment The SAP system provides a Commitments Management function. A com-
mitment is understood as a scheduled (purchase requisition) or contrac-
tual (purchase order) commitment that will result in costs. Costs can be
incurred in the form of goods or invoice receipt. This means commitments
are prebooked sales that you can check against approved budgets.
Activating Although you can also integrate commitment updates with the general led-
Commitments ger, asset accounting, and funds management, Commitments Management
Management
in Controlling is frequently used. You activate this function at the control-
ling area level (see Figure 4.6).
You can navigate to the Controlling area maintenance using Transaction
OKKP. The activation of the Commitments Management component
enables you to manage commitments for cost centers and internal orders.
You can also initiate that commitments are updated to sales orders in Trans-
action OKKP by selecting the W. Commit. Mgt (With Commitment Man-
agement) checkbox in the Sales Orders section. These options indicate
that commitments can only be updated for purchase orders with account
assignment.

98

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


Updating Commitments 4.4

Figure 4.6 Commitments Management Activation

In addition, you have to configure commitment updates for order types


and cost center categories.
For internal orders, you can enable these updates by selecting the W. Com- Commitment
mit. Mgt checkbox in the individual order types. To do so, you can use update for order
types
Transaction KOT2_OPA. When the checkbox is selected, this definition
immediately applies to all orders of this order type that exist in the system.
This is also indicated in the master record of the order in the Control
data field group. Figure 4.7 displays an example.

Figure 4.7 Order Master for Enabled Commitments Management

The logic for cost centers is different. Here, the Commitment block indica- Commitment
tor is set for all cost center categories for which no commitment update is update for cost
centers
desired. Commitments are updated for all cost center categories for which
this indicator is not set. Figure 4.8 displays the specifications for the two

99

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


4 Procurement Process

cost center categories 4 (Administration) and 5 (Management). For cost


center category 4, commitments should be updated; for category 5, they
should not be updated.

Figure 4.8 Blocking Commitment Updates for Cost Center Categories

You can implement the commitment update settings for the cost center
categories in the Implementation Guide under Controlling • Cost Cen-
ter Accounting • Master Data • Cost Centers • Define Cost Center
Categories.
However, because these settings for the cost center categories are only
default values for the creation of master data, you can also individually
modify Commitments Management in the respective cost center master
when creating a new cost center (see Figure 4.9).

No Effect on Existing Cost Centers


Keep in mind that changes to the Customizing of the cost center category do
not affect existing cost centers. Therefore, the SAP system behavior for cost
centers differs from the behavior for internal orders.

Figure 4.9 Changing the Commitment Update Settings in the Cost Center Master

100

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


Updating Commitments 4.4

You can reduce commitments in two alternative ways: Reducing


commitments
EE Reduction based on values of the goods receipt
EE Reduction based on values of the invoice receipt

Here, the system behavior depends on whether a valuated goods receipt


exists. If the goods receipt is valuated, the corresponding goods receipt
data is used. and prices are taken from the purchase order.
If there is no goods receipt or if it is non-valuated, the commitment is
reduced upon invoice receipt.

Defining a G/L Account as the Cost Element


To generate commitments, the G/L account to which the purchase order is
assigned must be defined as the cost type when the goods or invoices are
received.

Let’s take a look at a budgeted order of Lederwaren-Manufaktur Man- “Commitment


nheim and the ordering and budget reduction process. A budget of calculation”
example
EUR 1,200,000.00 was assigned to marketing order 400237. A purchase
requisition and—based on this—a purchase order with an amount of
EUR 5,850.00 were created. Figure 4.10 illustrates the flow and the previ-
ous use of the budget.

Figure 4.10 Budget Evaluation for Marketing Order 400237

You can see that an expense of EUR 1,200,000.00 is planned from which
EUR 1,194,150.00 are available. At the time the query was issued, the
Actual column reads EUR 1,170.00. Where does this value come from?
To answer this question, you have to take a look at the development of
the purchase order.

101

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


4 Procurement Process

Figure 4.11 Development of Purchase Order 4500018746

In Figure 4.11, you can see that two pieces were posted as goods receipt.
According to the purchase order with EUR 585.00/piece, a total of
EUR 1,170.00 1 was valuated.
However, three pieces at EUR 585.00 were invoiced; that is, the invoice
was EUR 1,755.00 in total 2. Therefore, in this case, the goods receipt
values were used for the budget usage. Because the purchase order is
EUR 5,850.00 3 in total, but goods of only EUR 1,170.00 were received,
a commitment of EUR 4,680.00 4 still exists.

Figure 4.12 Total Value of Purchase Order 4500018746

The budget evaluation (see Figure 4.10) includes the total value in the
Assigned column. You can also determine it using the Actual and Com-
mitment columns.
“Commitments This example illustrates that Commitments Management is a simple but
Management” tool powerful tool that enables you to implement cost accounting even before
the costs actually incur. Generating the commitment with the purchase
requisition allows for an early interaction from the cost accounting side—
for example, by blocking the purchase order or increasing the budget.
The topic of reducing a commitment goes beyond the scope of mere bud-
geting. Only an accounting-relevant document—that is, the valuated goods
receipt or invoice receipt—allows for a reduction of the commitment.
Section 4.5, Integration of MM and Financial Accounting/Controlling,
describes how the system generates accounting documents.
Availability control However, mapping the budget and commitment flow is only one side of
the story. At least as important is the system behavior in the event of a

102

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


Updating Commitments 4.4

budget overrun or what is called availability control. The bad news is that
the standard SAP system can prohibit postings because of budget overruns
for internal orders or projects only. It does not allow for triggering an error
message for account assignments to a cost center.

Availability Control for Account Assignments to Cost Centers


SAP Note 68366 (Active Availability Control for Cost Centers) provides a so-
lution using a substitution.

You can influence the behavior for budget overruns for internal orders and
projects using Customizing. You can find the settings for internal orders in
the Implementation Guide under Controlling • Internal Orders • Bud-
geting and Availability Control. Here, you first create a budget profile
and then assign it to the order types. Additionally, you determine whether
availability control is implemented in the case of an account assignment to
a budgeted internal order. You can also define tolerances here.

Figure 4.13 Availability Control Tolerances

Figure 4.13 shows an example of a three-level check. This is controlled


via the specification of the budget usage in percentages (Usage in % ) and
absolute amounts for the variance (Absolute variance ) if necessary. The
Action column enables you to control the system behavior. In our exam-
ple, the following control is implemented:
EE Action 1
When you reach 80 percent of the budget, the system generates a warn-
ing message for the goods/invoice receipt.
EE Action 2
At 90 percent, the system generates another warning and additionally
sends an email to the person responsible.
EE Action 3
In the event of a budget overrun, the system generates an error mes-
sage. You can no longer post a document with account assignment to
the budget (for example, via an internal order).

103

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


4    Procurement Process

4.5 Integration of MM and Financial


Accounting/Controlling
Document flow Figure 4.2 illustrated which documents are generated during the procure-
ment process. In this context, you learned that value flow-relevant proce-
dures always result in multiple documents:
EE Material document
EE Financial Accounting document
EE Controlling document (optional)

For the goods receipt, it is easy to understand why a document needs to be


generated in MM. The MM document posts the receipt and the accounting
documents map the corresponding values. The purpose of the MM docu-
ment for the logistics invoice verification is not clear at first glance. Keep
in mind that the logistics invoice verification in SAP has more tasks than
simply posting the payables and implementing the respective offsetting
account assignment.
The invoice verification is characterized by a high integration with MM.
The system can compare the invoice of the purchase order with the goods
receipt and can consequently automatically answer the question of whether
the existing invoice seems to be justified and correct. For this purpose, how-
ever, it requires detailed information from the purchase order and the goods
receipt if necessary. Technically, this information is solely available in MM.
Content of the All stock-relevant processes are therefore first mapped by a material docu-
MM document ment in the inventory management (MM component). Here, the informa-
tion flow is generated along the material flow, as you already know from
Chapter 2, Section 2.1.1, Value Flow. The material document contains all
of the pieces of information you need for proper inventory management
and detailed evaluations of goods movement:
EE Material number
EE Storage data such as storage location or stock type
EE Movement type

MM account This information serves as the basis for the structure of the documents in
determination Financial Accounting and Controlling that represent the value flow. The
interface from MM to Financial Accounting/Controlling is characterized
by a high degree of automation, which can be achieved thanks to what is
called MM account determination. The MM account determination can be

104

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


Integration of MM and Financial Accounting/Controlling    4.5

considered complex rules for the derivation of account assignments. It is


restricted, however, to the determination of G/L accounts and does not
affect Controlling account assignments such as cost centers or orders.
The prospect of newly implementing MM account determination makes
most consultants moan. First, you have to configure account determina-
tion yourself; then, you have to explain the logic of account determination
to the user departments, which are general ledger accounting and cost
accounting in this case. The latter is usually quite time-consuming and
might require strong nerves. If you look at the steps of MM account deter-
mination separately, however, you can see that it is not rocket science. It
is complex, but has a logical structure. We will therefore begin with an
overview and then go into details.
As the name implies, the goal of MM account determination is to deter- General structure
mine a G/L account in Financial Accounting. As you can see in Figure 4.14,
you can categorize the numerous relationships into three groups.

Basic Settings: Valuation Class:


– Valuation Grouping Code – Material Type
– Valuation Level – Account Category Reference
– Valuation Area – Valuation Class

Transaction:
– Movement Type
– Valuation Rule G/L Account
– Account Grouping
– Transaction

Figure 4.14  Overview of the Settings for MM Account Determination

The basic settings define the valuation class and the transaction, which in
turn define the G/L account. The following sections discuss the individual
groups in detail.

4.5.1 Basic Settings


Let us start with the basic settings, which enable you to influence the MM Valuation level
account determination behavior as a whole. Here, the central question is at

105

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


4 Procurement Process

which level you want to influence the account determination and thus the
mapping of goods movements in the financial statement. You can choose
between plant and company code. The rather simple setting and selection,
which are illustrated in Figure 4.15, have far reaching effects.
The valuation level defines whether the account determination is identical
for all plants of a company code or whether you can set the account deter-
mination for each plant individually. After the going-live of the client using
standard means, you can no longer change the decision you made. Because
this setting applies centrally, you can also find it in the Implementation
Guide under Enterprise Structure • Definition • Logistics – General •
Define Valuation Level.

Figure 4.15 Defining the Valuation Level

Not Reversible and Client-Wide


The valuation level setting is irreversible and applies across all clients.

Plant level You should always select the plant level, even if no deviating account deter-
recommendation mination is planned for individual plants at the time of the specification.
You have to set the plant as the valuation level if you want to use the PP
(Production Planning) component or Product Cost Planning in Controlling.
This selection consequently allows for a multitude of options.
Updating the price In addition to controlling the account determination, the valuation level
has further effects. It defines if the accounting view in the material mas-
ter is maintained per plant or per company code. This is also the level at
which the valuated price of a material is updated. The term accounting view
is therefore misleading.
Valuation area Accordingly, you usually define the plant as the valuation level. Although
multiple plants are defined in your company code, you may still want to
specify an account determination at the company code level. One of the
reasons for this could be that you want to maintain the account determina-
tion specifically for each country, which is a rather common procedure in

106

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


Integration of MM and Financial Accounting/Controlling    4.5

international enterprises. To map this, the SAP system provides the valua-
tion area classification criterion.
The valuation area corresponds to the individual attributes of the selected
valuation level. At the “plant” valuation level, each plant corresponds to
a valuation area. If you want to work with the “company code” valuation
level, the system proposes the company code that exists in the client as
the valuation area.
To avoid that you have to assign different account determination to each Valuation grouping
valuation area, you need to group the valuation areas. For this, you must code
enable the use of the valuation grouping code (VGC). You can do this in the
Implementation Guide under Materials Management • Valuation and
Account Assignment • Account Determination • Account Determi-
nation Without Wizard • Define Valuation Control.

Missing Connection to the Automatic Transport System


At this point, note that the activation of the VGC, along with the definition
of the valuation area, is stored in the TCURM table. This table is not con-
nected to the automatic transport system. Consequently, you enable the VGC
directly in the target system. If the target or live SAP system is still initial, for
example, in the event of a new system implementation, you can manually
bundle the settings in a transport.
For this purpose, you need to include the following entries in the transport
request:
EE Program ID R3TR
EE Object type TABU
EE Object name TCURM
EE Specify the client as the key.

This missing connection to the transport system is a security measure of


the SAP system to avoid that this setting will be overwritten.
You can implement groupings via the Materials Management • Valua- Grouping of the
tion and Account Assignment • Account Determination • Account valuation areas
Determination Without Wizard • Group Together Valuation Areas
Customizing path. Figure 4.16 shows a corresponding example.
The first column, Valuation Area (see Figure 4.16) indicates the valuation
areas. In this example, these are the plants that exist in the client because
here, plants serve as the valuation area (see Figure 4.15). The next two
columns, Company Code and Company Name, display the ID and the
name of the company code to which the respective plant is assigned. SAP

107

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


4 Procurement Process

uses the company code to determine the operating chart of accounts that
is valid for the account determination for goods movements. Accordingly,
the account determination is specific to the charts of accounts.

Figure 4.16 Grouping of the Valuation Areas

Assigning the VGC In the last column, Valuation Grouping Code (see Figure 4.16), you can
view the valuation grouping code. Here, the entries can be freely selected.
You should use clear logic, for example, the country code at the first two
places and then ascending numbers.
As our example illustrates, Lederwaren-Manufaktur Mannheim has created
specific plants for logistics processing in Belgium, France, and Italy. Each
plant of Lederwaren-Manufaktur Mannheim you can see in Figure 4.16 is
located in another country. Because you work with country-specific VGCs,
each plant has its own VGC: plant M100 in Belgium uses BE01, M200 in
France uses FR01, M300 in Italy uses IT01. The two plants that are located
in Poland, PL01 and PL02, of the 0006 and 0005 company codes both use
the PL01 VGC and are thus treated identically in the MM account deter-
mination. The figure is therefore an example of how you should define the
VGC: The numbering consists of a country code and a counter.
You will then implement all account determination settings at the VGC
level only. The settings will apply to all assigned valuation areas.

VGC Assignment
You should only assign company codes with the same chart of accounts
to a common VGC to avoid unnecessary complexity for the account
determination.

At first, it does not seem to be useful to work with VGCs for, for example,
SAP implementations with a single plant/company code. However, for
future-oriented project approaches and if the enterprise might continue
to grow, you should work with VGCs right from the start. This does not
involve much additional effort but considerably facilitates expansion.

108

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


Integration of MM and Financial Accounting/Controlling    4.5

You are now familiar with the basic settings for MM account determina-
tion, which are summarized in Figure 4.17. This schematic illustration
shows that the basic settings are complex only at first glance.

Valuation Grouping
Code

Grouped

Determined
Valuation Level Valuation Area

Figure 4.17  Schematic Illustration of Basic MM Account Determination Settings

For the sake of completeness, the option of split valuation should also be Split valuation
mentioned. This enables you to further divide the valuation areas for a
material. A common criterion for the division of prices and account deter-
mination for a material and its stock is the batch. Batches of a material can
have different prices and can be mapped in different ways in the financial
statement. This is the case, for example, if the product quality at the end
of a production process cannot be absolutely defined and the batches can-
not be compared or exchanged. Because this is a topic that is critical in
individual industries but not relevant to the majority of enterprises that
use SAP, it is not further discussed here.
Instead, we will take a step forward in the MM account determination and
turn to the categorization of materials. Because not all materials should be
managed in one material stock account in the financial statement, a distin-
guishing criterion is required for the account determination. SAP provides
the valuation class for this purpose.

4.5.2 Valuation Class Settings


From the MM account determination view, you can consider the valuation Valuation class
class a grouping of materials. It is defined in the accounting view of every
material that is managed on a value basis. Materials with the same valua-
tion class are subject to the same account determination. When designing
the account determination, you can define a separate valuation class for

109

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


4      Procurement Process

each material stock account you want to map in the financial statement.
Usually, the following materials are mapped separately:
EE Raw materials
EE Semi-finished products
EE Finished products
EE Trading goods
EE Operating supplies

In addition, you may want to evaluate certain materials or goods—especially


valuable raw materials or goods with high price fluctuations—separately.
Customizing enables you to define which valuation classes are provided
for selection in the maintenance of a material. This way, you can reduce
the risk of incorrect entries in the material master.
Account category For this purpose, you can group the valuation classes into what are called
reference account category references. For example, if you use multiple valuation
classes to map raw materials, you can combine them in the “raw materials”
account category reference. When you then create a new material master
for a raw material, you can select from all of the valuation classes for raw
materials. Every valuation class is assigned to exactly one account category
reference; that is, it is an n:1 relationship.
Assignment to the The account category references, in turn, are assigned to the material types.
material type Every material type is assigned exactly one account category reference; that
is, it is a 1:n relationship. If you use account category references, not all of
the materials of one material type have to use the same account determina-
tion. Moreover, materials of different material types can be subject to the
same account determination.
Figure 4.18 again illustrates the relationships between material type,
account category reference, and evaluation class.
Valuation class SAP combined the entire Customizing of the valuation class in one Cus-
Customizing tomizing item. You can find it in the Implementation Guide under Mate-
rials Management • Valuation and Account Assignment • Account
Determination • Account Determination Without Wizard • Define
Valuation Classes. From there, you can navigate to the three necessary
operations: the editing of Account Category Reference, Valuation
Class, and Material Type. Figure 4.19 shows the initial screen.

110

ch04_5571.indd 110 12/7/09 12:22:41 PM


Integration of MM and Financial Accounting/Controlling 4.5

Assigned
Account Category
Material Type
Reference

Grouped

Valuation Class

Figure 4.18 Schematic Illustration of the Valuation Class Determination

Figure 4.19 Customizing of the Valuation Classes

Using the Account Category Reference/Valuation Class view, first


define the Account Category References, that is, the link between valu-
ation classes and material type (see Figure 4.20).

Figure 4.20 Definition of the Account Category References

111

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


4 Procurement Process

Then, you can create the Valuation Classes and immediately assign them
to an account category reference. This is illustrated in Figure 4.21.

Figure 4.21 Creating and Assigning Valuation Classes

In the third and last step, you assign the account category references to the
Material Types (see Figure 4.22).

Figure 4.22 Assigning the Account Category Reference to the Material Type

Material type For the inventory management of the materials in the SAP system, the
material type assumes a major role. Chapter 3, Section 3.4.3, Material
Master, already discussed some material master settings that are essential
for the value flow. The material type was not mentioned there, because it
does not directly affect the value flow. But as you know now, the material
type is a critical MM account determination element.
Customizing of the You can find the material type Customizing in the Implementation Guide
material type under Logistics – General • Material Master • Basic Settings • Mate-
rial Types • Define Attributes of Material Types.
Quantity update The material type also defines whether quantities and/or values are updated
and value update for the materials that are assigned to the material type. You can generally
activate or deactivate quantity and value updates or even make this deci-
sion at the valuation area level. There are certainly reasons for controlling

112

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


Integration of MM and Financial Accounting/Controlling 4.5

the quantity and value updates of the material types in the individual valu-
ation areas in different ways. In real life, however, this is an exception.
Figure 4.23 displays the corresponding settings for the MFER material type
(LWM – finished products), which you can find in the Implementation
Guide under Logistics – General • Material Master • Basic Settings •
Material Types • Define Attributes of Material Types.

Figure 4.23 Quantity/Value Updates of the Material Type

As you can see in Figure 4.23, our material type does not clearly define
whether quantities or values are updated. It depends on the settings in the
individual valuation areas, which are shown in Figure 4.24.
This figure also indicates that a decision about the quantity and value
update at the valuation area level actually means that the materials in the
individual plants/company codes behave differently. Based on our exam-
ple, this means that quantities and values are updated for MFER in all valu-
ation areas, except for valuation area QMTR.

Figure 4.24 Quantity/Value Updates for Every Valuation Area

MM account determination is only relevant for materials that are subject New material
to value updates. However, you should trust in the SAP standard and only types
create new material types by copying a standard material type and chang-
ing it according to your requirements.
Usually, the MM component administrators/consultants design and imple-
ment the material types. Afterward, the material types should be assigned

113

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


4    Procurement Process

to the account category references by the persons who are responsible for
the MM account determination.
Regarding the account category references, this section introduced the
standard-related solution. In this context, the system only provides a part
of the valuation classes (namely, the account category reference) when you
create a material.
Alternative Alternatively, you can also assign all valuation classes to one account cat-
assignment egory reference. As a result, the material maintenance then provides all
classes of the client for the valuation class selection. One of the benefits
of this method is that you can decide for each material how it should be
mapped in the financial statement. The disadvantage is that a wrong valua-
tion class may be selected due to the large number of options. If the wrong
valuation class is selected, all movements of this material will be mapped
incorrectly in accounting and cost accounting.
You now know that the definition of valuation classes is no problem at
all. All that remains is the last subject area: determining transactions and
modifying accounts. Unfortunately, this subject area is also the area with
the highest complexity within MM account determination.

4.5.3 Determining Transactions


Because the MM account determination reflects the goods movements in
inventory management, the properties of each movement play an essential
role in account determination: Is it merely an internal transaction or perhaps
a delivery to a customer? Is the enterprise the owner or is it vendor stock?
Transactions and The most apparent element that can provide important information is
account groupings the movement type. Because the standard version already contains numer-
ous movement types, it would be very time-consuming to directly link
the movement types to G/L accounts. You also have to consider additional
influencing factors such as the stock type (e.g., special stock) and quantity
or value updates of the material. Consequently, SAP developed comprehen-
sive rules according to which you can specify and classify goods movements
for the account determination. In the end, the account determination is
configured based on what are called transactions and account groupings.
Figure 4.25 illustrates how the SAP system determines these two objects.
The following sections describe in detail how this determination is
implemented.

114

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


Integration of MM and Financial Accounting/Controlling    4.5

Transaction Code Movement Indicator


Movement Type
Consumption Posting Ind.
Special Stock Indicator
GR w/o � [BLANK]
Material
Acct. Assgmt.
GR with � Acct. Assgmt.
Acct. Assgmt. Cat. from PO
Material Type GI � Acct. Assgmt.
Value Update Value String Cat. or Delivery
Quantity Update
Receipt Indicator
[BLANK] � Normal Receipt
X � Stock Transport
Order
L � Borrowed
Empties

Transaction Key

Account Grouping

Figure 4.25  Determining the Transaction Key and Account Grouping

To record goods movement in materials management, the SAP system pro- Movement
vides a wide range of special transactions. Within the SAP system, these indicator
transactions are linked to what are called movement indicators. The fol-
lowing attributes are available for movement indicators:
EE B goods movement for purchase order
EE F goods movement for order
EE L goods movement for delivery note
EE O subsequent adjustment of stock of material provided/material
provided

The link between transaction and movement indicator is established in


table T158 (Inventory Management Transaction Control). Table 4.2 shows
six transactions for posting goods movements.
The names of the transaction codes already imply whether the system
can determine which transaction is posted. For Transactions MIGO and
MIGO_GR, the SAP system assumes that a goods movement is recorded for
a purchase order. MIGO_GO is a goods movement for an order. Transac-
tions MIGO_GI and MIGO_TR do not indicate what kind of movement is
posted. Consequently, no movement indicator is defined for these transac-
tions. Although this indicator affects MM account determination, you will
rarely come across it.

115

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


4    Procurement Process

Transaction Description Value


Assignment
Indicator
MIGO Goods Movement B
MIGO_GI Other Goods Movement
MIGO_GO Goods Movement for Order F
MIGO_GR Goods Movement for Purchase Order B
MIGO_GS Subsequent Adjustment of Material O
Provided
MIGO_TR Other Transfer Posting

Table 4.2  Link Between Transaction and Movement Indicator

Movement type This is different for the movement type, which is another important
account determination element. Its primary task is the presentation of the
material flows 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 specification of the movement.
To perform this task, you have to implement various definitions for each
movement type. You define individually which transactions provide the
movement type and which fields can or have to be populated. The move-
ment type also specifies 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.
Special stock When entering a goods movement, you also define whether the transac-
indicator 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 financial statement.

116

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


Integration of MM and Financial Accounting/Controlling 4.5

Another indicator you usually cannot influence is the consumption post- Consumption
ing indicator. The system sometimes sets this indicator automatically and posting
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:
EE A asset
EE V consumption
EE E settlement through sales order
EE U unknown
EE P settlement for project

Finally, there is the receipt indicator, which is used for MM account deter- Receipt indicator
mination. It specifies the type of the goods receipt or of the stock transfer
but can only adopt one of the following three values:
EE [BLANK] normal receipt
EE X stock transport order
EE L borrowed empties

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


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 defines
how you have to transfer a material document to Financial Accounting/
Controlling. This context can be best understood at the table level.

Figure 4.26 Excerpt of Table T156SY


(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

117

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


4    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 first 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.
Transaction and Account grouping enables you, for example, to further break down the
account grouping “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.
Creating custom You can also define your own account groupings. This is useful if your
account groupings reporting requirements are specific. A common example can be that you
are unsatisfied 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.
Transactions in the The standard SAP system already provides numerous transactions. The
SAP standard 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:
EE 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.

118

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


Integration of MM and Financial Accounting/Controlling    4.5

EE 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.
EE 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 define the assigned
account as a cost element, you have to define standard account assign-
ments, for example, using Transaction OKB9.

Defining 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 fixed
cost center or order:
EE You can enter the Controlling account assignment in the cost element mas-
ter record itself.
EE You can use Transaction OKB9, which enables you to define a fixed cost
center, order, business area, or profit 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.

EE Stock posting (BSX)


Transaction BSX addresses the material stock accounts in the financial
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
verification.
The specifications 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.

119

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


4    Procurement Process

EE 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:
EE Freight clearing (FR1)
EE Provisions for freight charges (FR2)
EE Customs clearing (FR3)
EE Provisions for customs clearing (FR4)
EE 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 sufficient 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 Usage
Grouping
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

Table 4.3  Account Groupings for Transaction GBB

120

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


Integration of MM and Financial Accounting/Controlling    4.5

Account Usage
Grouping
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.)

EE 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 defined in the purchase order. Transaction KBS therefore only
serves to specify the posting keys for the goods receipt posting.
EE 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.
EE Small differences in Materials Management (DIF)
Transaction DIF is used in invoice verification when you define a toler-
ance limit for small differences and the balance of the invoice does not
exceed the tolerance.
EE 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:
EE Goods receipts for purchase orders if the purchase order price differs
from the standard price
EE Goods issues if an external amount is entered
EE 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 insufficient 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.

121

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


4    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 Usage
Grouping
[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

Table 4.4  Account Groupings for Transaction PRD

EE 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.
EE Income/expenditure from revaluation (UMB)
Transaction UMB is used both in inventory management and in invoice
verification 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.
EE 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 specified 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.
EE 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.

122

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


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.

4.5.4 Rebuild Process for Account Determination


If you want to rebuild account determination in a result-oriented way, you
should perform the following steps:
1. Define the a company code or plant as the valuation level.
2. Create a valuation grouping code and link it to the valuation areas.
3. Define and assign valuation classes.
4. Define G/L accounts and check whether cost elements are created for
the relevant transactions.
5. Correct reported errors for the goods movements.

The first step, defining the valuation level, involves an easy decision: If Defining the
you use PP or want to calculate products in Controlling, you must use the valuation level
plant as the valuation level.
The valuation classes are also usually not a problem. The critical question Defining the
is: Which material stock accounts does the accounting department want valuation class
to map in the financial 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 specific materials separately, for example, because
high stock values are expected for these materials or because extreme price
fluctuations 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 define a G/L account for the most important trans- Defining G/L
actions. Which transactions are critical depends on the business activities accounts for
critical transactions
of your enterprise. In a first step, you could maintain the following trans-
actions and account groupings, for example:
EE Transaction BSX
EE Transaction GBB
With the AUA/AUF, VAX/VAY, and VBR account groupings

123

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


4    Procurement Process

EE Transaction DIF
EE Transaction PRD
EE 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: Configure 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 financial
statement may arise in this context.

Tabular mapping of Experience has shown that tables are best suited for the mapping of the MM
the MM account account determination. Among other things, the horizontal axis shows the
determination
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 define 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.

Transaction Movement Transaction/ VGC Valuation Classes


Types Account Raw Semi Finish Pack.
Grp.
Goods receipt 101, 102, … BSX 0001 39000 39100 39200 39300
Inventory 701, 702 GBB INV 0001 35000 35000 35020 35010
difference
Inventory 701, 702, … GBB INV 0002 35040 35020 35020 35010
difference

Table 4.5  Structure of a Microsoft Excel Table for the MM Account Determination
(Excerpt)

124

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


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- MM account
ment type. For these situations, SAP provides an MM account determina- determination
simulation
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).

Figure 4.27 Simulation of the MM Account Determination—Selection

In Figure 4.27, 101 is specified for the Movement Type in the selection
field. The system displays or updates the list below this field, which shows
the different goods receipts, when you confirm 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).

125

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


4 Procurement Process

Figure 4.28 Simulation of the MM Account Determination—Evaluation

The top field groups in Figure 4.28 show that the following information
has been derived from the plant:
EE Company code and thus chart of accounts.
EE Valuation area and thus valuation grouping code.
EE The valuation class is determined from the material.
EE 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.

126

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


Integration of MM and Financial Accounting/Controlling 4.5

The Check Screen Layout button (see Figure 4.28) enables you to navigate Comparing the
to additional useful functions, namely, the comparison of the field groups field control
of movement type and G/L account. Both elements—movement type and
G/L account—individually define which fields are ready for input or even
which fields are mandatory entry fields. 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 field 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 field is hidden. A circle stands for an optional entry. Mandatory fields
are illustrated by a plus.

Figure 4.29 Comparing the Field Controls of Movement Type and G/L Account

You only need these two functions—simulation and field 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 flow

127

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


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

4.6 Goods Receipt


Are goods receipts The decision whether goods receipts are necessary is already made in the
necessary? 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 first 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.
Valuated/ More complicated is the decision about whether the goods receipt should
non-valuated be valuated or non-valuated. If you define in the purchase order that the
goods receipt
goods receipt should be non-valuated, the valuation does not take place
until the invoice is received.
“Asset acquisition” 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 defines when the asset is posted for the
first 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.

128

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


Goods Receipt 4.6

Figure 4.30 Purchase Order Status—Valuated GR for an Asset

The fact that both a quantity and an amount are specified 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).

Figure 4.31 Purchase Order History 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 field in the asset master in Figure 4.32.
From the value flow perspective, the goods receipt does not include fur- Stock material
ther special aspects. For materials that are managed on a quantity and receipt
value basis, the stock is built-up at this point and thus the stock value in
the financial statement increases.
The stock value may not be increased if you are not the owner of the goods. Vendor
An example of this is the vendor consignment stock. In this case, only an consignment stock
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.

129

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


4 Procurement Process

Figure 4.32 Capitalization Date in the Asset Master

4.7 Invoice Verification


Formal invoice The term invoice verification can refer to different processes: to the techni-
verification cal verification and to the formal verification 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 specifications, for
example, to pass the invoice verification:
E Name and address of the providing enterprise and of the debiting party
E Tax number of the providing enterprise
E Unique sequential invoice number
E Issue date of the invoice (invoice date)
E Quantity and standard description of the delivery or type and scope of
the service provided
E Net amount for the delivery or service
E Tax rate and amount (if the delivery or service is tax-exempt, this needs
to be specified explicitly)

130

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


Invoice Verification    4.7

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


such as discounts
EE 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 sufficient 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 justified but
whether it meets all legal requirements.
In addition to the formal verification, incoming invoices also need to be Factual invoice
factually verified. In this context, you should primarily clarify whether the verification
invoice amount is correct and whether the vendor has correctly provided
or delivered the agreed service or goods.
SAP systems cannot support formal invoice verification. Instead, software System support
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 verification to countries with low wage levels.
For factual invoice verifications, however, the SAP system provides a very Logistics Invoice
good tool: Logistics Invoice Verification. It is characterized by a high inte- Verification
gration with MM and Financial Accounting/Controlling. Posting invoices
with Logistics Invoice Verification should be a standard process and is
therefore discussed in detail in this section.

Invoice Verification 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 Verification. However, you can,
of course, also post credit memos.

4.7.1 Invoice Verification Process


Whether the system expects an invoice is defined by the account assign-
ment category in the purchase order—as is the case for the goods receipt. If
you define 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 defined in the purchase order.

131

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


4 Procurement Process

GR-based invoice Another critical specification for invoice verification is made in the pur-
verification chase order. You define against what the invoice is checked: the purchase
order or the goods receipt (GR). You make this decision via the GR-Based
Invoice Verification checkbox. You can find this checkbox in the detail
view of the purchase order item on the Invoice tab (see Figure 4.33).

Figure 4.33 Invoice Receipt Specifications in the Purchase Order

“Invoice receipt Let us take a closer look at the consequences of this decision using two
specifications” examples:
example
EE The invoice is received before the goods are received.
EE 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 first purchase order, the indicator for the GR-based invoice
verification is not selected; in the second purchase order, the indicator is
selected.
IR before GR 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 Verification


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

Figure 4.34 Message if the Invoice is Received Before the


Goods are Received—Without GR-Based Invoice Verification

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.

132

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


Invoice Verification 4.7

Purchase Order with GR-Based Invoice Verification


The system behaves differently with GR-based invoice verification. 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).

Figure 4.35 Message for GR-Based Invoice Verification and Invoice Receipt
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 first consequence of the GR-Based
Invoice Verification 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 office—you should avoid
using GR-based invoice verification. 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 GR with partial
then the invoice is posted. Because real life is not always as ideal as we delivery before IR
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 verification—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).

Figure 4.36 Item Proposal in the Invoice Receipt for Partial Delivery

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

133

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


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

Figure 4.37 Purchase Order Status for Partial Delivery and Complete Invoice Receipt

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 verification. Only the case where the invoice is received
before the goods receipt is posted is handled more restrictively for GR-
based invoice verification.
Customizing of the You were already introduced to the Logistics Invoice Verification settings
Logistics Invoice that are implemented by the purchasing department in the purchase order.
Verification
These settings include the definition 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 verification itself provides. You can find all cor-
responding settings in the Implementation Guide under Materials Man-
agement • Logistics Invoice Verification.
Document number The fact that Logistics Invoice Verification also creates both an MM doc-
assignment ument and a Financial Accounting document often leads to discontent
among invoice verification 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:
EE The MM document number is also used as the Financial Accounting
document number.
EE 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.

134

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


Invoice Verification 4.7

In the early Logistics Invoice Verification years, only the first variant was Buffering
available. You had to provide external number assignment for the Financial deactivation
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 modifi-
cation of the system, which should usually be avoided, because modifications
entail additional work in the event of release changes.
In this case, however, the modification is not critical and therefore also justi-
fiable from the point of view of the IT.

In the meantime, SAP has developed an easier solution, which you can Adapting the
completely implement in the standard SAP system. For this purpose, you information
message
only have to expand the parameters in the user master. Users can maintain
their master using the System • User Profile • Own Data menu path (see
Figure 4.38).

Figure 4.38 Changing the User Profile for Logistics Invoice Verification

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

Figure 4.39 Display with MM and Financial Accounting Document Number

With this information, you considerably facilitate the work of invoice veri-
fication clerks without having to implement modifications.

135

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


4 Procurement Process

Material Document Number in a Reference Field


The standard SAP system writes the number of the material document to the
Reference Key field 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 field 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 • Define Additional
Fields for Line Item Display.

We will now proceed with the Logistics Invoice Verification posting


technologies.
Unplanned Logistics Invoice Verification uses MM account determination. Section
delivery costs 4.5.3, Determining Transactions, already described that there is a specific
transaction key for unplanned delivery costs and that there are two posting
options. You can make the following decisions:
EE Whether you divide the additional costs between the purchase order
items
EE Whether you want to post a special G/L account line

For materials with moving average price, the first 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 specification at the company code level. You
implement the corresponding setting in the Implementation Guide under
Materials Management • Logistics Invoice Verification • Incom-
ing Invoice • Configure How Unplanned Delivery Costs Are Posted.
Unplanned delivery costs are a special invoice verification 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).

Figure 4.40 Posting Unplanned Delivery Costs

You have to post unplanned delivery costs on the Details tab. The follow-
ing sections describe two posting examples.

136

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


Invoice Verification 4.7

Posting Unplanned Delivery Costs with Distribution


Figure 4.41 displays the Financial Accounting document of an invoice
receipt.

Figure 4.41 Distribution of Unplanned Delivery Costs

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 1 and 2 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).

Figure 4.42 Special Posting of Unplanned Delivery Costs

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, define a standard account
assignment, for example, via Transaction OKB9.

137

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


4    Procurement Process

Posting without In real life, you will often come across invoices that do not refer to a pur-
purchase order chase order. In these cases, you can post the invoice without integration
reference
with MM, which is discussed in Section 4.9.1, Invoice Receipt Without
MM Integration. Or you can use Logistics Invoice Verification. For this
purpose, however, you have to enable this kind of posting first. You can
find the corresponding Customizing in the Implementation Guide under
Materials Management • Logistics Invoice Verification • 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.

4.7.2 Considering Tolerances


Acceptable The procurement process can include numerous variances. Some of them
variances can be tolerated such as differences of a few cents in an invoice due to the
summation of all invoice items.
Individual Other variances are not acceptable such as an obvious price difference
tolerance limits between purchase order and invoice. To set a limit for variances you are
willing to accept, you have to define tolerance limits in Customizing.
Depending on your individual situation, you can maintain various toler-
ances. The standard SAP system provides the following tolerances:
EE AN amount for item without purchase order reference
EE AP amount for item with purchase order reference
EE BD form small differences automatically
EE BR percentage OPUn variance (IR before GR)
EE BW percentage OPUn variance (GR before IR)
EE DQ exceed amount: quantity variance
EE DW quantity variance when GR quantity = zero
EE KW variance from condition value
EE LA amount of blanket purchase order
EE LD blanket purchase order time limit exceeded
EE PP price variance
EE PS price variance: estimated price
EE ST date variance (value * days)
EE VP moving average price variance

138

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


Invoice Verification    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 define
an upper and a lower limit for the variance; additionally, the variance is
defined in absolute amounts and in percentages.
The definition of upper and lower limits enables you, for example, to pre- Definition of upper
vent vendors from considerably exceeding or going below the price that and lower limits
has been agreed in the purchase order. By setting an absolute tolerance in
amounts and additionally a tolerance in percentages, you avoid that you
define unwanted high tolerance limits.

Specifying Tolerance Limits in Absolute Amounts and in Percentages


If you define the percentage for the price overrun at five 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 defining 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 first 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 Verification •
Invoice Block • Set Tolerance Limits. Figure 4.43 displays the definition
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 AN and AP
checked, however, you do not have to use them all. For example, the AN tolerance keys
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- The BD
tially does not balance to zero. This can happen especially if the taxes for tolerance key
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.

139

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


4 Procurement Process

Figure 4.43 Tolerance Limits for Price Variances

PP, KW, and PS Figure 4.43 displayed the PP tolerance keys for basic price variances. How-
tolerance keys ever, there is also a specific 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 fixed 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 verification department.
Thus, you should think twice before setting higher tolerance limits.

LA and LD Finally, SAP also supports you in verifying blanket purchase orders by
tolerance keys enabling you to define tolerances for the amount (LA key) and schedule
fulfillment (LD key).
The VP The VP tolerance key is also quite interesting. It compares the moving
tolerance key average price before the invoice receipt with the moving average price

140

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


Invoice Verification    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- Outside of
tem indicates the reason for the variance in the document and blocks the tolerances
open vendor item for invoice. The system also supports you in releasing
blocked invoices as you will see next.

4.7.3 Automatically Releasing Blocked Invoices


To automatically release blocked invoices, you use Transaction MRBR Automatic release
(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 workflow. If the purchasing department adapts the purchase order af-
ter having clarified the price issue, the invoice can be released for payment.

Regardless of the elimination of the invoice blocking reason, you can also Manual release
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.

141

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


4    Procurement Process

4.8 GR/IR Account


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.

4.8.1 Posting to the GR/IR Account


The WRX To allow for high automation, GR/IR accounts are also defined in the MM
transaction 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.
Purpose of the From the accounting perspective, the GR/IR account is a balance sheet
GR IR account account that is not mapped in the financial 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 to 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: first 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

(2) EUR 2,000.00 (1) EUR 2,000.00

191100 GR/IR

(2) EUR 2,000.00 (1) EUR 2,000.00

Figure 4.44  Posting Example—GR/IR Account

142

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


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 find the goods receipt (10 m2) of
EUR 2,000.00 and the invoice receipt (10 m2) of EUR 2,000.00.
As agreed, the vendor delivered 10 m2 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.

4.8.2 Clearing the GR/IR Account


For clearing, use the function for automatic clearing of G/L accounts in Automatic clearing
Financial Accounting. You can find this function in the user menu under
Accounting • Financial Accounting • General Ledger • Periodic Pro-
cessing • Automatic Clearing • Without Specification of Clearing
Currency (or directly via Transaction F.13). In this case, the system tries
to clear open items on the account according to defined rules. You define
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
fields of the open items have to match so that the items can be grouped.
Figure 4.45 displays the default settings.

Figure 4.45 Default Settings—Automatic Clearing

The definitions 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) fields must match. In our small sample
enterprise, the check whether these three fields match is sufficient. In real

143

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


4 Procurement Process

life, however, you should additionally define 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.
Clearing Let us have another look at the example from Section 4.7.1, Invoice Verifi-
transaction 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 fields (according to the Customizing shown in Figure 4.45) so that
the system identifies that they belong together. Because the group balances
to zero, the system clears the open items (see Figure 4.46).

Figure 4.46 Clearing the GR/IR Account Using Automatic Clearing

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

Figure 4.47 Clearing Document from the GR/IR Account Maintenance

144

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


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- Transaction F.13
ple: You can consider implementing tolerance limits and reduce the criteria
for the grouping of documents on the GR/IR account.
EE 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.
EE 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 verification, 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 GR/IR Account
invoice receipts—for example, if no goods or invoice receipts are expected Maintenance with
MR11
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 find this transaction in the user menu
under Logistics • Materials Management • Logistics Invoice Veri-
fication • GR/IR Account Maintenance • Maintain GR/IR Clearing
Account.
You can start the program automatically or manually. In automatic opera- Automatic or
tion, the system can write off open items for which the delivery quantity manual start
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 configure a specific account Posting
determination. The system works with the settings that are also used for configurations

145

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


4    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-
figurations are likely:
EE Purchase orders with account assignment
The offsetting entry is posted to the account assignment that is defined
in the purchase order.
EE Material with standard price
The offsetting entry is posted to the price difference account.
EE 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.

Mapping in the It has already been mentioned that the GR/IR account is not mapped in
financial statement the financial statement. However, to ensure that the financial statement is
using F.19
correct, all values on the GR/IR account that exist at the time the financial
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:
EE An account that maps invoice receipts for which no goods have been
received
EE 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 find
the corresponding settings in the Implementation Guide under Financial
Accounting (New) • General Ledger Accounting (New) • Periodic
Processing • Reclassify • Define Adjustment Accounts for GR/IR
Clearing. Figure 4.48 shows an example.

146

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


Integration of Accounts Payable Accounting 4.9

Figure 4.48 Account Determination for the Reclassification of the GR/IR Account

Here, you can see Transaction BNG (Invoiced but not yet delivered).
For our 191100 GR/IR account, the 191199 adjustment account has been
defined 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 financial statement. It should be mapped in the
financial 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 finan-
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.

4.9 Integration of Accounts Payable Accounting


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

147

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


4    Procurement Process

object is the vendor master. In addition to the entry of incoming invoices


via Logistics Invoice Verification, which was described in Section 4.7.1,
Invoice Verification Process, you can also directly enter invoices and credit
memos in Accounts Payable.

4.9.1 Invoice Receipt Without MM Integration


Lack of integration 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 flower pot that is paid from the department’s kitty. These
transactions are often called secondary businesses.
Deviating These kinds of documents are usually not posted with the RE document
document type type, but—if you use the standard SAP system—with the KR document
and number
type for invoices and the KG document type for credit memos. Unlike
the document types from Logistics Invoice Verification, these document
types do not use the same number range. This—as well as the necessity of
an additional input screen and the missing verification against a purchase
order or goods receipt—is often the reason why invoice verification clerks
do not fully accept this screen variant. You can address this by providing
an option in Logistics Invoice Verification for postings to G/L accounts.
This enables invoice verification 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 Verification in Section 4.7,
Invoice Verification.
Recurring entries 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 define 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 figures. You can
consider it a template for the actual postings. At regular intervals, usually

148

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


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:
EE Reduction of the work involved in accounting because you do not have
to re-enter documents every time they recur
EE 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 fiscal 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 fiscal year or a variable has been defined. As a result,
the system verifies the fiscal year of the original document, but not the fiscal
year of the documents that are supposed to be posted. The simple solution is
to not enter a fiscal 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.

4.9.2 Outgoing Payments


The payment run is an accounting tool that enables you to trigger all exist- Functional scope
ing payments automatically. In many enterprises, the majority of payments of the payment run
refer to due vendor invoices. However, you can also pay credit memos to
customers or fulfill 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).

149

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


4    Procurement Process

Customizing of the Information from the Information from the Parameters of the
Payment Program Vendor Master Single Document Current Payment Run

Behavior of the Payment Run:


– What Will Be Paid?
– Which Media are Used for Payment?

Figure 4.49  Influencing Factors of a Payment Run

Customizing of the You can find the Customizing of the payment program in the Implementation
payment program 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
define the valid payment methods. For each payment method, you specify a
minimum and a maximum amount, for example. Additionally, you define
whether payments in foreign currencies or to foreign banks are allowed and,
if required, which forms have to be printed. Furthermore, you define 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.
Bank Because enterprises today typically have more than one bank account and
determination often at different banks, bank determination needs to be configured. Here,
depending on the payment methods and currencies, you can define 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 defining 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).

Information from You have two options for selecting the payment method that should be
the vendor master used for an individual open item: by definition in the company code-spe-
and single
cific data of the vendor master or directly in single documents. Normally,
document
the payment method is defined in the vendor master. You should select
the option of assigning the payment method at the document level only

150

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


Integration of Accounts Payable Accounting 4.9

if you want to use a specific payment method for individual documents.


If a payment method is specified twice, the more specific definition wins;
that is, the single document. You can always define more than one pay-
ment method in the Payment Methods field. If there are several entries,
the priority of the entries decreases from the left to the right—that is, the
first entry from the left usually wins.
Figure 4.50 shows an example. Here, three entries are maintained in the
Payment Methods field: 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 first. 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 office. 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 define a partner bank type, the system always uses
the first bank in the vendor master.

Figure 4.50 Payment Methods in the Vendor Master

151

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


4 Procurement Process

Payment run The payment run also allows you to set parameters you can use to con-
parameters figure 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 defined in the payment run.

Figure 4.51 Definition of the Parameters in the Payment Run

Figure 4.51 shows an example of the parameter definition in a payment


run. Here, you can find the posting date that is used for the accounting
documents. You use the Documents entered up to and Customer items
due by fields to define 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 defines 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 field, 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).

152

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


Integration of Accounts Payable Accounting    4.9

Payment Run Next Posting Behavior


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

Table 4.6  Due Date and Payment

However, you can also set grace days for yourself in Customizing. For Grace days
example, if you define 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- Payment proposal
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 specific 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

153

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


4    Procurement Process

send a payment medium file 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 flow, 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.

4.10 Mapping the Tax on Sales/Purchases


Tasks of the In the SAP system, the tax code is the central object for mapping tax on
tax code sales/purchases. It defines 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.
Attributes of a tax You can find the settings for the tax on sales/purchases centrally in the
procedure 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-specific pricing procedures, called tax procedures,
which meet country-specific basic taxation conditions. However, you should
always check the settings for any new SAP system implementation.
Scope of tax You need to assign a tax procedure to every country in which you perform
procedures 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.
Maintaining You maintain the tax codes using Transaction FTXP. The system indirectly
tax codes 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).

154

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


Mapping the Tax on Sales/Purchases 4.10

Figure 4.52 Maintaining the VN Tax Code

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 defined at the tax code level. This means Account
that you only have to specify the tax code in the posting process. The sys- determination
tem can then assume the determination and posting processes. Both in
the procurement process and in the sales and distribution process, this
provides for significant 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
defines 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 modifiable. When
you create individual codes, the direct maintenance is usually less time-con-
suming in the target system.

155

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


4    Procurement Process

Country Key

Assigned

Tax Procedure

Assigned
– Base Amount
Determined – Tax Rate
Tax Keys – Posting Key
– Account Determination for Posting
of Taxes on Sales/Purchases

Figure 4.53  Schematic Illustration of the Customizing for the Tax on Sales/Purchases

Enjoy transactions 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 specifications in one screen.
You register the tax codes using Transaction OBZT (Tax Code Selection
for Transactions), which you can find 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 • Define
Tax Code per Transaction.
Here, depending on the country keys (required for determining the tax
procedure) and tax codes, you can define for which posting procedures a
code is available in the Enjoy transactions. The following posting proce-
dures are available:
EE (Logistics) invoice verification
EE Invoice receipt for financial accounting
EE Invoice issue for financial accounting
EE 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

156

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


Summary    4.11

both to the invoice verification and to the invoice receipt in Financial


Accounting to allow for the use in Logistics Invoice Verification 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.

4.11 Summary
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 define many aspects
in a purchase requisition or purchase order that control the remaining
value flow.
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 flow—that is, when the goods or invoices are received.
MM account determination is the central element for controlling the
value flow in the purchasing process. It is quite complex but also ensures
high automation in the process flow. If you do not want to configure
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 verifica-
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 financial
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 verification.

157

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


Index

A Accounts
Neutral, 62
Access sequence, 168, 211 Parallel, 55
KOF1, 211 Accounts Payable, 148
PR00, 169 Accounts Receivable, 182
Account assignment, 93 Post bills, 194
Incorret account assignment, 95 Account symbol, 199
Account assignment category, 72, 95, Accrual/deferral, 336
212 Accrual Engine, 338
Account assignment group, 207 Acquisition and production costs (APCs),
Customer, 207 320
Material, 207 Activation date, 386
Account assignment manual, 396 Activity price, 231
Account assignment object Maintain, 231
Classic, 260 Activity type, 229
Custom, 51 Define, 230
Account balance, 346 Activity Type
Account category reference, 110 Plan, 231
Assign, 112 Ad-hoc costing, 244
Define, 111 Adjustment account
Account control Account determination, 331
GR/IR account, 147 Use, 330
Account determination, 155 Adjustment posting
Account determination for real-time Reverse, 330
integration, 306, 309 After-image delta method, 371
Adjustment account, 331 Allocation, 338
Configure, 331 Maintain, 340
MM, 124 Allocation structure, 277
Rebuild, 123 Define, 277
SD, 205 APC values posting
Secondary cost element, 306 Periodic, 323
Account determination procedure, 213 Application Link Enabling (ALE), 314
Account determination type, 211 Assembly, 225
Account group, 183 Assessment, 338
Account grouping, 114, 118 Asset, 96
Accounting, 333 Capitalized, 96
Indicator, 83 Asset Accounting
International, 321 Function, 317
Accounting principle, 54 Asset acquisition, 128
Assign, 332 Asset history sheet, 325
Accounting reconciliation, 341 Asset under construction (AuC), 96, 317
Account key, 172, 214 Distribution rule, 318
Account origination, 161 Settle, 317

429

298 Book_TIGHT.indb 429 12/4/09 3:50:22 PM


Index

Authorization group, 328 Business process categories, 32


Automatic clearing, 143 Business process reengineering, 32
Automatic release, 141 Business transaction
Availability control, 102, 103 Periodic, 188
Tolerance, 103 Special, 175

B C
BAdI Calculation
ACC_DOCUMENT, 323 Base, 238
FAGL_COFI_ACCIT_MOD, 305 Data volume, 384
FAGL_COFI_LNITEM_SEL, 304 Determine base, 238
FAGL_DERIVE_SEGMENT, 164 Capitalized asset, 96
Balance carryforward, 335 Category, 271
Balance sheet, 346 Change management, 396
Balance sheet and P&L statement/ Characteristic, 76
cashflow, 346 Assign, 78
Balance sheet structure, 372 Create, 77
Create, 348 Derivation rule, 79
Bank determination, 150 Select, 375
Base planning object, 251 Update, 74
Base planning object and simulation Characteristics item, 383
costing, 242 Characteristic value
Benchmarking, 32 Derive, 79
Best practice analysis, 32 Chart of accounts, 63
BEx Analyzer, 362 Additional, 63
BEx Query Designer, 361 Country-specific chart of accounts, 65
BEx Suite, 361 Group chart of accounts, 64
BEx Web Application Designer, 363 Hierarchy, 63
Billing document, 161 Operating, 64
Bill of material, 225 Clearing
BOM, 295 Automatic, 143
BOM explosion, 227 Document, 144
Branch office, 185 Closed loop process, 356
Budget, 87, 98 Closing
Monitoring, 98 Early, 58
Buffering Closing procedure document, 312
Deactivate, 135 Closing procedure document, 401
Business area, 45 Commission, 173
Business Area, 301 Commitment, 98, 190
Business Content, 364, 368 Blocks, 100
SAP ERP, 364 Calculation, 101
SAP NetWeaver BW, 367 Change, 100
Business intelligence, 353, 354 Cost center, 99
Business perspective, 28 Management, 98

430

298 Book_TIGHT.indb 430 12/4/09 3:50:22 PM


Index

Order, 99 Group, 277


Reduce, 101 Number, 61
Update, 98 Primary, 61
Company, 45 Secondary, 61
Company code, 45 Cost element calculation
Cross-company-code transactions, 310 For each recipient type, 278
Global transactions, 48 Costing, 70
Parallel, 54 Ad-hoc costing, 244
Condition Base object and simulation costing,
Assign, 81 251
Condition exclusion, 171 Base planning object and simulation
Procedure, 172 costing, 242
Condition record, 167, 168 Current, 236
Condition table, 210 Inventory costing, 235
Condition technique, 210 Modified standard cost estimate, 236
Condition type, 167 Order BOM cost estimate, 295
Customizing, 168 Period-end closing, 262
PR00, 167 Simultaneous, 261
RA01, 170 Without quantity structure, 243
Consolidation With quantity structure, 243, 244
Preparation, 300, 342 Costing-based element, 166, 173
Consumption posting, 117 Costing procedure, 242
Contribution margin accounting, 82 Costing run, 244
Contribution margin scheme, 377 Create, 244
Control Operation, 245
Extended, 268 Status development, 247
Controlling Costing sheet, 166, 169
Operative, 349 Pricing, 167
Controlling approach, 37 Costing type, 234
Controlling approaches, 37 Costing value
Controlling area, 47 Transfer, 294
General, 47 Costing variant, 231, 252
CO-PA, 73 Cost object, 287
Account-based, 74 Controlling, 223, 257, 281
Costing-based, 74, 75 Hierarchy, 259
Value field, 81 Node, 259
Co-product, 278 Cost object controlling
Cost accounting, 262 Periodic, 258
Cost Center Update, 300 Cost-of-sales accounting, 46, 346
Cost component split, 233 Cost-of-Sales Accounting, 301
Cost component structure, 232 Cost-of-sales accounting ledger, 46
Customizing, 233 Country-specific chart of accounts, 65
Cost element, 59, 60, 82, 230 Create
Category, 61 Balance sheet structure, 348
Category 90, 62 Credit control area, 47
G/L account, 60 Credit limit calculation, 190

431

298 Book_TIGHT.indb 431 12/4/09 3:50:22 PM


Index

Crystal Reports, 364 Delivery cost provisions (RUE), 122


Cube Delivery costs, 136
Virtual, 371 Unplanned, 122
Current costing, 236 delta compatibility, 365
Current setting, 150 Delta method, 371
Custom account assignment object, 51 Depreciation, 320
Custom DataSource, 373 Depreciation key, 320
Customer account, 183 Depreciation posting run, 320
Company code data, 185 Function, 320
General part, 183 Derivation option, 164
Reconciliation account, 186 Derivation procedure, 393
Sales data, 183 Derivation rule, 79
Customer enhancement, 80 Design level, 35
Customer hierarchy access, 80 De-taxation, 175
Customer-specific table, 392 Deviating document number, 148
Customer with a credit balance, 333 Deviating document type, 148
Customizing, 196 Discount, 170, 171
Distribution, 338
Distribution cycle
D Define, 339
Distribution rule (AuC settlement), 318
Data acquisition, 356, 357 Document flow, 27
Data modeling, 357 SD, 180
Data provisioning layer, 357 Document/journal entry report, 345
Data retention, 357 Document number
DataSource, 357 Deviating, 148
Activate, 370 Document number assignment, 134
Custom, 373 Document splitting, 59, 60
DataStore object, 357, 359 Document summarization, 305
Data structure, 357 Document type, 194
Data transfer, 240 Deviating, 148
Data volume, 381 Down payment, 188
Calculate, 384 Dummy account assignment, 395
Data Warehousing Workbench, 367 Dunning, 195
Date control, 248 Dunning charge, 195
Decision Bill, 196
Strategic, 221 Dunning interests, 195
Define Duplicated CO-PA record, 165
Activity type, 230 Duplicated invoice, 91
Allocation structure, 277
Credit, 239
Distribution cycle, 339 E
Line identification, 270
Segment, 339 Early closing, 58
Standard value key, 228 Earnings Before Interests and Taxes
Define credit, 239 (EBIT), 61, 182
Delivery, 161

432

298 Book_TIGHT.indb 432 12/4/09 3:50:22 PM


Index

Easy Cost Planning, 244 G


Electronic bank statement, 196
Account symbol, 199 General controlling area, 47
External transaction code, 198 General ledger account, 59
Number logic of the bank accounts, G/L account, 59, 60
200 Goods issue
Posting rule, 198 Valuate, 181
Transaction category, 198 Goods issue posting, 178
Element Goods receipt, 87, 93, 128
Costing-based, 166 Non-valuated, 128
price-determining, 170 Valuated, 128
Price-determining, 166 Grace day, 153
Engineer-to-order, 224 GR/IR account, 142
Controlling approach, 37 GR/IR clearing (WRX), 122
Enjoy transaction, 156 Gross discount, 171
Entity model, 43 Gross schema, 175
Exchange rate rounding differences for De-taxation, 175
Materials Management (KDR), 121 SAP standard, 175
Execution processes, 34 Group
Expenditure/income from consignment Cost element, 277
material consumption (AKO), 118 Group chart of accounts, 64
Expenditure/income from transfer
posting (AUM), 119
Explosion type, 240
H
Extended control, 268
Extractor, 357 Head office, 185
General ledger balances, leading House bank, 150
ledger, 369 Human Resources, 312

F I
Fast close, 57 Implementation level, 36
Feeder system, 357 Income/expenditure from revaluation
Field control, 127 (UMB), 122
Final costing, 264 Incoming payment, 161, 196
Financial statement, 48 Individual value adjustment, 335
First In - First Out (FIFO), 70 InfoCube, 357
Fiscal year change, 325 InfoObject, 357
Fixed account assignment, 179 InfoProvider, 357
Flat-rate value adjustment, 335 Information
Foreign currency valuation, 329 Inherit, 340
Function, 329 Information broadcasting, 364
Full settlement (FUL), 286 Information flow, 27
Functional area, 46 Information message
Overwriting, 47 Adapt, 135
Functional area derivation, 46

433

298 Book_TIGHT.indb 433 12/4/09 3:50:22 PM


Index

Information system, 353 L


Integrated value flow, 25
Definition, 25 Lack of integration, 148
Integration, 28 Last In - First Out (LIFO), 69
Financial Accounting and Controlling, Lease Accounting Engine (LAE), 317
42 LeatherWorks Manufacturing, 20
Information flow and material flow, Ledger
27 Compare Financial Accounting and
In SAP ERP, 41 EC-PCA, 344
Interest group, 28 Cost-of-sales accounting ledger, 46
Lack of, 148 Parallel, 57
Missing, 42 Post to, 56
MM and Financial Accounting/ Special, 54
Controlling, 102, 104 Update, 300
SD and Accounts Receivable, 193 Legal entity, 45
Intercompany clearing account, 310 Level of integration, 221
Intercompany reconciliation, 342 Life cycle, 241
Interface, 172 Limitation
Internal invoicing, 312 Planned revenues, 294
International accounting, 321 Line identification, 270
International Accounting Standards Assign, 271
(IAS), 54 Define, 270
International Financial Reporting List of stock values, 343
Standards (IFRS), 54 List screen, 253
Inventory, 315 Logistical master data, 225
Asset Accounting, 324 Logistics Invoice Verification, 131
Continuous, 315 Lowest value principle, 69
Deferred, 315
Periodic inventory, 315
Procedures subject to permission, 316
M
Sample-based physical inventory, 315
Inventory costing, 235 Maintain
Invoice Allocation, 340
Cuplicated, 91 Make-to-order, 224
Invoice receipt, 87, 94 Make-to-stock, 224
Invoice verification, 130 Controlling approach, 37
GR-based, 132 Management reporting, 350
Logistics, 131 Manufacturing order, 259
Process, 131 Manufacturing process, 223
Technical, 131 Mapping of delivery costs, 120
Invoicing Masking, 233
Internal, 312 Master data
Item category, 93, 97, 253 Logistical, 225
Master data concept
Value flow-oriented, 58
Master data report, 345

434

298 Book_TIGHT.indb 434 12/4/09 3:50:22 PM


Index

Master recipe, 229 Organizational structure, 44, 51


Material flow, 26 Changing, 51
Material group, 92, 95 Organizational unit
Material ledger, 224 Controlling, 50
Material master, 65 Financial Accounting, 50
View, 66 Outgoing payments, 88
Material type, 110, 112, 113 Overhead, 262
New, 113 Overhead application, 262
Mickey Mouse model, 55 Overhead cost controlling, 262
Migration date, 385 Overhead Cost Controlling, 216
Migration scope, 386
Migration to the SAP General Ledger, 44
MM account determination, 104, 105 P
Simulation, 125
Structure, 105 Parallel accounting
Transaction, 114 Classic general ledger, 54
MM document, 104 Parallel accounts, 55
Modified standard cost estimate, 236 Parallel company codes, 54
Movement indicator, 115 Parallel ledger
Movement type, 114, 116 Migration, 57
Moving average price, 67 Parallel ledgers, 56
Parallel rendering of accounts, 53
SAP General Ledger, 56
N Partial payment, 203
Partner role, 193
Net discount, 171 PA transfer structure, 81, 278
Net schema, 175, 176 Payable, 90
Non-valuated goods receipt, 128 Payer, 193
Noted items, 189 Payment block
Permanent, 153
Payment difference, 201
O Large variance, 203
small difference, 201
Offsetting entry to the stock posting Payment method, 91, 150, 196
(GBB), 120 Payment on account, 203
Open item control, 59 Payment proposal, 153
Operating chart of accounts, 64 Payment run, 149
Operating concern, 49, 76 Percentage rate
Error message, 79 Define, 239
Operative controlling, 349 Performance management, 37
Order BOM cost estimate, 295 Period accounting, 346
Order-related cost object controlling, Period closing program
258 Settings, 327
Order status, 290 Period control, 326
Order type Period-end closing, 285, 289, 297
Commitment update, 99 Periodic APC values posting, 323

435

298 Book_TIGHT.indb 435 12/4/09 3:50:22 PM


Index

Periodic business transaction, 188 Procurement process, 85


Periodic cost object controlling, 258 Product controlling
Periodic settlement (PER), 286 Period-related, 281
Periodic unit price, 68 Resource-related, 258
Period-related product controlling, 281 Sales-order-based, 258
Permanent payment block, 153 Product cost by sales order, 258, 292
Perspective Product cost collector, 259, 282
Business, 28 Product cost controlling, 225
Value-based, 28 Basic setting, 231
Physical inventory prices, 68 Time schedule, 261
Plan Product cost planning, 241
Activity type, 231 Type, 241
Planning, 32 Product Cost Planning
Planning processes, 33 Type, 242
Plant level, 106 Production, 32
Porter‘s value chain model, 30 Production cost planning, 222
Posting Production process, 221
Automatic, 268 Production typology, 260
WIP posting, 268 Profitability analysis, 373
Posting period, 327 Profit and loss statement (P&L
Close, 327 statement), 346
Open, 327 Capitalization, 317
Posting Procedure, 191 Return, 317
Posting rule, 198 Profit center, 48, 163
Preliminary costing, 283, 289, 294 Matrix organization, 163
Price Profit Center Accounting, 380
Update, 106 Profit center assignment
Price control, 67 Change, 53
Price determination, 166, 209 Profit center derivation, 49, 163
Price-determining element, 166 Derivation rules, 384
Article, 171 From the material master, 163
Customer, 171 Substitution, 164
Sales and distribution, 170 Profit center/segment link, 50
Price differences (PRD), 121 Profit Center Update, 301
Price update, 250 Pro forma invoice, 214
Pricing Project
Costing sheet, 167 Charter, 379
Trigger, 177 Dry run, 397
Pricing procedure, 236 Financial Accounting/Controlling
Primary activity, 30 value flows, 396
Primary cost element, 61 Initial situation, 379
Process Phases, 387
Integration, 43 Plan, 385, 387
Process category, 161 Preliminary considerations, 380
Process design, 37 Redesigning value flows, 391
Procurement, 32 Review, 397

436

298 Book_TIGHT.indb 436 12/4/09 3:50:23 PM


Index

Scope, 384 Recurring entry, 148


Segment, 391 Reference variant, 240
Value flows in sales process, 394 Release
Value flows in the procurement Automatic, 141
process, 393 RemoteCube, 372
Purchase order, 92, 128 Replacement value, 70
Purchase order history, 129 Report
Purchase order status, 129 RGUIST01, 384
Purchase requisition, 92 Reporting, 345, 349
Purchasing data, 91 Reporting and analysis option, 353
Purchasing info record, 94 Requirement
International, 53
Requirements class, 71, 212
Q Derivation, 72
Requirements type, 72
Quantity field, 80 Resource, 227
Quantity fields, 177 Results analysis, 297
Quantity flow Key, 72, 266
MM, 180 Version, 266
Quantity update, 112 Retained earnings account, 335
Query, 359 Parallel financial reporting, 336
Returns, 33
Revaluate, 256
Revaluation, 256
R
Revenue, 217
Real-time integration, 58, 302 Cost-reducing, 217
Account, 308 Revenue account determination, 206
Account determination, 306, 309 Account determination procedure, 213
Variant specification, 304 Account determination type, 211
Real-time integration (RTI), 396 Condition technique, 210
Rebate, 174 Customer account assignment group,
Receipt indicator, 117 207
Receivable, 182 Material account assignment group,
Reclassification, 333 207
Reconciliation, 341 Prerequisites, 206
Accounting, 341 Rebuild, 217
Financial Accounting and inventory Troubleshooting, 218
management, 343 Revenue planning, 294
Financial Accounting ñ Controlling, Revenue recognition, 204
344 Method, 204
Financial Accounting ñ EC-PCA, 344 Time, 204
Financial Accounting ñ FI-AA, 324 Time of service performance, 204
Reconciliation account, 89, 186, 333
Changeable, 188, 341
Vendor, 89 S
Reconciliation ledger, 302
Sales and distribution, 33

437

298 Book_TIGHT.indb 437 12/4/09 3:50:23 PM


Index

Sales document item, 259 Characteristic, 375


Sales order, 162 Value field, 375
Profit center account assignment, 181 Service, 371
Sales order controlling, 38, 74 Setting
Sales order costing, 294 Current, 150
Sales revenue, 204 Settlement, 275, 297
SAP BusinessObjects, 364 Control, 279
SAP ERP Profile, 72, 276, 318
Value flow model, 42 Rule, 72
SAP General Ledger Simulation and base planning object,
Account determination, 331 251
SAP Management Cockpit, 364 Simulation costing, 251
SAP NetWeaver BW, 353 Simultaneous costing, 261, 284, 289,
Additional information, 377 295
SAP Note Single document
69642, 150 Transfer, 58
77430, 150 Small differences in Materials
81153, 150 Management (DIF), 121
213444, 192 Source, 82
SAP system Source of supply, 92
Components, 43 Source structure, 278
Historically grown, 42 Special business transaction, 175
Organizational element, 44 Special G/L indicator, 189
Structure, 42 Create, 189
Scenario, 300 Down payment request, 191
Scheduling, 240 Property, 190
SCOR model, 31, 86, 160, 223 Special G/L sales, 190
Business process category, 32 Special G/L transaction
Configuration level, 33 Integrated with SD, 192
Design level, 35 Special G/L transactions, 188
Extend, 36 Special ledger, 54
First level, 33 Special stock, 116
Link levels, 34 Split valuation, 109
Production model, 35 Standard account assignment, 119
second level, 33 Standard cost estimate, 235
Secondary activity, 30 Standard price, 121
Secondary business, 194 Standard value key
Debit-side, 194 Define, 228
Vendor, 148 Stock change account, 181
Secondary cost element, 61 Stock change (BSV), 119
Segment, 49, 164 Stock issue
Define, 339 Account determination, 181
Financial statements, 57 Stock posting (BSX), 119
Segmentation, 301 Storage
Segment derivation, 164 Final, 255
BAdI, 165 Temporary, 255
Select Strategic decision, 221

438

298 Book_TIGHT.indb 438 12/4/09 3:50:23 PM


Index

Structural change, 51 Task list, 396


Substitution, 164 Tax code, 154
Subtotal, 170 Maintain, 154
Supply chain, 26 Tax on sales/purchases, 154
Supply Chain Council (SCC), 32 Tax procedure, 154
Support processes, 34 Terms of payment, 186
Surcharge, 170, 171 Test phase, 388
Symbolic account, 313 Tolerance, 138
Tolerance group, 202
Tolerance key, 139
T AN, 139
AP, 139
Tab BD, 139
Additional Log, 153 KW, 140
Basic Data, 228 LA, 140
Control, 282, 287 LD, 140
Cost Accounting, 282 PP, 140
Costing, 66, 228, 229 PS, 140
Costing 1, 163 VP, 140
Costing1, 70 Tolerance limit, 138
Costing 2, 70 Totals table, 381
Dates, 244 FAGLFLEXT, 306
Details, 136 Transaction, 114, 118
Financial Accounting, 66 0KEM, 164
Header, 283 3KEH, 49
Invoice, 132 ABST2, 324
Overhead Costs, 236 AJAB, 325
Parameter, 135 AJRW, 325
Payment Transactions, 202 AO90, 320
Sales General/Plant, 70, 163 ARAL, 325
Sales sales org. 1, 70 ASKB, 323
Valuation, 244 CK11N, 251
Table CK24, 251
ANLC, 324 CK40N, 244
BKPF, 382 CKMATSEL, 244
BSEG, 382 Clear, 144
Customer-specific, 392 CO01, 282, 287
FAGLFLEXA, 382 CO02, 289
FAGLFLEXT, 369, 382 CR01, 228
T042A, 150 CS01, 225
T042D, 150 CS11, 227
T156SY, 117 Enjoy transaction, 156
Totals table, 381 F.03, 341
Table access, 79 F.07, 336
Target costs, 257 F.13, 143, 144, 145
Calculate, 257 F.19, 146
Target ledger group, 332 F110, 152

439

298 Book_TIGHT.indb 439 12/4/09 3:50:23 PM


Index

FAGLBW03, 369 OMWB, 125


FAGLF101, 334 OMWN, 118
FAGLGVTR, 335 OV25, 210
FB01, 156 OVF3, 179
FB02, 153 OVZG, 71
FB50, 156 RSA1, 367
FB60, 156 SA38, 384
FTXP, 154 SAP standard, 118
GCAC, 344, 388 SBIW, 365, 374
KAH1, 82 V/08, 167
KALC, 58, 302 VA03, 179
KEA0, 78 VA44, 297
KEA5, 76 VF03, 218
KEA6, 80 VOFA, 194
KEAT, 344 Transaction category, 198
KEAW, 344 Transaction code
KEND, 51 external, 198
KI12, 262 Transaction key, 114
KKAX, 272 Transfer control, 240
KKE1, 251 Transfer posting
KKEB, 256 Manual, 308
KKF6N, 282, 283 Transformation, 358
KKS2, 275 Turning action into data, 36
KOT2_OPA, 99
MB5L, 343
ME21, 68 U
MF30, 283
MIGO, 115 Unit costing, 251
MIGO_GI, 115 United States Generally Accepted
MIGO_GO, 115 Accounting Principles (US-GAAP, 54
MIGO_GR, 115 Unplanned delivery costs (UPF), 122
MIGO_TR, 115 Post, 137
MIRO, 133, 138 Update material price, 242
MR11, 145 Updating
MRBR, 141 Material price, 242
OB52, 327
OB58, 348
OBA5, 91
V
OBZT, 156
OKB9, 119, 137, 179, 203 Valuated goods receipt, 128
OKG1, 266 Valuation
OKG8, 267 Split, 109
OKGB, 271 Valuation area, 107
OKKP, 98 Group, 107
OKO7, 318 Valuation class, 66, 109, 123
OKP1, 328 Assign, 112
OME9, 98

440

298 Book_TIGHT.indb 440 12/4/09 3:50:23 PM


Index

Create, 112 Vendor management and vendor


Customizing, 110 controlling, 38
Valuation grouping code (VGC), 107 Vendor master, 89
Assign, 108 Accounting view, 89
Valuation level, 106, 123 General part, 89
Valuation variant, 236, 248, 273 Vendor secondary business, 148
Valuation view, 236 Vendor selection, 86
Value-based perspective, 28 Vendor with a debit balance, 333
Value creation View, 91
Increase, 31 Virtual cube, 371
Value field, 80, 177
Assign, 83
Create, 80 W
fill, 80
Value flow, 26 Wage type, 313
Integrated, 25 Web browser, 363
Order-related product controlling, 291 Work in process (WIP), 264
Period-based product controlling, 285 Customizing, 272
Sales-order-related product Posting, 268
controlling, 295 Updating, 270
Sales process, 162 Worklist, 244
Start in sales order, 161
Value flow model
In SAP ERP, 42
Y
Value string, 117
Value update, 112 Year-end closing, 325
Variance calculation, 273
Variance Calculation, 275
Variance category, 83
Variance key, 273
Variance variant, 274
Vendor consignment stock, 129

441

298 Book_TIGHT.indb 441 12/4/09 3:50:23 PM

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy