第 285 页 / 共 337 页
270 CHAPTER 7 SPECIAL AREAS
T he steps involved in each of these approaches are presented in
Table 7.2.
Adjusting the Balance per Bank Adjusting the Balance per Books
Balance per Bank Statement on Balance per Books on MM/DD/YY
MM/DD/YY
Add: Deposits in transit Deduct: Deposits in transit
Deduct: Outstanding checks Add: Outstanding checks
Add or Deduct: Bank errors Add or Deduct: Bank errors
Adjusted/Corrected Balance Adjusted/Corrected Balance
per Book per Bank
TABLE 7.2 Bank reconciliation
In SAP solutions, when the bank reconciliation process is implemented,
you will have a minimum of three G/L accounts: (1) incoming clearing account,
(2) outgoing clearing account, and (3) main account.
Once the company has issued checks to their vendors, it will pass the following
entries:
Debit Vendor Account
Credit Outgoing clearing account
When receiving checks, the company will pass the following entries:
Debit Incoming clearing account
Credit Customer Account
W hen the company receives a bank statement from its bank, it passes the
following accounting entries:
For incoming payment:
Debit Bank main account
Credit Incoming clearing account
| Adjusting the Balance per Bank | Adjusting the Balance per Books |
| Balance per Bank Statement on MM/DD/YY | Balance per Books on MM/DD/YY |
| Add: Deposits in transit | Deduct: Deposits in transit |
| Deduct: Outstanding checks | Add: Outstanding checks |
| Add or Deduct: Bank errors | Add or Deduct: Bank errors |
| Adjusted/Corrected Balance per Book | Adjusted/Corrected Balance per Bank |
第 286 页 / 共 337 页
7.4 LOCKBOX CONFIGURATION 271
For outgoing payment:
Debit Outgoing clearing account
Credit Bank main account
W hen the company passes these entries, the main bank account balance
will agree with the bank balance as per bank.
T o carry out automatic/manual bank reconciliation, you need to configure
the following steps:
n C reate Account Symbol (OT53): In this step, you will create
various IDs for banking transactions, such as the following:
(1) CI—Check Issues, (2) CR—Check Receipts, (3) BD—Bank
Debits, (4) BC—Bank Credits, and (5) BM—Bank Main Accounts.
n Assign Account to Account Symbol (OT53) : In this step, you
will assign G/L accounts to account symbols.
n Create Keys for Posting Rule (OT53): In this step, you will
create posting rules and IDs.
n Define Posting Rules (OT53) : In this step, you will assign
posting keys, account symbols, document types, and posting
types to posting rules.
n D efine Variant for Manual Bank Statement (OT43) : In
this step, you will define a screen variant for data entry for bank
reconciliation.
U sing transaction code FF67 from the application menu, you can input
data for manual bank reconciliation statements. You can upload a BAI file for
electronic bank statements through T-code FF.5.
7.4 LOCKBOX CONFIGURATION
A lockbox is an arrangement with a bank under which payments are mailed to a
strategically located post office box that is serviced by the bank. The bank picks
up the payments from the post office several times a day and accelerates the
processing of the checks to make funds available to the customer. Lockboxes
enhance the security and control of funds and can reduce workloads in customer
service offices.
第 287 页 / 共 337 页
272 CHAPTER 7 SPECIAL AREAS
The following steps need to be carried out to use a lockbox:
1. Define House Bank (FI12): In this step, you will create a house bank, bank
ID, and account ID. Each house bank of a company code is represented by a
bank ID in the SAP system, and every account at a house bank is represented
by an account ID. In the SAP system, you use the bank ID and the account
ID to specify bank details. These specifications are used, for example, for
automatic payment transactions to determine the bank details for payment.
P ath : SAP Customizing Implementation Guide → Financial Accounting → Bank
→ →
Accounting Bank Accounts Define House Banks
2. Define Lockboxes for House Bank (SPRO) : In this step, you define
your lockbox accounts at the house banks. Thus, on the outgoing invoice you
can inform your customer of the lockbox to which payment is to be made.
By specifying this, you can optimize the payment transactions. The lockbox
procedure is currently used only in the United States.
P ath: SAP Customizing Implementation Guide → Financial Accounting →
→ →
Bank Accounting Bank Accounts Define House Banks
3. Define Lockboxes for House Banks (SPRO): In this activity, you store
control data for the lockbox procedure. This data is needed for importing
lockbox files sent by banks. Currently, only BAI and BAI2 file formats are
supported by SAP solutions.
P ath: SAP Customizing Implementation Guide → Financial Accounting → Bank
→ →
Accounting Bank Accounts Define Lockboxes for House Banks
4. Define Posting Data (SPRO): In this activity, you store information needed to
process particular lockbox data and generate postings. The Destination and Origin
are routing information and defined by your bank. For every unique destination/
origin, posting information is needed to create the following postings:
G/L posting—Debit bank account (incoming checks) and credit payment clear-
n
ing account
A/R posting—Debit payment clearing account and credit customer account
n
Path: SAP Customizing Implementation Guide → Financial
→ → →
Accounting Bank Accounting Business Transactions Payment
→ →
Transactions Lockbox Define Posting Data
The following steps need to be carried out from the application side:
1. Main Lockbox Program to Upload Data (FLB2):
2. Post Processing of Lockbox Data (FLB1):
第 288 页 / 共 337 页
7.5 REVENUE RECOGNITION 273
7.5 REVENUE RECOGNITION
T he revenue recognition principle arises from accrual accounting and the
matching principle. Accrual accounting and the matching principle help the user
determine how a business entity will determine whether a particular transaction
will be treated as an expense or revenue.
I n accrual accounting, revenues are recognized when you have realized and
you have performed, i.e., when goods are transferred or services rendered, no
matter when cash is received.
In cash accounting, revenues are recognized when you have received cash,
regardless of the timing of goods or services sold. Revenue recognition depends
upon the nature of the transaction. From an academic point of view, transactions
can be broadly divided into four types: (1) selling inventory, (2) selling services,
(3) leasing activities, and (4) selling of assets other than inventory.
Revenue recognition occurs from four types of transactions:
1. R evenue from selling inventory is recognized at the date of sale, which is
often interpreted as the date of delivery.
2. R evenue from rendering services is recognized when services are completed
and billed.
3. R evenue from permission to use a company’s assets (e.g., interest for using
money, rent for using fixed assets, and royalties for using intangible assets)
is recognized as time passes or as assets are used.
4. Revenue from selling an asset other than inventory is recognized at the point
of sale when it takes place.
R evenue recognition mostly applies when you are billing your customer in
advance. For example, you entered a service contract (such as a maintenance
contract) with your customer for $12,000 for one year. As per payment terms,
you billed your customer in advance. Therefore, as of January 1, you billed your
customer for an entire year and the customer paid. At the end of January, you can
treat $1,000 as your income and the remaining $11,000 remains as a liability.
第 289 页 / 共 337 页
274 CHAPTER 7 SPECIAL AREAS
FIGURE 7.3 Revenue recognition
To handle revenue determination in an SAP solution, you need the following
configuration:
1. Set Revenue Recognition for Item Categories: In this step, you will
maintain two fields: (1) your revenue recognition method and (2) the
start date. These configuration steps are in the following path: S ales and
→ → →
Distribution Basic Functions Account Assignment/Costing Revenue
→
Recognition
FIGURE 7.4 Revenue recognition
第 290 页 / 共 337 页
7.6 AUTOMATIC PAYMENT PROGRAM 275
Rev. recognition: Here you specify the revenue recognition category. There
are four types of revenue recognition categories: (1) No value, (2) A, (3) B, and
(4) D. This designates how you are going to determine your revenue.
Acc. period start: This indicator determines the start date of revenue
recognition.
2. Maintain Account Determination: In this IMG step, you will assign various
G/L accounts to which transactions will be posted.
Determine the revenue account: The revenue account is maintained in the fi rst
column. This is confi gured through transaction code VKOA.
Assign account for unbilled receivables: In this step, you will assign G/L
accounts for the deferred revenue account (special G/L account) and the
unbilled receivable account.
A fter configuration, the SD user will post the customer invoice for the full
amount in the SD module. Once you run transaction code VF44, the system will
list the transactions that need to be considered as revenue for the said period.
7.6 AUTOMATIC PAYMENT PROGRAM
Through an automatic payment program, you can pay both vendors and
customers to whom you owe money. The transaction code for the configuration
of an automatic payment program is FBZP. To execute the program, you would
use transaction code F110. There are five steps to configure an automatic
payment program:
1. All Company Code: Enter the sending and paying company codes, outgoing
payment with cash discount from. In this step, you will define the sending
and paying company code relation.
2. Paying Company Code: Enter the minimum amount of the incoming and
outgoing payments and the form for the payment advice.
3. Country Payment Methods: Select Check will be created, Allowed for
personal payments, Street, P.O. box or No. (bank details for wire transfer),
or RFFOUS_C (RFFOUS_T for wire transfer) as the print (payment)
program.
4. Company Code Payment Methods: Enter minimum and maximum
amounts and the form for payment transfer. The payment per due day,
optimized by bank group or postal code, can also be selected.
第 291 页 / 共 337 页
276 CHAPTER 7 SPECIAL AREAS
5. Bank Determination : If there is more than one house bank, a ranking order
can be given. Under Amounts, specify the amount available for outgoing
payment. Under Accounts, enter the bank clearing account for the bank
subaccount.
After configuring the automatic payment program, you will run it using
transaction code F110. Follow these steps:
1. Enter the Run Date and Identification and go to the Parameters tab.
2. E nter company codes, payment methods, the next pay date, and vendor
accounts.
3. Go to the Additional Log tab and select due date check, payment method
selection in all cases, and line items of the payment documents.
4. G o to the Printout/data medium tab, enter the variant against the payment
program, and select Maintain Variants .
5. Enter the paying company code, house bank details, and check lot
number.
6. Select Print Checks and Print payment summary for checks and P rint
payment advice notes for wire transfers (enter the printer and select
Print immediately). Also set the number of sample printouts to zero.
7. Then execute Proposal , Payment run , and P rintout .
7.7 THREE-WAY MATCH
T he three-way match is part of the procure to pay (P2P) process. Refer to the
SAP Business process section for details of the P2P. The P2P process involves
various steps depending on configuration and the SAP modules implemented.
Out of all the steps involved in the P2P process, these three steps are components
of the three-way match:
n Creation of PO (T-code ME21N)
n Goods receipt (T-code MIGO)
n LIS invoice receipts (T-code MIRO)
第 292 页 / 共 337 页
7.8 P2P 277
1. A fter sorting the list of vendors, the purchase department will create a purchase
order through transaction code ME21N. In this step, there is no accounting
impact, but in Controlling (CO), the PO will create a commitment posting
if you have activated commitment management. This commitment item will
be converted into an actual posting once you have received material.
2. O nce you have received goods, the goods receiving clerk will enter the goods
receipts into the SAP system through transaction code MIGO. While posting
the goods receipt, the system will check quantity, goods, and price against
the PO. If you have partial goods against a PO, the goods receiving clerk will
modify the quantity, which will leave the PO open until the next goods receipt.
The G/L is automatically updated with postings made to the G/L, cost centers,
or asset accounts, while an offsetting posting will be made to a new general
account called the GR/IR account. The accounting will be as follows:
Expenses Accounts Debit
Inventory Debit
Assets Debit
GR\IR Credit
3. The accounting department will receive an invoice from the vendor. Invoice
verification is the last step in the three-way match. While posting the invoice,
the system will check goods receipts for quantity and price with PO. The
following entry is posted once you save the invoice:
GR/IR Debit
Vendor Credit
7.8 P2P
An organization sells goods and services. To sell goods and services, naturally, it
will have to procure these goods and services or produce them. The procurement
part of goods and services is handled by the purchasing department of an
organization. Although the procurement process starts with the purchase
department, it flows to various departments and ultimately ends with a payment
第 293 页 / 共 337 页
278 CHAPTER 7 SPECIAL AREAS
to the vendor. In SAP solutions, the P2P cycle may be simple or complex,
depending on the modules implemented and the client’s business process. The
following shows how the P2P process can be viewed using different modules.
n P2P process with FICO module: When you are only working
with the FICO module, the P2P process is pretty simple. In this
case, the recording of goods movement will be taken care of
outside of the SAP solution.
Vendor invoice posting
n
Payment to vendor
n
n P2P process with FICO and MM modules:
Source determination
n
Purchase order
n
Goods receipt
n
Invoice verifi cation
n
Payment to vendor
n
7.9 VENDOR DOWN PAYMENT AND CLEARING
“ Down payment” is the term used when you are entering into agreement with
your vendor to purchase an expensive item or capital assets. It means an upfront
payment to the vendor before delivery of goods and services, and is also called
an “advance payment.” According to the accrual concept, a down payment or
advance payment is not a liability but rather an asset. Since the down payment is
treated as an asset for your financial statement, it cannot be mixed with normal
transactions with vendors. In SAP solutions, a down payment is treated as a
special G/L transaction. Down payment transactions are shown and recorded
in a different reconciliation (control) account called an alternative reconciliation
account. As per SAP standards, a vendor down payment process involves the
following steps:
1. Down payment request (T-code F-37)
2. Down payment (T-code F-29 or F110)
3. Invoice (T-code FB70)
4. Down payment clearing (T-code F-39)
第 294 页 / 共 337 页
7.10 ORDER TO CASH (OTC) 279
T he down payment request is an optional step, but the advantage of this step
is that you can make payment to your vendor through an automatic payment
program.
FIGURE 7.5 Down payment processing
W hen clearing the down payment, the system will do a transfer posting from
the alternative reconciliation account to the normal reconciliation account. For
this automatic account determination, you need to configure the vendor down
payment through transaction code OBYR.
7.10 ORDER TO CASH (OTC)
The order to cash (OTC) process covers all to the steps related to placing an order
from customer purchase order to cash collection from the customer. During this
process, the user has to go through various steps for successful processing of a
business transaction. Before delivering material to a customer, the company has
to check the customer’s credit and the availability of the material. This process
第 295 页 / 共 337 页
280 CHAPTER 7 SPECIAL AREAS
involves the SD, MM, and FICO modules. Generally, the following steps are
involved in a typical situation:
n Sales quotation
n Standard order
n Shipping
n Delivery
n Picking
n Posting goods issue
n Warehouse picking execution
n Packing
n Billing: Using transaction code VF01, the SD user will create a
billing document, which will trigger an FI document to record
the FI transaction.
n Payment of customer: This is a FI process. Through various FI
transaction codes, you can record incoming payments.
7.11 MAKE TO ORDER
S ometimes a customer requests a specific product that is not a generally
available product line of your vendor. This circumstance requires the make to
order process.
M ake to order is initiated after receiving a customer order. The sales
department receives the customer’s make to order and passes the sales order to
the material department, as well as the purchasing department, which checks
for the required materials. The material requirement analysis is carried out
through the SAP solution. In the material requisition planning (MRP) run, the
SAP software explodes the Bills of Material (BOM) for all levels. If the required
materials are not available, the MRP will create planned orders.
P lanned orders for materials produced in-house will be converted into
production orders, while planned orders for materials procured from outside
will be converted into purchase orders.
T he availability of material produced in-house and procured from outside
will be decided through the replenishment time mentioned in the material
master. In the case of in-house produced goods, the route time will take
precedence over the replenish date mentioned in the material master.
第 296 页 / 共 337 页
7.12 SUMMARIZATION LEVELS IN CO-PA 281
The cycle of made to order is as follows:
n Create material for make to order
n Route creation
n Create BOM
n Sales order
n Production order
n Recording of finished goods
n Delivery against sales order
n Invoicing
7.12 SUMMARIZATION LEVELS IN CO-PA
To satisfy various business needs, CO-PA deals with large data to produce
segment reports, i.e., reports based on customer hierarchy, product group, or
geographical location. Due to the large volume of data handling, the user may
question system performance. To increase response time, the SAP R/3 system
provides a summarization concept in CO-PA.
S ummarization means the system aggregates data based on required
segments and stores the data in a different set of tables. Since the system holds
data in summary form in different tables, it provides quick access to the user.
W hen the user runs a particular CO-PA report, the system looks for the
most suitable summarization table instead of the CE1XXXX table (where XXXX
is the operating concern name).
I n the absence of the summarization level, the system always looks for
CE3XXXX and CE4XXXX tables for each and every run. A summarization level
stores the original dataset in a reduced form.
From a technical point of view, a summarization consists of two tables
that have just been generated, the key table and the totals table. The key table
corresponds to the segment table and contains the pseudosegments produced
from the reduced characteristics. The totals table corresponds to the segment
level and contains the associated value fields.
F igure 7.6 shows the summarization levels. From top to bottom, it goes
from more specific segments to less specific segments.
第 297 页 / 共 337 页
282 CHAPTER 7 SPECIAL AREAS
FIGURE 7.6 Summarization levels
I n the absence of the summarization level, the SAP R/3 system will return
the following types of warnings shown in Figures 7.7 and 7.8:
FIGURE 7.7 CO-PA reporting error
第 298 页 / 共 337 页
7.12 SUMMARIZATION LEVELS IN CO-PA 283
FIGURE 7.8 CO-PA reporting error
To avoid these messages and increase system performance, you have to
build a summarization level following these steps:
1. Create Automatic Proposal for Summarization Levels (T-code
KEDVP) : In this step, the data system will propose new summarization
levels according to CO-PA usage. SAP R/3 allows you to create up to 5,000
summarization levels.
2. Define/Change Summarization Levels (T-code KEDV) : Once
summarization levels are proposed, you can change the attributes of the
summarization level in this step. The summarization level status will be
active without data.
3. Build Summarization Levels (T-code KEDU) : Once you build your
summarization level, you need to populate it with data. The summarization
level holds historical data; to use it properly, you need to execute this
transaction at the proper interval to populate the summarization level with
recent data.
第 299 页 / 共 337 页
第 300 页 / 共 337 页
8
N G/L
EW
Chapter
To satisfy a broader range of internal and external requirements, the mySAP
ERP application combines all general ledger functionality under one roof.
mySAP ERP also streamlines various functions of earlier versions, which
makes reporting easier and meets all internal and external reporting requirements.
Now New G/L provides a unified structure for cost of sales accounting, profit
center accounting (PCA), and segment reporting. The New G/L ledger has the
following advantages:
n Accelerates period-end processing
n Makes reporting easier by providing real-time reconciliation
between FI and CO
n Lets an entity report in multiple ways by providing multiple
ledgers within G/L accounting
n Has an extended data structure so the customer can add new
fields to standard tables
Refer to OSS: 756146 for a more complete list of advantages.
mySAP combines the following features of older versions into the New G/L
concept:
n General ledger (G/L)
n PCA
n Reconciliation ledger
n Special-purpose ledger (SPL)
n Business area
n Cost of sales accounting
285
第 301 页 / 共 337 页
286 CHAPTER 8 NEW G/L
FIGURE 8.1 Comparing R/3 Enterprise and mySAP ERP
Implementation of New G/L is compulsory for newer customers and
optional for existing SAP customers. If existing customers want to use this
functionality, they can activate it by using transaction code FAGL_ACTIVATION.
New G/L activation is client specific, not company code specific. After activation
of New G/L, you will find some new paths for New G/L, in addition to the old
paths. See Figure 8.2.
FIGURE 8.2 New G/L menus
第 302 页 / 共 337 页
CHAPTER 8 NEW G/L 287
After activating New G/L, you will have two views for document display:
(1) Data Entry View and (2) General Ledger View as shown in figures 8.3
and 8.4.
FIGURE 8.3 Data Entry View
FIGURE 8.4 General Ledger View
Since New G/L substitutes FI_SPL, it comes with leading and nonleading
ledger concepts. For the time being, think of leading ledgers as your G/L
and non-leading ledgers as your FI_SPL. Table 8.1 points out the differences
between leading ledgers and nonleading ledgers.
第 303 页 / 共 337 页
288 CHAPTER 8 NEW G/L
Leading Ledger Nonleading Ledger
Existence Required Optional
Transaction All FI transactions will be updated May or may not be posted with
Posting all FI transactions
Currencies Takes currencies from company code Can maintain currencies different
from company code
Fiscal Year Same as company code Can be different from company
code
Accounting Follow basic accounting principle May follow different accounting
Principle principle
Number of One leading ledger for a given company May have zero or more
ledgers code
TABLE 8.1 Leading ledger versus nonleading ledger
mySAP comes with a brand-new table (FAGLFLEXT) that contains
additional fields. The FSGLFEXT table thus supports the following
activities:
n Segment reporting
n Profit center updating
n Cost of sales accounting
n Cost center updating
n Preparation for consolidation
n Business-area updating
You can add new fields to this table to capture different scenarios.
8.1 DOCUMENT SPLITTING
The main functionality of New G/L is document splitting. You use document
splitting to capture additional missing accounting assignments by which each and
every document is balanced individually. As an example, say you are entering a
| Leading Ledger | Nonleading Ledger | |
| Existence | Required | Optional |
| Transaction Posting | All FI transactions will be updated | May or may not be posted with all FI transactions |
| Currencies | Takes currencies from company code | Can maintain currencies different from company code |
| Fiscal Year | Same as company code | Can be different from company code |
| Accounting Principle | Follow basic accounting principle | May follow different accounting principle |
| Number of ledgers | One leading ledger for a given company code | May have zero or more |
第 304 页 / 共 337 页
8.2 TRANSACTION CODES 289
cost center while posting an expense. From the cost center, expenses are posted
to the profit center. Is the payable also assigned to the profit center? The answer
is “No” if you are using an old version of SAP software, but it is “Yes” if you are
using mySAP. If document splitting is active in mySAP, the system will transfer
the profit center from expense line items to payable line items.
There are three types of document splitting: (1) active (rule-based) split,
(2) passive split, and (3) clearing lines/zero balance formation by balancing
dimensions.
1. Active split: This is a configuration step in which the system will split the
document. Active splitting is applicable for original entries, i.e., vendor
invoice posting and customer invoice posting.
2. Passive split: This is the default setting. Passive splitting is applicable for
subsequent transactions, i.e., clearing of vendor invoice with payment, etc.
3. Clearing lines/zero balance formation by balancing char. (and document):
This occurs when a transfer is made between two segments.
8.2 TRANSACTION CODES
mySAP ERP comes with several new transaction codes that replace existing
transaction codes:
n FAGLB03: Display Balances (New); replaces FS10N
n FAGLL03: Display Line Items (New); replaces FBL3N
n FB50L/FB01L: G/L Document Posting for a Ledger Group;
replaces FB50/FB01
n FAGL_FC_VAL: Foreign Currency Valuation (New); replaces F.05
n FAGLF101: Sorting/Reclassification (New); replaces F101
n FAGLGVTR: Balance Carry-forward (New), replaces F.16,
GVTR, and 2KES
第 305 页 / 共 337 页
第 306 页 / 共 337 页
9 T
ABLES IN THE
SAP S
YSTEM
Chapter
Whenever you enter data in a screen, the data is stored in a table. Sometimes
there may be more than one table linked to a particular screen. As a FICO
functional consultant, you should be aware of important tables in the SAP
software and their data structure. You can use transaction code SE11 to see the
field structure of a table. By invoking transaction code SE16 or SE16N, you can
browse the data in a particular table.
The tables provided in this chapter
9.1 ENTERPRISE STRUCTURE (FI-ES)
The following is an important SAP table for FI enterprise structure:
Table Description
T001 Company code
T005 Countries
TCURC Currency codes
TCURR Exchange rate
TCURT Currency name
T077S Account group (G/L accounts)
T009 Fiscal year variants
T880 Global company data
T014 Credit control area
TABLE 9.1 FI-G/L tables
Continued
291
| Table | Description |
| T001 | Company code |
| T005 | Countries |
| TCURC | Currency codes |
| TCURR | Exchange rate |
| TCURT | Currency name |
| T077S | Account group (G/L accounts) |
| T009 | Fiscal year variants |
| T880 | Global company data |
| T014 | Credit control area |
第 307 页 / 共 337 页
292 CHAPTER 9 TABLES IN THE SAP SYSTEM
Table Description
T004 Chart of accounts (COA)
T077S Account group (G/L accounts)
T009 Fiscal year variants
T880 Global company data
T014 Credit control area
T010O Posting period variant
T010P Posting period variant names
T001B Permitted posting periods
T003 Document types
T012 House banks
TABLE 9.1 FI-G/L tables
9.2 GENERAL LEDGER ACCOUNTING (FI-G/L)
The following is an important SAP table for FI G/L Accounting:
Table Description
SKA1 G/L master—Chart of accounts
segment
SKB1 G/L master—Company code
segment
BNKA Bank master record
BKPF Accounting documents header
Continued
| Table | Description |
| T004 | Chart of accounts (COA) |
| T077S | Account group (G/L accounts) |
| T009 | Fiscal year variants |
| T880 | Global company data |
| T014 | Credit control area |
| T010O | Posting period variant |
| T010P | Posting period variant names |
| T001B | Permitted posting periods |
| T003 | Document types |
| T012 | House banks |
| Table | Description |
| SKA1 | G/L master—Chart of accounts segment |
| SKB1 | G/L master—Company code segment |
| BNKA | Bank master record |
| BKPF | Accounting documents header |
第 308 页 / 共 337 页
9.3 ACCOUNTS RECEIVABLE (FI-AR) 293
Table Description
BSEG Accounting documents item level
BNKA Bank master record
BSAD Accounting: Index for customers
(cleared items)
BSAK Accounting: Index for vendors
(cleared items)
BSAS Accounting: Index for G/L
accounts (cleared items)
TABLE 9.2 FI-G/L tables
9.3 ACCOUNTS RECEIVABLE (FI-AR)
The following is an important SAP table for FI Accounts Receivable:
Table Description
KNA1 Customer master—General
data
KNB1 Customer master—Company
code data
KNVV Customer master—Sales data
KNBK Bank details
KNVH Customer hierarchy
KNVP Customer partners
KNVS Shipment data for customer
KNVK Contact persons
KNVI Customer master tax indicator
TABLE 9.3 FI-AR tables
| Table | Description |
| BSEG | Accounting documents item level |
| BNKA | Bank master record |
| BSAD | Accounting: Index for customers (cleared items) |
| BSAK | Accounting: Index for vendors (cleared items) |
| BSAS | Accounting: Index for G/L accounts (cleared items) |
| Table | Description |
| KNA1 | Customer master—General data |
| KNB1 | Customer master—Company code data |
| KNVV | Customer master—Sales data |
| KNBK | Bank details |
| KNVH | Customer hierarchy |
| KNVP | Customer partners |
| KNVS | Shipment data for customer |
| KNVK | Contact persons |
| KNVI | Customer master tax indicator |
第 309 页 / 共 337 页
294 CHAPTER 9 TABLES IN THE SAP SYSTEM
9.4 ACCOUNTS PAYABLE (FI-AP)
The following is an important SAP table for FI Accounts Payable:
Table Description
LFA1 Vendor master—General data
LFB1 Vendor master—Company code
data
LFM1 Purchasing organization data
LFM2 Purchasing data
LFB5 Vendor dunning data
LFBK Bank details
TABLE 9.4 FI-AP tables
9.5 ASSETS MANAGEMENT (FI-AA)
The following is an important SAP table for FI Assets Management:
Table Description
ANKA Asset classes: General data
ANKT Asset classes: Description
ANLU Asset master record user fields
ANLZ Time-dependent asset
allocations
ANEK Document header asset posting
ANEP Asset line items
ANKB Asset classes: Depreciation area
TABLE 9.5 FI-AA tables
| Table | Description |
| LFA1 | Vendor master—General data |
| LFB1 | Vendor master—Company code data |
| LFM1 | Purchasing organization data |
| LFM2 | Purchasing data |
| LFB5 | Vendor dunning data |
| LFBK | Bank details |
| Table | Description |
| ANKA | Asset classes: General data |
| ANKT | Asset classes: Description |
| ANLU | Asset master record user fields |
| ANLZ | Time-dependent asset allocations |
| ANEK | Document header asset posting |
| ANEP | Asset line items |
| ANKB | Asset classes: Depreciation area |
第 310 页 / 共 337 页
9.7 COST CENTER ACCOUNTING (CO-CCA) 295
9.6 GENERAL (CO)
The following is an important SAP table for Controlling:
Table Description
TKA01 Controlling (CO) areas
TKA02 CO area assignment
KEKO Product costing header
KEPH Cost components for cost of
goods manufacturing
KALO Sales order items—costing
objects
KANZ Accounting: Index for G/L
accounts (cleared items)
TABLE 9.6 CO tables
9.7 COST CENTER ACCOUNTING (CO-CCA)
The following is an important SAP table for CO Cost Center Accounting:
Table Description
CSKS Cost center master data
CSKT Cost center texts
CRCO Assignment of work center to
cost center
COSP CO object: Cost totals for
external postings
COEP CO object: Line items (by
period)
COBK CO object: Document header
COST CO object: Price totals
TABLE 9.7 CO-CCA tables
| Table | Description |
| TKA01 | Controlling (CO) areas |
| TKA02 | CO area assignment |
| KEKO | Product costing header |
| KEPH | Cost components for cost of goods manufacturing |
| KALO | Sales order items—costing objects |
| KANZ | Accounting: Index for G/L accounts (cleared items) |
| Table | Description |
| CSKS | Cost center master data |
| CSKT | Cost center texts |
| CRCO | Assignment of work center to cost center |
| COSP | CO object: Cost totals for external postings |
| COEP | CO object: Line items (by period) |
| COBK | CO object: Document header |
| COST | CO object: Price totals |
第 311 页 / 共 337 页
296 CHAPTER 9 TABLES IN THE SAP SYSTEM
9.8 PROFIT CENTER ACCOUNTING (CO-PCA)
The following is an important SAP table for CO Profit Center Accounting:
Table Description
CEPC Profit center master data table
CEPCT Texts for profit center master
data
GLPCA EC-PCA: Actual line items
GLPCC EC-PCA: Transaction attributes
GLPCO EC-PCA: Object table for
account
GLPCP EC-PCA: Plan line items
TABLE 9.8 CO-PCA tables
9.9 PROFITABILITY ANALYSIS (CO-PA)
The following is an important SAP table for CO Profitability Analysis:
Table Description
CE1XXXX CO-PA—Actual line items (where
XXXX represents operating
concern)
CE2XXXX CO-PA—Plan line items
CE3XXXX Total records—make time-based
classification possible
CE4XXXX PA segment definition: higher
level table used to assign segment
number to each combination of
characteristic values
TABLE 9.9 CO-PA tables
| Table | Description |
| CEPC | Profit center master data table |
| CEPCT | Texts for profit center master data |
| GLPCA | EC-PCA: Actual line items |
| GLPCC | EC-PCA: Transaction attributes |
| GLPCO | EC-PCA: Object table for account |
| GLPCP | EC-PCA: Plan line items |
| Table | Description |
| CE1XXXX | CO-PA—Actual line items (where XXXX represents operating concern) |
| CE2XXXX | CO-PA—Plan line items |
| CE3XXXX | Total records—make time-based classification possible |
| CE4XXXX | PA segment definition: higher level table used to assign segment number to each combination of characteristic values |
第 312 页 / 共 337 页
10 SAP MM
C
ONFIGURATION
Chapter
T he Material Management (MM) module is integrated with the SD, PP, QM,
WM, FI, and CO modules. The MM module is part of the logistic menu in
SAP software. The MM module takes care of inventory management and the
procurement process.
Along with other master data, this module controls two main data masters,
i.e., vendor master and material master.
Similar to the FI and CO modules, you will maintain the organizational
hierarchy while implementing the MM module. This chapter provides an
overview of the MM module and describes the minimum configuration steps.
As a FICO functional consultant, it is necessary that you understand MM
flow if you are working in an implementation site where MM is part of the
implementation.
Client
Company Code Company Code
Plant Plant Plant
Storage Storage Storage Storage
Location Location Location Location
FIGURE 10.1 SAP MM organizational structure
297
第 313 页 / 共 337 页
298 CHAPTER 10 SAP MM CONFIGURATION
Figure 10.1 shows a straightforward MM organizational structure.
Depending upon client requirements, your MM organization may be simple
or complex. Note that this chapter describes configuration steps for a simple
MM module.
In Figure 10.1, observe that the MM module is dependent on the company
code, which is the highest organizational entity in FI. FICO configuration is
not discussed here, so before configuring MM, make sure that FI and CO
configuration have already taken place.
Description and Path T-code
1 Define, Copy, Delete, Check Plant: SPRO → Enterprise OX10
Structure → Definition → Logistics (General) → Define,
Copy, Delete, Check Plant
2 Maintain Storage Location: SPRO → Enterprise OX09
Structure → Definition → Materials Management →
Maintain Storage Location
3 Maintain Purchase Organization: SPRO → Enterprise OX08
Structure → Definition → Materials Management →
Maintain Purchase Organization
4 Assign Plant to Company Code: SPRO → Enterprise SPRO
Structure → Assignment → Logistics (General) → Assign
Plant to Company Code
5 Assign Purchasing Organization to Company Code: OX18
SPRO → Enterprise Structure → Assignment → Materials
Management → Assign Purchasing Organization to
Company Code
6 Assign Purchasing Organization to Plant: SPRO → OX01
Enterprise Structure → Assignment → Materials
Management → Assign Purchasing Organization
to Plant
7 Define Industry Sectors and industry sector-specific SPRO
field section: SPRO → Logistics (General) → Material
Master → Field Selection → Define Industry Sectors and
industry sector-specific field section
Continued
| Description and Path | T-code | |
| 1 | Define, Copy, Delete, Check Plant: SPRO → Enterprise Structure → Definition → Logistics (General) → Define, Copy, Delete, Check Plant | OX10 |
| 2 | Maintain Storage Location: SPRO → Enterprise Structure → Definition → Materials Management → Maintain Storage Location | OX09 |
| 3 | Maintain Purchase Organization: SPRO → Enterprise Structure → Definition → Materials Management → Maintain Purchase Organization | OX08 |
| 4 | Assign Plant to Company Code: SPRO → Enterprise Structure → Assignment → Logistics (General) → Assign Plant to Company Code | SPRO |
| 5 | Assign Purchasing Organization to Company Code: SPRO → Enterprise Structure → Assignment → Materials Management → Assign Purchasing Organization to Company Code | OX18 |
| 6 | Assign Purchasing Organization to Plant: SPRO → Enterprise Structure → Assignment → Materials Management → Assign Purchasing Organization to Plant | OX01 |
| 7 | Define Industry Sectors and industry sector-specific field section: SPRO → Logistics (General) → Material Master → Field Selection → Define Industry Sectors and industry sector-specific field section | SPRO |
第 314 页 / 共 337 页
CHAPTER 10 SAP MM CONFIGURATION 299
Description and Path T-code
8 Define Attributes of Material Type: SPRO → Logistics SPRO
(General) → Material Master → Basic Settings →
Material Types → Define Attributes of Material Type
9 Define Number Ranges for Each Material Type: SPRO
SPRO → Logistics (General) → Material Master → Basic
Settings → Material Types → Define number ranges for
each material type
10 Maintain Company Codes for Material Master: OMSY
SPRO → Logistics (General) → Material Master → Basic
Settings → Material Types → Maintain Company Codes
for Material Master
11 Set Tolerance Limit for Price Variance: SPRO → Materials SPRO
Management → Purchasing → Purchase Order → Set
Tolerance Limit for Price Variance
12 Set Tolerance Limits: SPRO → Materials Management → SPRO
Logistics Invoice Verification → Invoice Block → Set
tolerance limits
13 Group Together Valuation Areas: SPRO → Materials SPRO
Management → Valuation and Account Assignment →
Account Determination without Wizard → Group
Together Valuation Areas
14 Configure Automatic Posting: SPRO → Materials SPRO
Management → Valuation and Account Assignment →
Account Determination without Wizard → Configure
Automatic Posting
TABLE 10.1 MM configuration steps
| Description and Path | T-code | |
| 8 | Define Attributes of Material Type: SPRO → Logistics (General) → Material Master → Basic Settings → Material Types → Define Attributes of Material Type | SPRO |
| 9 | Define Number Ranges for Each Material Type: SPRO → Logistics (General) → Material Master → Basic Settings → Material Types → Define number ranges for each material type | SPRO |
| 10 | Maintain Company Codes for Material Master: SPRO → Logistics (General) → Material Master → Basic Settings → Material Types → Maintain Company Codes for Material Master | OMSY |
| 11 | Set Tolerance Limit for Price Variance: SPRO → Materials Management → Purchasing → Purchase Order → Set Tolerance Limit for Price Variance | SPRO |
| 12 | Set Tolerance Limits: SPRO → Materials Management → Logistics Invoice Verification → Invoice Block → Set tolerance limits | SPRO |
| 13 | Group Together Valuation Areas: SPRO → Materials Management → Valuation and Account Assignment → Account Determination without Wizard → Group Together Valuation Areas | SPRO |
| 14 | Configure Automatic Posting: SPRO → Materials Management → Valuation and Account Assignment → Account Determination without Wizard → Configure Automatic Posting | SPRO |