SAP® FI
FINANCIAL ACCOUNTING

LICENSE, DISCLAIMER OF LIABILITY, AND LIMITED WARRANTY

By purchasing or using this book (the “Work”), you agree that this license grants permission to use the contents contained herein, but does not give you the right of ownership to any of the textual content in the book or ownership to any of the information or products contained in it. This license does not permit uploading of the Work onto the Internet or on a network (of any kind) without the written consent of the Publisher. Duplication or dissemination of any text, code, simulations, images, etc. contained herein is limited to and subject to licensing terms for the respective products, and permission must be obtained from the Publisher or the owner of the content, etc., in order to reproduce or network any portion of the textual material (in any media) that is contained in the Work.

MERCURY LEARNING AND INFORMATION LLC (“MLI” or “the Publisher”) and anyone involved in the creation, writing, or production of the companion disc, accompanying algorithms, code, or computer programs (“the software”), and any accompanying Web site or software of the Work, cannot and do not warrant the performance or results that might be obtained by using the contents of the Work. The author, developers, and the Publisher have used their best efforts to insure the accuracy and functionality of the textual material and/or programs contained in this package; we, however, make no warranty of any kind, express or implied, regarding the performance of these contents or programs. The Work is sold “as is” without warranty (except for defective materials used in manufacturing the book or due to faulty workmanship).

The author, developers, and the publisher of any accompanying content, and anyone involved in the composition, production, and manufacturing of this work will not be liable for damages of any kind arising out of the use of (or the inability to use) the algorithms, source code, computer programs, or textual material contained in this publication. This includes, but is not limited to, loss of revenue or profit, or other incidental, physical, or consequential damages arising out of the use of this Work.

The sole remedy in the event of a claim of any kind is expressly limited to replacement of the book, and only at the discretion of the Publisher. The use of “implied warranty” and certain “exclusions” vary from state to state, and might not apply to the purchaser of this product.

SAP® FI
FINANCIAL ACCOUNTING

SAP® ERP ECC 6.0
SAP® R/3 4.70

V. Narayanan

MERCURY LEARNING AND INFORMATION

Dulles, Virginia
Boston, Massachusetts
New Delhi

Reprint Copyright ©2013 by MERCURY LEARNING AND INFORMATION LLC. All rights reserved.
Original Copyright © 2010 BPB Publications. ISBN : 978-81-8333-323-8

This publication, portions of it, or any accompanying software may not be reproduced in any way, stored in a retrieval system of any type, or transmitted by any means, media, electronic display or mechanical display, including, but not limited to, photocopy, recording, Internet postings, or scanning, without prior permission in writing from the publisher.

Publisher: David Pallai

MERCURY LEARNING AND INFORMATION

22841 Quicksilver Drive

Dulles, VA 20166

info@merclearning.com

www.merclearning.com

1-800-758-3756

V. Narayanan, SAP® FI: Financial Accounting.

ISBN: 978-1-937585-64-8

SAP® ERP Financials is the trademark(s) or registered trademark(s) of SAP AG in Germany and in several other countries. SAP AG is not the publisher of this book, and is not responsible for the views mentioned in this book (see also below).

The publisher recognizes and respects all marks used by companies, manufacturers, and developers as a means to distinguish their products. All brand names and product names mentioned in this book are trademarks or service marks of their respective companies. Any omission or misuse (of any kind) of service marks or trademarks, etc. is not an attempt to infringe on the property of others.

Library of Congress Control Number: 2012956347

131415321          Printed in the United States of America
This book is printed on acid-free paper.

This publication contains references to the products of SAP AG. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP company.

SAP AG is neither the author nor the publisher of this publication and is not responsible for its content. SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Our titles are available for adoption, license, or bulk purchase by institutions, corporations, etc. For additional information, please contact the Customer Service Dept. at 1-800-758-3756 (toll free).

The sole obligation of MERCURY LEARNING AND INFORMATION to the purchaser is to replace the book and/or disc, based on defective materials or faulty workmanship, but not based on the operation or functionality of the product.

To my dear wife, Meena.

DISCLAIMER

The contents of this book are the views of the author, together with inputs from the experience of colleagues in consulting for SAP projects. The views expressed in this book should not be construed as those of SAP AG. Any omissions or factual inaccuracies in this book, if any, in correctly depicting SAP methods, etc. are unintentional.

CONTENTS

Preface

Acknowledgments

About the Author

SAP FI Organizational Structure

Chapter 1   Organizational Units and Basic Settings

1.  What is an enterprise structure in SAP?

2.  What are organizational units in SAP?

3.  What organizational units must be defined in SAP FI?

4.  What is a company?

5.  What is a company code and how is it different from a company?

6.  What needs to be done if you define a company code by a copy function?

7.  How do you create a new company code from scratch?

8.  How do you change the company code key?

9.  What are all the important global parameters for a company code?

10.  Can you assign more than one company code to a company?

11.  What is a business area?

12.  How do you enable Business Area Financial Statements (FS)?

13.  What precautions should you take when you enable Business Area FS?

14.  Can you derive a business area by not assigning one in a posting?

15.  How do you post cross-company code business area postings?

16.  What is a consolidation business area?

17.  What is a credit control area?

18.  What is a functional area?

19.  What settings are required for a functional area?

20.  What does the ‘Financial Management (FM) area do?

21.  What is a segment?

22.  What is the difference between a business segment and a geographical segment?

23.  What is a profit center?

24.  What are two prerequisites for defining a profit center?

25.  How can you ensure data consistency between the profit center and other areas?

26.  Can you create a profit center by copying a cost center?

27.  What are a fiscal year and a fiscal year variant?

28.  How do you assign a fiscal year variant to a company code?

29.  What is a posting period?

30.  How does the system identify a posting period?

31.  What happens when you post to, for example, the year 2008 when you are in 2009?

32.  What is the opening /closing of a posting periods?

33.  What is a posting period variant?

34.  Can you selectively open and close accounts?

35.  Why is it not possible to post to a customer a/c in a previously closed period?

36.  Can you open a posting period only for a particular user?

37.  What is a special period? When is it used?

38.  What is the maximum number of posting periods that can be in SAP?

39.  What is a special purpose ledger?

40.  What variations are possible in defining a fiscal year?

41.  What is the year shift/displacement in a fiscal year?

42.  Can you have non-calendar months as periods in a non-calendar fiscal year?

43.  What is a year-dependent fiscal year?

44.  What precautions do you need to take when defining a shortened fiscal year?

45.  When might you need a shortened fiscal year?

46.  How do you open a new fiscal year in the system?

47.  How do you carry forward the account balances?

48.  How does carry-forward happen in SAP?

49.  Is there a prerequisite for carry-forward activity?

50.  How does SAP adjust the carry-forward balance in a new year when you post to a previous year(s)?

51.  How do you correct carry-forward balances if you need to change a G/L classification?

52.  Can you rerun the carry-forward program for a particular G/L account?

53.  In what currency are balances carried forward?

54.  How many retained earnings accounts can be defined?

55.  How do you set up only one retained earnings account?

56.  How do you maintain currency in SAP?

57.  What is local currency?

58.  What is parallel currency?

59.  What do you need to know when ledgers are maintained in parallel currencies?

60.  What is group currency?

61.  What is a hard currency?

62.  What is global company code currency?

63.  What is account currency?

64.  What is reference currency?

65.  What two options can be used to set upaccount currency?

66.  What are all the prerequisites for posting in a foreign currency?

67.  How are exchange rates maintained in SAP?

68.  What is an exchange rate type?

69.  What is a translation factor?

70.  Is there an easy way to maintain exchange rates in SAP?

71.  What is an exchange rate spread?

72.  How are direct and indirect quotations used?

73.  How are taxes handled in SAP?

74.  At how many levels can taxes be handled in SAP?

75.  How is tax calculation structured in SAP?

76.  What is a tax procedure?

77.  How are taxes calculated in SAP?

78.  What configurations are required for taxes in SAP?

79.  What is a tax jurisdiction code?

80.  What is withholding tax in SAP?

81.  What is the difference between withholding tax and extended withholding tax (EWT)?

82.  How do you switch from classic withholding tax to extended withholding tax?

83.  What are tax reports in SAP?

84.  What is a document in SAP?

85.  What is a document header?

86.  What is a document type?

87.  How do you configure the document types when you use New G/L?

88.  How is account type connected to document type?

89.  What are net postings?

90.  What are the various reference methods?

91.  What is a document change rule?

92.  What is a line item?

93.  Which business transactions for which system can generate the line items?

94.  What is a document overview?

95.  What are the document number ranges in SAP?

96.  How do you change the number ranges?

97.  Can you delete a number range?

98.  Do you need to change the validity of a number range?

99.  How does the system populate the default values for a document?

100.  What are the editing options in a document entry?

101.  What are holding and setting data?

102.  What is the difference between parking and holding documents?

103.  What is simulating documents?

104.  What is the account assignment model in SAP?

105.  What is a recurring entry document?

106.  When will you use a sample document?

107.  What is a line layout variant?

108.  What functions can be used for line item display?

109.  Can you change documents in SAP?

110.  What is mass changes to line items?

111.  What is clearing?

112.  What is reversal of documents in SAP?

113.  What is negative posting?

114.  What is fast entry?

115.  What are control totals in SAP?

116.  How are master data different from transaction data?

117.  Can you post an accounts document if credit is not equal to debit?

118.  What is a posting key?

119.  What is the schedule manager?

120.  How you can use the schedule manager in SAP?

121.  What are the advantages of a multilevel worklist in the schedule manager?

Chapter 2: General Ledger (FI-G/L)

1.  What is a chart of accounts?

2.  What are the major components of a chart of accounts?

3.  What is an operating chart of accounts?

4.  What is the difference between a group chart of accounts and an operating chart of accounts?

5.  What is a country chart of accounts? Why do you need one?

6.  Can one chart of accounts be assigned to several company codes?

7.  How do you create G/L account master data?

8.  What is collective processing of G/L accounts?

9.  What is individual processing of G/L accounts?

10.  Can you change an existing balance sheet G/L account to a P&L account?

11.  Can you change the tax category in a G/L master?

12.  What is an account group?

13.  What is a screen layout?

14.  What is a field status group?

15.  What is only balances in local currency?

16.  What is line item display?

17.  What is archiving? How is it different from deleting?

18.  When do you block an account?

19.  What are intercompany postings in SAP?

20.  Can you manually clear the open items? When?

21.  How do you perform period closing in SAP?

22.  What is preclosing?

23.  What is financial closing?

24.  What is a financial statement version?

25.  What items are required in a financial statement version?

26.  How can you make sure the correct balances are in a financial statement version?

27.  How do you do annual closing in SAP?

28.  What is managerial closing?

2.1.  New General Ledger Accounting

29.  Why did SAP introduce new general ledger accounting?

30.  What are the technical advantages of using New G/L?

31.  What are the business advantages of using New G/L?

32.  What are all the features of New G/L?

33.  What is the ledger concept in New G/L?

34.  What is the leading ledger in New G/L?

35.  What are the two views in New G/L?

36.  Is it necessary for a client to use only New G/L?

37.  Why do you need to activate New G/L in the system?

38.  When do you deactivate updates to Classic G/L in the system?

39.  What new tables are included in New G/L?

40.  What is the major difference between FAGLFLEXA and FAGLFLEXT?

41.  How do you map tables between Classic and New G/L?

42.  What are the segments in New G/L accounting?

43.  How many segments can you have in Table FAGLFLEXT?

44.  How does the BW data source like FAGLXX replace GLT0 in New G/L?

45.  Can a totals table be used to manage both line items and totals?

46.  How do you enhance and bring in additional fields to a totals table?

47.  What is the customer field enhancement in New G/L?

48.  What is document splitting in New G/L?

49.  What are the two types of document splitting in New G/L?

50.  How do you do document splitting during document creation in New G/L?

51.  How do you do document splitting at accounting interface?

52.  How is document splitting in New G/L different from splitting in SAP R/3 FI-SL?

53.  How does profit center/segment splitting occur for B/S-only entries?

54.  How does document splitting work for residual postings?

55.  What happens if you activate/define “Define Splitting Characteristics for CO” in IMG?

56.  Can a segment assignment (via the profit center) be overridden on an FI posting?

57.  What is the zero balance switch in document splitting?

58.  What is the mandatory field switch in document splitting?

59.  Can you selectively deactivate document splitting in a few company codes?

60.  How has profit center accounting been mapped to New G/L?

61.  What is extended document splitting?

62.  What are the various methods to achieve fast closing?

63.  How do you eliminate reconciliation ledger postings?

64.  How do you transfer CO documents retrospectively?

65.  How do you eliminate P&L/balance sheet adjustments by online splitting?

66.  How do you eliminate transfer payables/receivables to PCA by segment reporting?

67.  How do you eliminate PCA allocations by using New G/L allocations?

68.  What is a Closing Cockpit?

69.  How do you use the Closing Cockpit?

Chapter 3: Accounts Payable and (FI-A/P)/Accounts Receivable (FI-A/R)

1.  What is a customer?

2.  What are customer/vendor master records?

3.  What are one-time accounts?

4.  What is an alternate payee?

5.  How is a trading partner used?

6.  What is blocking a customer account?

7.  Can you archive a customer master record immediately?

8.  Can you post to a customer account that is marked for deletion?

9.  Can you assign a customer/vendor master record to a business area?

10.  What is tolerance in transaction processing?

11.  What is dual control in master records?

12.  What is a sales cycle in SAP?

13.  What is automatic account assignment in SD?

14.  What is account determination in SD?

15.  What is credit management in SAP?

16.  What is the credit management process in SAP?

17.  What is a credit check?

18.  What is the difference between a static credit check and a dynamic check?

19.  What reports are in credit management?

20.  What is the difference between a partial payment and a residual payment?

21.  What is a payment advice?

22.  How do reason codes help in incoming payment processing?

23.  What is dunning in SAP?

24.  What is a dunning procedure?

25.  What is a dunning area?

26.  What is the dunning process?

27.  Can you dun customers across clients in a single dunning run?

28.  What differentiates one dunning level from another?

29.  How many dunning levels can be defined?

30.  What is an accounts payable submodule?

31.  What documents result from procurement processes?

32.  What is a purchase cycle?

33.  What is a purchase requisition?

34.  What is a request for quotation (RFQ)?

35.  What is an outline agreement?

36.  What is a contract?

37.  What is a release order?

38.  What is a scheduling agreement?

39.  What is a quotation?

40.  What is a purchase order?

41.  What is a PO history?

42.  Will an FI document be created during a purchase order?

43.  What is FI-MM integration.

44.  What happens when you post a goods receipt?

45.  What is Invoice Verification (IV) in SAP?

46.  What do you do with the tax when you post an invoice?

47.  What variances are in invoice verification?

48.  What is the payment program in SAP?

49.  What settings are required for controlling the payment program in SAP?

50.  Where do you maintain the specifications for controlling the payment program?

51.  What are the prerequisites for running the payment program?

52.  How do you configure the payment program?

53.  What is a sending company code?

54.  How do you configure sending and paying company codes for the payment program?

55.  What is a payment method?

56.  What payment methods are normally available in SAP?

57.  What is payment methods in country for the payment program?

58.  How do you configure payment methods in company code?

59.  What is payment method selection by the payment program?

60.  What is optimization by bank groups?

61.  What is bank optimization by postal code?

62.  When do you use the payment per due date grouping option?

63.  What is bank determination for the payment program?

64.  What are value dates?

65.  How do you configure available amounts?

66.  How do you execute the payment program?

67.  How does the payment program determine the house bank for payment?

68.  Can the payment program determine the check cashing time for value dating?

69.  What is local payment?

70.  What factors influence when the payment program pays an open item?

71.  How do you arrive at an appropriate cash discount strategy for payments?

72.  Can you pay a vendor in a currency other than the invoice currency?

73.  What is a payment block?

74.  How do you release blocked invoices for payment?

75.  What is a Payment Medium Workbench (PMW)?

76.  What is an account assignment category?

77.  What is a credit memo?

78.  What are special G/L transactions?

79.  What is the difference between a free offsetting entry and a statistical posting?

80.  What is a noted item?

81.  What is A/R pledging?

82.  What is assigning documents to customers?

83.  What are vendor/customer evaluations in financial information systems?

84.  When do you use a due date breakdown analysis for customers/vendors?

85.  What is DSO analysis?

86.  What do you do before posting a document in A/R and A/P?

87.  What are the options for calculating interest on customer/vendor accounts?

88.  What fields are used for arrear interest calculations in the customer/vendor master?

Chapter 4: Bank Accounting (Fi-Bl)

1.  What are the features of Bank Accounting in SAP?

2.  What is a bank directory?

3.  How do you create a bank directory?

4.  What is a house bank?

5.  How do you distribute the bank master data?

6.  What is lockbox processing?

7.  What are the important control parameters for lockbox processing?

8.  What do you do if the file formats are not exactly the same as BAI and BAI2?

9.  How does the lockbox program identify the customer?

10.  What are the posting data for a lockbox?

11.  What is a lockbox for your house bank?

12.  What is IBAN?

13.  How do you configure the checks for bank master data?

14.  What is a repetitive code in bank accounting?

15.  What is an intermediate bank?

16.  What is a bank chain?

17.  How is the bank chain used during a payment run?

18.  How do you handle cashed checks?

19.  What is electronic check deposit?

20.  What is manual check deposit?

21.  What is the main function of an Electronic Bank Statement (EBS)?

22.  What information is on an Electronic Bank Statement (EBS)?

23.  What are the formats of an Electronic Bank Statement (EBS)?

24.  What problems might you encounter when using Electronic Bank Statements (EBS)? How you can overcome them?

25.  What is an external transaction in an Electronic Bank Statement (EBS)?

26.  What is a posting rule in an Electronic Bank Statement (EBS)?

27.  What do plus (+) and minus (−) signs mean in posting rules in an Electronic Bank Statement (EBS)?

28.  What is a transaction type in an Electronic Bank Statement (EBS)?

29.  What is a posting area in an Electronic Bank Statement (EBS) configuration?

30.  How do you configure the global settings for an Electronic Bank Statement (EBS)?

31.  What is the posting/clearing flow in an Electronic Bank Statement (EBS)?

32.  What is a currency class?

33.  Why must planning types be assigned to certain transactions?

34.  What is a payment request?

Chapter 5: Asset Accounting (FI-AA)

1.  What is Asset Accounting (FI-AA)?

2.  What is the lean implementation in FI-AA?

3.  What are the kinds of assets in SAP?

4.  What are complex assets and asset sub-numbers?

5.  What is a group asset? When you will use this?

6.  What is asset super number in SAP?

7.  What is chart of depreciation? How is it different from a chart of accounts?

8.  How do you create an asset accounting company code?

9.  What is depreciation? What are the various types of depreciation?

10.  What is planned depreciation? How it is different from unplanned depreciation?

11.  What are the three types of depreciation in SAP?

12.  What is the depreciation area?

13.  What is depreciation area type?

14.  What is a derived depreciation area?

15.  What is the function of depreciation areas?

16.  How do you set up depreciation area postings from FI-AA to FI?

17.  What is an asset class?

18.  Why do you need asset classes?

19.  What is an asset class catalogue?

20.  Can you create asset classes automatically?

21.  What is control information in an asset class?

22.  Can you delete an asset class?

23.  What is an index series?

24.  How do you calculate replacement value without an index series?

25.  What is an asset value date?

26.  What is an asset master?

27.  What kinds of data are maintained in an asset master?

28.  What is the maintenance level?

29.  When do you use asset sub-numbers?

30.  How do you create an asset master?

31.  Can you create multiple assets in a single transaction?

32.  What time-dependent data are in the asset master?

33.  How do you make changes to an asset master?

34.  Why it is necessary to block an asset master record?

35.  What is deactivation of an asset?

36.  How do you delete an asset?

37.  What is an asset transaction type in FI-AA?

38.  What is an asset acquisition?

39.  What data are automatically set in the asset master during initial acquisition?

40.  Can you post asset acquisition in two steps (or two departments)?

41.  What are the implications of valued/non-valued transactions in FI-AA?

42.  What are Assets under Construction (AuC) in SAP?

43.  How do you capitalize AuC in SAP?

44.  What is Low Value Assets (LVA)?

45.  What is an asset transfer in SAP?

46.  What is a transfer variant?

47.  What is asset retirement in FI-AA?

48.  What is scrapping in FI-AA?

49.  How does SAP handle the partial retirement of an asset?

50.  Why is it important to select the right transaction type for retirement?

51.  What is an asset sale with customer?

52.  What are proportional value adjustments in asset retirement?

53.  Is there a special requirement for retiring LVA?

54.  Can you retire several asset sub-numbers simultaneously?

55.  What is mass retirement of assets?

56.  What are work lists?

57.  What are depreciation keys?

58.  What in an internal calculation key?

59.  What is the significance of the depreciation key 0000?

60.  What is periodic processing in FI-AA?

61.  How does the system post imputed interest to CO?

62.  What is a depreciation run in SAP?

63.  What are the steps in a depreciation run?

64.  How does the system calculate the depreciation?

65.  How the system determine the depreciation start date?

66.  What is a repeat run in the depreciation process?

67.  What is restart a depreciation run?

68.  What is depreciation simulation?

69.  Can you select “direct FI posting” for a depreciation run?

70.  Does the system post individual documents when you run RABUCH00?

71.  What document number range do you use for automatic depreciation postings?

72.  What is the difference between smoothing and catch-up?

73.  What is the transfer of legacy asset data to SAP?

74.  What is automatic transfer of old assets?

75.  What are the three methods of old asset data transfer based on the number of assets?

76.  With any of the old asset transfer methods, will G/L in FI be updated?

77.  What is the asset transfer date?

78.  What data are transferred in the year-end transfer and the sub-annual transfer?

79.  What are the two ways to transfer depreciation posted in the current year?

80.  What transfers/postings are allowed in the different SAP environments?

81.  What is mass change? How do you do this?

82.  What is the year closing in FI-AA?

83.  What is an asset history sheet?

84.  Can you change the reports in a report tree in FI-AA?

85.  What is the sort version?

86.  What is asset explorer?

87.  What is the production setup in FI-AA?

88.  How does FI-AA integrate with CO in SAP?

Chapter 6: Lease Accounting (FI-LA)

1.  What is SAP Lease Accounting (FI-LA)?

2.  What are the key components of lease accounting?

3.  What is the Lease Accounting Engine (FI-LAE)?

4.  What are the subcomponents of the Lease Accounting Engine (FI-LAE)?

5.  What is the value ID in lease accounting?

6.  How do you manage the leased assets in FI-AA?

7.  What is a leasing type?

8.  What is a classification?

9.  What does the lease accounting engine do in classification?

10.  What are some examples for one-time postings in FI-LAE?

Chapter 7: Travel Management (FI-TV)

1.  What are the implementation considerations for FI-TV?

2.  How do you combine the subcomponents of FI-TV?

3.  How do travel requests support the business processes?

4.  What is travel planning?

5.  How do travel expenses in FI-TV help you in travel management?

6.  How does FI-TV enables global travel policy compliance?

7.  What is travel and expense analytics in SAP Travel Management?

8.  What is the overall process in SAP Travel Management?

9.  What are the roles in SAP FI-TV?

10.  What is the technical setup of the FI-TV application?

11.  What are the advantages and disadvantages of the various technical setups of FI-TV?

12.  How do you select the system infrastructure for FI-TV?

13.  What is the SAP Travel Manager?

14.  What is a travel request?

15.  What personal settings can you make in the Travel Manager?

16.  What is an infocenter?

17.  What is data integration in the Travel Manager?

18.  What two statuses for a travel request are in the Travel Manager?

19.  What is a travel plan?

20.  What is the Planning Manager?

21.  How are travel expenses integrated with the other application areas in SAP?

22.  What are the elements of a trip?

23.  Do you need an employee’s HR master record for entering trips?

24.  What is a personnel mini-master?

25.  What are the mandatory and optional infotypes?

26.  What is the approval process in travel planning?

27.  What is a trip transfer document?

28.  What is a posting run?

29.  Can you cancel a trip that has been posted in accounting?

30.  How do you post the private expenses paid by the company?

31.  What is a Travel Information System?

Chapter 8: SAP FI Tables

Chapter 9: SAP FI Transaction Codes

Transaction Codes

Other SAP FI Transaction Codes

Tables

Figures

PREFACE

As with my first book, SAP FI: Transactions Made Easy, this book is also different from others in this field in providing an enrichment of knowledge in SAP Financial Accounting in an easy and straightforward way.

This book is an expanded and revised edition of my earlier book, SAP FI/CO Demystified, although this book concentrates only on SAP FI (Financial Accounting). Whether or not you consider this a second edition of the earlier book or a first edition, this book presents more information on SAP FI than the previous one.

This book unravels the complexity of the SAP FI application and its component modules through a series of questions and answers (440 to be exact!). The questions are collected, grouped, and explained in a logical way so the reader can progress seamlessly from the basics to the more advanced topics. To help visualize what is covered in a particular question, numerous illustrations are provided in the form of screenshots, diagrams, and examples. The screenshots in particular make it seem as if you are looking at a computer screen showing an SAP FI application!

This book consists of nine chapters:

•  Organization Units and Basic Settings

•  General Ledger Accounting

•  Accounts Payable and Accounts Receivable

•  Bank Accounting

•  Asset Accounting

•  Lease Accounting

•  Travel Management

•  SAP FI Tables

•  SAP FI Transaction Codes

Chapter 1 covers the basics of Financial Accounting. To help understanding of how you need to set up the several organizational elements within FI and their assignments, an organizational map is provided first. Besides the organizational structure, Chapter 1 also discusses most of the basic settings like fiscal year, posting periods, currencies, document types, document number ranges, taxes, and even the SAP Schedule Manager.

Chapter 2 introduces the important aspects of both Classic G/L and New G/L. It takes you from charts of accounts to G/L accounts to the latest in G/L accounting, including document splitting, segment accounting, parallel valuation, closing cockpit, and more.

Chapter 3 covers customer/vendor masters, purchase cycles, terms of payment, payment programs, tolerances, sales cycles, credit management, dunning, and more.

Chapter 4 discusses bank directories, house banks, bank chains, lockbox processing, bank statements (electronic and manual), checks, and more.

Chapter 5 covers types of assets, including assets under construction and low value assets; asset numbering; asset class; asset masters; acquisition; transfers; retirements; scrapping; depreciation; asset history sheets; asset explorers; and more.

Chapter 6 discusses leasing types, classifications, value IDs, lease accounting engines, and more.

Chapter 7 discusses travel requests, travel planning, travel expenses, the entire process flow in travel management, trips, SAP Planning Manager, SAP Travel Manager, technical options of setting up various components of travel management, and more.

Chapters 8 and 9 act as one-stop references. Chapter 8 lists the most important tables in SAP FI. Chapter 9 lists the transaction codes in configuration and others.

Unlike typical alphabetical listings of transaction codes and tables, which are the convention, this book attempts something more functional and useful. This information is arranged in the order in which it is needed, because most of the time you may not know the transaction code or table to look at, but you know the functionality or task for which you are trying to find the information.

So how should you use this book?

The answer is simple.

Read it in any order you want. Pick a chapter and read all the questions, or simply read a question. Then go to the relevant page and see the answer. Use this book as a reference or study guide or just as reading material, but make sure you understand a particular question or concept before moving on to the next one.

All of the 440 questions listed in this book will certainly improve your understanding of the subject, whether it is for job interviews in SAP, especially in Financial Accounting, or just to use the application more efficiently in your current job.

V. Narayanan
December, 2012

ACKNOWLEDGMENTS

A book like this requires a great deal of input from experts so the end product will be accurate and authentic. I have been fortunate enough to have a number of SAP experts serving in various application areas as my friends and well wishers who were more than willing to provide me with helpful tips, clarifications, and reviews in formulating the questions in this book. I am not naming them here for fear that I may inadvertently leave out one or more names. Therefore, instead I extend a very loud “Thanks!” to all of them.

As you will see in this book (rather unusual in a book like this), many screen-shots are provided to make the SAP application easier to understand. My thanks to Mr. Hariharan of Maagnus Infotech for allowing me to use its SAP system to generate these screenshots.

I also thank Mr. Manish Jain of BPB Publishers for encouraging me to write this book.

ABOUT THE AUTHOR

V. Narayanan has more than 25 years of experience in accounting, banking, finance, and information technology. A postgraduate in the sciences, a chartered financial analyst, and a project management professional, he trained in SAP FICO, and he is a practicing SAP FI/CO consultant and project manager. Mr. Narayanan has been instrumental in managing SAP implementations (new, rollouts, upgrades, etc.) for a number of international clients. Experienced in various versions of R/3 as well as mySAP ERP (currently SAP ERP) and new dimension products of SAP, he currently works in SAP consulting for a multinational IT consulting company. He attended Thames Valley University in the United Kingdom and is a professional trainer and visiting faculty member in the areas of ERP, SAP, and banking. He has written several best-selling books on SAP Finance and Controlling.

SAP FINANCIAL
ACCOUNTING (FI)

Before getting into the questions, please look at the Financial Accounting (FI) organization structure in Figure 0.1. When moving through the questions, it is helpful to refer to the layout if you have questions at any point of time. To be successful as an FI or CO consultant, you must have a thorough grasp on this basic fundamental block in SAP FI/CO.

FIGURE 0.1  FI Organizational Structure

The questions are arranged into several areas within FI, including:

•  Organization Units and Basic Settings

•  General Ledger Accounting (FI-G/L)

•  Accounts Payable (FI-A/P) and Accounts Receivable (FI-A/R)

•  Bank Accounting (FI-BL)

•  Asset Accounting (FI-AA)

•  Lease Accounting (FI-LA)

•  Travel Management (FI-TV)

CHAPTER

1

ORGANIZATIONAL UNITS AND BASIC SETTINGS

The questions in this section relate to the basics in SAP Financial Accounting and will help you to understand how to design and define the organizational units, relationships, assignments, and interdependencies among them, as well as the various configuration units/settings like financial year, posting period, chart of accounts, and so on as detailed below:

•  Company

•  Company codes

•  Fiscal year

•  Posting period

•  Currency

•  Exchange rate

•  Tax

1.     WHAT IS AN ENTERPRISE STRUCTURE IN SAP?

The enterprise structure helps you to portray the specific organizational structure of your business in the SAP system. SAP, in its standard version, comes with sample organizational units (for accounting, logistics, human resources, etc.). Do not expect SAP to provide everything that is required for your business, but it is a good idea to try to match the structure provided by SAP with your specific requirements and extend the SAP structures wherever you need more or different units. It is very critical that you define the structure correctly because you will not be able to change these after the business is activated. It is also necessary that you restrict the access to these structures through appropriate authorization profiles. Remember to define only the required structures—nothing more, nothing less!

2.     WHAT ARE ORGANIZATIONAL UNITS IN SAP?

The organizational units in SAP are the elements or structures representing the business functions, and they are used in reporting—for example, Client (across the various modules), Company Code (FI), Controlling Area (CO), Plant (Logistics), Sales Organization (SD), Purchasing Organization (MM), Employee Group (HR), and so on.

3.     WHAT ORGANIZATIONAL UNITS MUST BE DEFINED IN SAP FI?

The various organizational units in SAP FI (Version SAP ERP/ECC6) are:

•  Company (not required)

•  Company Code (mandatory)

•  Business area (mandatory)

•  Consolidation Business Area (mandatory)

•  Functional Area (mandatory)

•  Credit Control Area (mandatory)

•  Functional Management (FM) Area (mandatory)

•  Profit Center (mandatory)

•  Segment (optional)

You will be defining these units under SAP Customizing Implementation Guide>Enterprise Structure>Definition>Financial Accounting (Version SAP ERP/ECC6) (Figure 1.1).

FIGURE 1.1  FI Organizational Units

Transaction Code
SPRO

4.     WHAT IS A COMPANY?

A company in SAP is represented by a 5-character alphanumeric code and usually represents the organizational unit in accounting depicting the business enterprise as per the particular country’s commercial law requirements. A company can include one or more company codes. In SAP, the creation/definition of a company is optional, but the consolidation functions in SAP are based on the company. SAP provides you with the sample company “G00000” with all the foreign key relationships. It is recommended that you keep the preset company ID G00000 if you only require one company. This way, you can reduce the number of tables you need to adjust (Figure 1.2).

FIGURE 1.2  Company and Company Code

FIGURE 1.3  Define a Company

Note that all the company codes for a company must work with the same operational chart of accounts and fiscal year, though the currencies used in each of the company codes can be different (Figure 1.3).

(When you enter the transaction, do not be confused when the screen shows “Change View Internal Trading Partners: Overview.” This is where you define the company.)

Transaction Code
OX15

5.     WHAT IS A COMPANY CODE AND HOW IS IT DIFFERENT FROM A COMPANY?

A company code in SAP is the smallest organizational unit for which you can draw individual financial statements (balance sheets and profit and loss accounts) for your external statutory reporting. It is denoted by a 4-character alphanumeric code. The creation of the company code is mandatory. You need to have at least one company code per client defined in the system for implementing FI. You may, however, define several company codes in a single client.

SAP comes delivered with company code 0001 in clients 000 and 001 for Germany (country code: DE). All country-specific parameters (like payment methods, tax calculation procedures, chart of accounts, etc.) are preset in this company code for this country. In case you want to create a company code for the United States and its legal requirements, you must first run the country installation program in client 001. The country of company code 0001 is then set to “US” (from “DE”), and all country-specific parameters related to it are set to the United States.

You may define a company code by copying from an existing one (copy, delete, check company code option). In fact, SAP recommends this approach (less time consuming than creating new), as this has the advantage that you also copy the existing company code-specific parameters. You may then change certain data in the relevant application.

You may also create the company code (the second option in Figure 1.4) from scratch.

FIGURE 1.4  Options to Define a Company Code

6.     WHAT NEEDS TO BE DONE IF YOU DEFINE A COMPANY CODE BY A COPY FUNCTION?

When you copy an existing company code, all the company code-specific specifications of the source (From Company Code) are copied to your new company code target (To Company Code) (Figure 1.5).

FIGURE 1.5  Define a Company Code (with the “Copy” Function)

Note that the target company code should not have been defined, as the same will be defined automatically during the copying procedure.

So how do you do this?

•  Create the company code using the function “Copy Company Code.”

•  Enter/modify special company code data (name, description, address, and currency) with the function “Edit Company Code Data.”

•  Use the Transaction Code OBY6 to modify any other global parameters that need to be different from the source company code.

Transaction Code
EC01

7.     HOW DO YOU CREATE A NEW COMPANY CODE FROM SCRATCH?

You can use the function “Edit Company Code Data” to create a company code from scratch (Figure 1.6). In this case, the company code “global data” are not copied.

FIGURE 1.6  Define a Company Code (with the ‘Edit Company Code Data’Function)

Once you create the new company code using this option, then you need to maintain the global parameters using the Transaction Code OBY6.

8.     HOW DO YOU CHANGE THE COMPANY CODE KEY?

Use the “Replace” function in the Transaction Code EC01 to change the company code key. But this is only possible if no postings have been made in the company code that are to be replaced with the new company code key.

9.     WHAT ARE ALL THE IMPORTANT GLOBAL PARAMETERS FOR A COMPANY CODE?

The global parameters for a company code are divided into two sections:

•  Accounting Organization

The parameters under this section include the chart of accounts, the credit control area, the FM area, the company, the fiscal year variant, and more (Figure 1.7). This is also the area where you will normally set the company code as “productive” before activating the system.

FIGURE 1.7  Accounting Organization Parameters under Global Parameters

•  Processing Parameters

The processing parameters include settings like field status variant, fiscal period variant, whether you want the system to propose the fiscal year during document entry, the company code–controlling area assignment, the calculation base for discounts/taxes, whether you will need financial statements per business area, the maximum exchange rate deviation allowed, and more (Figure 1.8).

FIGURE 1.8  Processing Parameters under Global Parameters

Transaction Code
OBY6

10.   CAN YOU ASSIGN MORE THAN ONE COMPANY CODE TO A COMPANY?

Yes, you can assign more than one company code to a company. But all such company codes should use the same chart of accounts and the same financial year, even though they all can have different local currencies.

11.   WHAT IS A BUSINESS AREA?

Business areas correspond to specific business segments of a company and may cut across different company codes (for example, product lines) (Figure 1.9). They can also represent different responsibility areas (for example, branch units). You can create financial statements for business areas that can be used for various internal reporting purposes.

FIGURE 1.9  Business Area

Transaction Code
OX03

12.   HOW DO YOU ENABLE BUSINESS AREA FINANCIAL STATEMENTS (FS)?

There are two ways you can enable the financial statements for the business areas:

•  Enabling the business area financial statements in the global parameters of company codes (one by one for each of the company codes) (Figure 1.10).

FIGURE 1.10  Enable Business Area Financial Statements

Transaction Code
OBY6

•  Enabling the business area financial statements for more than one company code at the same time (Figure 1.11).

FIGURE 1.11  Enable Business Area Financial Statements

Transaction Code
OB65

When you set this indicator, the business area field is always ready for input (when documents are posted), independent of the field control of the posting keys and of the accounts.

13.   WHAT PRECAUTIONS SHOULD YOU TAKE WHEN YOU ENABLE BUSINESS AREA FS?

You should only set the indicator for the business area field if you work with all the financial statements (this way, the business area field is always ready for input irrespective of your settings if field control for posting keys/accounts). If you only work with business areas in a few financial statement areas (for example, P&L), then you should not set the indicator. Instead, you should make the business area field ready for input for the business area–relevant accounts using the field control of the accounts/posting keys.

14.   CAN YOU DERIVE A BUSINESS AREA BY NOT ASSIGNING ONE IN A POSTING?

Yes. The business area can also be derived from other account assignments—for example, cost center. But to do this, you need to define the business area in the master record of that particular cost center.

15.   HOW DO YOU POST CROSS-COMPANY CODE BUSINESS AREA POSTINGS?

By using a cross-company code transaction, you can post to different business areas cutting across various company codes. Any number of businessarea–company code combinations are possible.

16.   WHAT IS A CONSOLIDATION BUSINESS AREA?

A consolidation business area, identified by a 4-character ID, is an organizational unit within accounting corresponding to a limited area of operations or responsibilities (representing a central business segment within a business organization) from a consolidation point of view. Companies and consolidation business areas together make up the consolidation units that are the basis for business area consolidation. Execute the functions for consolidating business areas based on consolidation business areas.

Transaction Code
OCC1

17.   WHAT IS A CREDIT CONTROL AREA?

In SAP, the credit control area helps in administering the credit management functions relating to the customers (Figure 1.12). This organizational unit is used both in SD and FI-AR (accounts receivable) modules. By definition, you can have more than one credit control area in a client, and each company code is assigned exactly to one credit control area. However, it is true that you can attach many company codes to the same credit control area. The credit limits within the same credit control area are to be defined in the same currency. Credit information is made available per customer in the credit control area.

FIGURE 1.12  Credit Control Area: the Possibilities

SAP comes delivered with the sample credit control area “0001” (Figure 1.13).

Transaction Code
OB45

FIGURE 1.13  Credit Control Area

18.   WHAT IS A FUNCTIONAL AREA?

A functional area in SAP is an organizational unit in accounting that is used to classify the expenses of the organization by functions like production, sales, marketing, administration, and so on. This classification is required for cost of sales accounting (COS). (Organizations that use funds management do not normally use cost of sales accounting. In such cases, the functional area can be used as an additional account assignment.)

To use the functional area in your organization, you must make the appropriate settings for the functional area in the customizing of Financial Accounting. You also need to activate the functional area in the customizing of funds management government. In addition, you must make the functional area ready for input from when transactions are put through across application areas.

19.   WHAT SETTINGS ARE REQUIRED FOR A FUNCTIONAL AREA?

The settings are to be done in the customizing of cost of sales accounting, as the functional area is also used for cost of sales accounting in Financial Accounting.

1.  Define the functional area (Figure 1.14).

SAP Customizing Implementation Guide > Enterprise Structure > Definition > Financial Accounting > Define Functional Area You may also use the following menu path to define the functional area:
SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Fields > Standard Fields > Functional Area for Cost of Sales Accounting > Define Functional Area

FIGURE 1.14  Functional Area

Transaction Code
OKBD

2.  Activate the cost of sales accounting for preparation (Figure 1.15).

Use this menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Fields > Standard Fields > Functional Area for Cost of Sales Accounting > Activate Cost of Sales Accounting for Preparation

FIGURE 1.15  Activate COS Accounting for Preparation

This is to make the functional area field ready for input in the master data for G/L accounts, cost types, and some of the CO account assignment objects. Select In preparation from the drop-down list (there will be three options: Inactive, In preparation, and Active). No function area is derived for postings in this company code.

3.  Define the derivation procedure for the functional area.

SAP recommends that you select the setting FA on the entry screen in order to ensure that the functional area can also be derived for commitments postings. The derivation of the functional area takes place in accordance with the rules described under “Rules” for deriving the functional area for postings. You should also be aware that you cannot define a functional area in the master record of a balance sheet account.

4.  Enter the functional area in the master data (of the specific objects).

If you use funds management integrated with Controlling, you should ensure that the functional area can always be derived from this master data. In this situation, you should avoid using substitution. Use this menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Fields > Standard Fields > Functional Area for Cost of Sales Accounting > Enter Functional Area > Enter Functional Area in G/L Account Master Data
Enter Functional Area in Cost Element Master Data
Enter Functional Area in Cost Center Categories
Enter Functional Area in Request Type

5.  Define a substitution for deriving the functional area.

You should only execute this step if your requirements for the derivation of the functional area are not met by entering the functional area in the master data of some of the account assignment objects. (You can find the steps under setup substitution for cost of sales accounting.)

6.  Activate the cost of sales accounting for your company codes (Figure 1.16).

Use this menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Ledger > Activate Cost of Sales Accounting

FIGURE 1.16  COS Activated

Once activated, when you post to these company codes, the functional areas are derived and updated.

20.   WHAT DOES THE FINANCIAL MANAGEMENT (FM) AREA DO?

A financial management area, denoted by a 4-character ID, is an organizational unit within accounting through which you can structure the business organization from the perspective of cash budget management and funds management (Figure 1.17). However, to take advantage of the high degree of integration in the SAP system, you must link these FM areas with organization units from other applications. For example, if you assign an FI document to a funds management object, such as a commitment item or funds center, the system has to determine an FM area so it can record the data in funds management. The FM area is taken from the company code when you assign a company code to an FM area. More than one company code can be assigned to an FM area. SAP provides you with the FM area 0001 in the standard system.

NOTE

To define the currency for each of the FM areas to define in the system, it is NOT necessary for this currency and the company code currency to be the same.

Transaction Code
OF01

FIGURE 1.17  Functional Management (FM) Area

21.   WHAT IS A SEGMENT?

A segment in SAP is a division of a company for which you can create financial statements for external reporting. The accounting principles US GAAP and IFRS require companies to perform segment reporting. US GAAP requires a virtually complete balance sheet at the segment level for segment reporting (essentially everything apart from stockholders’ equity). The segment is defined as a subarea of a company with activities that generate expenses and revenues, with an operating result that is regularly used by management for profit assessment and resource allocation purposes, and for which separate financial data are available.

Once you define a segment, it is then possible when you define the profit center to enter an associated segment in the master record of that profit center. If no segment is specified manually during posting (only possible for transactions in FI), the segment is determined from the master record of the profit center that can be assigned manually or derived.

Note that the document splitting procedure (made available with the introduction of new G/L) is the prerequisite for creating financial statements at any time for the segment dimension.

Use this menu path to define a segment: SAP Customizing Implementation Guide > Enterprise Structure > Definition > Define Segment

22.   WHAT IS THE DIFFERENCE BETWEEN A BUSINESS SEGMENT AND A GEOGRAPHICAL SEGMENT?

IAS requires for segment reporting primary and secondary segmentation, which have different reporting depths. A distinction is made between a business segment and a geographical segment.

A business segment is a distinguishable subactivity of a company that relates to the manufacturing of a product or the provision of a service and that has risks and revenues that differ from those in other business segments.

A geographical segment, on the other hand, is a distinguishable subactivity of a company that relates to the manufacturing of a product or the provision of a service within a specific field of business, with the risks and revenues of a geographical segment different from the subactivities in other fields of business.

23.   WHAT IS A PROFIT CENTER?

In SAP, a profit center is an organizational unit in accounting that reflects a management-oriented structure of the organization for the purpose of internal control through which you can analyze operating results for profit centers using either the cost-of-sales or the period accounting approach (Figure 1.18). It is also possible to use the profit center as an investment center by calculating the fixed capital.

Note that the profit center accounting (PCA) at the profit center level is based on costs and revenues, which are assigned statistically by multiple parallel updating to all logistical activities and other allocations of relevance for a profit center. Every profit center is assigned to the organizational unit Controlling (CO) area. This assignment is necessary because PCA displays values in G/L accounts.

Transaction Code
KE51

Use this menu path, SAP Customizing Implementation Guide > Enterprise Structure > Definition > Define Profit Center

FIGURE 1.18  Profit Center

(In the earlier versions, SAP R/3 to 4.70, the profit center did not have a place in “definition” under “enterprise structure.” But with the introduction of mySAP ERP, this now forms a part of the enterprise structure.)

24.   WHAT ARE TWO PREREQUISITES FOR DEFINING A PROFIT CENTER?

To define a profit center, the following prerequisites are required:

•  You should have defined the Controlling (CO) area. The system will prompt you to enter or select the desired Controlling area before you proceed to define the profit center.

•  The standard hierarchy for the Controlling area should also have been created either directly or via the enterprise organization.

25.   HOW CAN YOU ENSURE DATA CONSISTENCY BETWEEN THE PROFIT CENTER AND OTHER AREAS?

To ensure that your data in profit center accounting (PCA) are consistent with those in other areas, you need to assign each profit center to the standard hierarchy in your Controlling (CO) area. The standard hierarchy is used in the information system, allocations, and various planning functions. It is also possible to assign your profit centers to alternative hierarchical structures that are completely independent of the standard hierarchy. These structures are called profit center groups.

26.   CAN YOU CREATE A PROFIT CENTER BY COPYING A COST CENTER?

The answer is yes. If the profit centers in your organization are closely linked to your cost centers, you can then simply copy your cost center master data to create your profit centers.

27.   WHAT ARE A FISCAL YEAR AND A FISCAL YEAR VARIANT?

A fiscal year is the accounting period, which normally spreads over 12 months (Figure 1.19). The financial statements are drawn for a fiscal year. In SAP, the fiscal year is defined using a fiscal year variant.

All calendar year fiscal year variants, in standard SAP, are denoted usually as K1, K2, and so on.

FIGURE 1.19  Fiscal Year Variant (Calendar Year)

It is also possible for the fiscal year to be shorter than 12 months, and this is called a shortened fiscal year (Figure 1.20).

FIGURE 1.20  Shortened Fiscal Year Variant

The fiscal year may or may not correspond to the calendar year. In the standard SAP system, the non-calendar fiscal year variants are denoted by V1, V2, and so on (Figure 1.21).

FIGURE 1.21  Fiscal Year Variant (Non-Calendar Year)

Transaction Code
OB29

28.   HOW DO YOU ASSIGN A FISCAL YEAR VARIANT TO A COMPANY CODE?

One fiscal year variant can be assigned to one or more company codes (Figure 1.22).

FIGURE 1.22  Assign Fiscal Year Variant to a Company Code

Transaction Code
OB37

29.   WHAT IS A POSTING PERIOD?

In SAP, a fiscal year is divided into various posting periods, with start and end dates defined for each of these periods (Figure 1.23). Any document posting is possible only when the posting periods are in place in the system. Normally there will be 12 posting periods. A posting period consists of a month and year.

FIGURE 1.23  Posting Periods

30.   HOW DOES THE SYSTEM IDENTIFY A POSTING PERIOD?

Based on the posting date entered into the system while posting a document, the system automatically determines the period by looking at the document date and the year. For this, you should have properly defined the fiscal year variant.

31.   WHAT HAPPENS WHEN YOU POST TO, FOR EXAMPLE, THE YEAR 2008 WHEN YOU ARE IN 2009?

First of all, to post a document relating to a previous year—say, 2008 when you are in 2009—the relevant posting period should be open in the system. When such a posting is done, the system makes some adjustments on the background:

•  The carry-forward balances of the current year, already done, are updated in case the posting is affecting balance sheet items.

•  If the posting is going to affect the profit and loss accounts, then the system adjusts the profit or loss balances that are carried forward to the retained earnings account(s).

32.   WHAT IS THE OPENING /CLOSING OF A POSTING PERIODS?

Postings in SAP are controlled by opening or closing of posting periods. Normally, the current posting period is open for document posting and all other periods are closed. At the end of the period (month), this posting period is closed and the new one is opened for postings. This way, it provides better control.

It is, however, possible to keep all the periods or select periods open.

Transaction Code
OB52

33.   WHAT IS A POSTING PERIOD VARIANT?

A posting period variant is useful in opening and closing posting periods across many company codes all at one time. Define a posting period variant and assign the same to various company codes. Because the posting period variant is cross–company code, it is easy to open and close posting periods. Instead of doing it individually for different company codes, you just need to open or close the posting period variant.

34.   CAN YOU SELECTIVELY OPEN AND CLOSE ACCOUNTS?

Yes, you can. It is possible to selectively control the opening and closing for various types of accounts. Usually, a “+” is mentioned in the topmost entry (under column “A”), indicating that all the accounts types are allowed for posting. Now, against the G/L(S) accounts specify the period that needs to be open. This ensures that all the account types are open for the current period, indicated by a “+, ” and only the G/L accounts are open for the previous period.

Besides select account types, select accounts within an account type also can be opened or closed for a specific period.

35.   WHY IS IT NOT POSSIBLE TO POST TO A CUSTOMER A/C IN A PREVIOUSLY CLOSED PERIOD?

When you want to selectively close or open the posting period of some accounts (account range), as long as you are doing it for G/L accounts, there is no problem. But if it is a subledger account (like the customer), the same has to be achieved via opening or closing the account interval of the reconciliation account of that account type.

36.   CAN YOU OPEN A POSTING PERIOD ONLY FOR A PARTICULAR USER?

Yes, you can. SAP allows you to open or close the posting period only for specific users. This can be achieved by maintaining an Authorization Group (AuGr) (Figure 1.24).

FIGURE 1.24  Posting Control through an Authorization Group

37.   WHAT IS A SPECIAL PERIOD? WHEN IS IT USED?

Besides the normal posting periods, SAP makes it possible to define a maximum of 4 additional posting periods, which are known as special periods because they are used for year-end closing activities. This is achieved by dividing the last posting period into more than one period. However, all the postings into these special periods should fall within the last posting period.

The special periods cannot be determined automatically by the system based on the posting date of the document (Figure 1.25). The special period must be manually entered into the “posting period” field in the document header.

FIGURE 1.25  Special Periods

38.   WHAT IS THE MAXIMUM NUMBER OF POSTING PERIODS THAT CAN BE IN SAP?

Under G/L accounting, you can have up to 16 posting periods (12 regular + 4 special periods). However, you can have up to a maximum of 366 posting periods in the case of special purpose ledgers.

39.   WHAT IS A SPECIAL PURPOSE LEDGER?

‘Special Purpose Ledgers’ (FI-SL) are used in reporting. These are all basically user-defined ledgers that can be maintained either as G/L or subsidiary ones with various account assignment objects (with SAP-dimensions like cost center, business area, profit center, etc., or customer-defined dimensions like region, area, etc.).

Once defined, this functionality helps you to report at various levels. Ideally you collect the information, combine it, and create the totals. This is something like an additional reporting feature, and using this feature has no effect on the regular functionalities of SAP.

40.   WHAT VARIATIONS ARE POSSIBLE IN DEFINING A FISCAL YEAR?

•  Fiscal Year = Calendar Year

The fiscal year starts on January 1 (1-Jan), and there are 12 posting periods. The posting periods correspond to the calendar months. It is not necessary to define each of the posting periods (Table 1.1).

TABLE 1.1  Calendar Year Fiscal Year

Posting Period

Start Date

End Date

1

1-Jan

31-Jan

2

1-Feb

28/29 Feb

3

1-Mar

31-Mar

4

1-Apr

30-Apr

5

1-May

31-May

6

1-Jun

30-Jun

7

1-Jul

31-Jul

8

1-Aug

31-Aug

9

1-Sep

30-Sep

10

1-Oct

31-Oct

11

1-Nov

30-Nov

12

1-Dec

31-Dec

•  The fiscal year is NOT the same as the calendar year.

In this case, you need to specify (1) how many posting periods you want and (2) how the system should derive the posting period. Because the posting period does not correspond to the calendar month, the start and end dates of each of the posting periods need to be maintained.

41.   WHAT IS THE YEAR SHIFT/DISPLACEMENT IN A FISCAL YEAR?

When the fiscal year is not the same as the calendar year, you must define a displacement factor for each of the posting periods to correctly identify the number of the posting period (Figure 1.26).

FIGURE 1.26  Year Shift/Displacement in Fiscal Year Variant

For example, consider the fiscal year variant V3. The fiscal year starts on April 1 and ends on March 31 of the next calendar year. The displacement factor or year shift from April to December is “0,” and for January to March, it will be “−1.” By defining it this way, the system is able to recognize the correct posting period. A posting made on January 25, 2009 will then be interpreted as the 10th posting period in fiscal year 2008, even though it is in the 1st calendar month of the year 2009.

42.   CAN YOU HAVE NON-CALENDAR MONTHS AS PERIODS IN A NONCALENDAR FISCAL YEAR?

Yes, you can. The noncalendar fiscal year can correspond to either calendar months or noncalendar months.

In the case of noncalendar months as the posting periods, you need to specify the start and end dates of these posting periods. Consider a fiscal year that starts on April 16, 2008 and ends on April 15, 2009. Here, the posting period-1 starts on April 16 and ends on May 15, and so on. Note that the posting period-9 will have two displacements (0 and -1), as shown in Table 1.2.

TABLE 1.2  Non-Calendar Year Fiscal Year

As a result, postings made on December 27, 2008, and on January 14, 2009, are both correctly identified as the postings corresponding to the period-9.

43.   WHAT IS A YEAR-DEPENDENT FISCAL YEAR?

A calendar year fiscal variant, when defined as year-dependent, is relevant and valid only for that year.

44.   WHAT PRECAUTIONS DO YOU NEED TO TAKE WHEN DEFINING A SHORTENED FISCAL YEAR?

Note that the shortened fiscal year is ALWAYS year-dependent. This has to be followed or preceded by a full fiscal year (12 months). Both the shortened and the full fiscal years, in this case, have to be defined using a single fiscal year variant.

45.   WHEN MIGHT YOU NEED A SHORTENED FISCAL YEAR?

A shortened fiscal year is one that contains fewer than 12 months. This kind of fiscal year is required (a) when you are in the process of setting up of a company, or (b) when you switch over from one fiscal year (say, calendar year) to another type of fiscal year (non-calendar).

46.   HOW DO YOU OPEN A NEW FISCAL YEAR IN THE SYSTEM?

You do not need to open the new fiscal year as a separate activity. Once you make a posting into the new fiscal year, that fiscal year is automatically opened. Or the new fiscal year is automatically opened when you run the balance carry-forward program.

However, you should have:

•  The relevant posting period already opened in the new fiscal year.

•  Completed the document number range assignment if you are following a year-dependent number range assignment.

•  Defined a new fiscal year variant if you follow a year-dependent fiscal year variant.

47.   HOW DO YOU CARRY FORWARD THE ACCOUNT BALANCES?

For all the G/L accounts, if you have already posted into the new fiscal year, you do not need to carry forward the balances manually. Otherwise, you should use the various carry-forward programs supplied by SAP for this task.

In the case of customer/vendor accounts, a posting in the new fiscal year does not carry forward the balances from the previous fiscal year. In this case, you need to manually carry forward these balances into the new fiscal year. However, any postings in the previous fiscal year(s) will update the balances carried forward into the subsequent fiscal years.

48.   HOW DOES CARRY-FORWARD HAPPEN IN SAP?

•  For all the balance sheet items, customer accounts, and vendor accounts, the balances are just carried forward to the new fiscal year, along with account assignments if any.

•  In the case of profit and loss accounts, the system carries forward the profit or loss (in the local currency) to the retained earnings account, and the balances of these accounts are set to “0.” No additional account assignments are transferred.

49.   IS THERE A PREREQUISITE FOR CARRY-FORWARD ACTIVITY?

Yes. For profit and loss accounts, you should have defined the retained earnings account in the system. Additionally, you should have also specified the profit and loss account type in the master record of each of these for profit and loss accounts.

There are no such requirements for G/L accounts, customer accounts, and vendor accounts.

50.   HOW DOES SAP ADJUST THE CARRY-FORWARD BALANCE IN A NEW YEAR WHEN YOU POST TO A PREVIOUS YEAR(S)?

When G/L balances are carried forward, at the end of a fiscal year (say, 2008), the system uses an indicator to determine whether the balance has already been carried over to the new fiscal year. That being the case, if you post values to a previous year (say, 2007), the system automatically adjusts the balance carried forward in the new fiscal year. This is very useful because you do not need to rerun the carry-forward program again and again when adjustments are to be done for the previous year(s).

51.   HOW DO YOU CORRECT CARRY-FORWARD BALANCES IF YOU NEED TO CHANGE A G/L CLASSIFICATION?

If, after the balance has been carried forward into the new fiscal year, you find that a G/L account has been mistakenly classified as a B/S account (instead of a profit and loss account) in the previous fiscal year, you just need to do two things to correct the situation:

•  Adjust the G/L account in the G/L account master record (in the “chart of accounts” area) as a P&L account.

•  Rerun the balance carry-forward program.

This is also what you should do if a G/L account has been wrongly classified as a P&L account instead of a B/S account in the previous fiscal year.

52.   CAN YOU RERUN THE CARRY-FORWARD PROGRAM FOR A PARTICULAR G/L ACCOUNT?

In the case of G/L accounts, there is no option to selectively carry forward balances to the new fiscal year. You must do this for all of the G/L accounts.

However, it is possible to carry forward the balances, selectively, in the case of AP/AR accounts.

53.   IN WHAT CURRENCY ARE BALANCES CARRIED FORWARD?

SAP carries forward the account balances in the currencies of the ledger.

54.   HOW MANY RETAINED EARNINGS ACCOUNTS CAN BE DEFINED?

You can define as many retained earnings accounts as you want. But normally, companies use only one retained earnings account (identified by “X” in the “profit and loss account type” field. To define more than one retained earnings account, you should use different profit and loss account types and assign the P&L statement G/L accounts to these account types.

Defining more than one retained earnings account could be useful for international corporations that are required to comply with various reporting requirements when producing the profit and loss statement.

55.   HOW DO YOU SET UP ONLY ONE RETAINED EARNINGS ACCOUNT?

You need to specify the retained earnings account to which profits or losses are transferred before you can include P&L statement accounts in the “chart of accounts” (Figure 1.27) SAP uses a special program to transfer these amounts to this account. Each P&L account is assigned to a retained earnings account via a key (normally “X”).

In the “chart of accounts” area of the G/L account master, select the “P&L statement acct” option for all of the profit and loss statement accounts if you follow individual processing of G/L account creation or change.

FIGURE 1.27  Denoting a G/L Account as a Profit and Loss Statement Account (Individual Processing)

Transaction Code
FSP0 (Edit Chart of Accounts Data)
FS00 (Edit G/L Account Centrally)

In the case of collective processing of G/L accounts (creation or change), put “X” under the “P&L Statement Acct Type” field for all the profit and loss statement accounts (Figure 1.28).

FIGURE 1.28  Denoting G/L Accounts as Profit and Loss Accounts (Collective Processing)

Transaction Code
OB_GLACC11

For account determination, you must enter the retained earnings account under the key “X” (Figure 1.29).

FIGURE 1.29  Retained Earnings Account Configuration

Transaction Code
OB53

56.   HOW DO YOU MAINTAIN CURRENCY IN SAP?

A currency (the legal means of payment in a country) in SAP is denoted by a 3-character currency code, maintained as per the ISO standards (Figure 1.30).

FIGURE 1.30  Currency Settings in IMG

Example

•  USD (US Dollars)

•  INR (Indian Rupee),

•  GBP (Great Britain Pound)

Each currency code in the system will have a validity defined.

Transaction Code
OY03

57.   WHAT IS LOCAL CURRENCY?

When you define a company code, you also need to mention in which currency you will be maintaining the accounts/ledgers in Financial Accounting. This currency is called the local currency (Figure 1.31). It is also known as company code currency. This is the national currency of that company code.

FIGURE 1.31  Local Currency

From the company codes point of view, all currencies other than its local currency are foreign currencies.

58.   WHAT IS PARALLEL CURRENCY?

When defining the currencies for a company code, it is possible to maintain two more currencies (2nd and 3rd local currencies) for each in addition to the local currency (Figure 1.32).

These two currencies are called parallel currencies, which can be:

•  Group currency

•  Hard currency

•  Global company currency

•  Index-based currency

FIGURE 1.32  Parallel Currencies (2nd and 3rd Local Currency)

To translate the values from one currency to the other, you need to maintain the exchange rate for each pair of the defined currencies in the system. For each such currency pair, you can define different exchange rates through exchange rate types (explained later in detail).

When parallel currencies are defined, the system maintains the accounting ledgers in these currencies as well in addition to the local currency.

59.   WHAT DO YOU NEED TO KNOW WHEN LEDGERS ARE MAINTAINED IN PARALLEL CURRENCIES?

When you manage ledgers in parallel currencies, you need to take note of the following:

•  During posting, the amounts are also saved in the parallel currencies. The amounts are translated automatically, but you can also enter them manually.

•  G/L account transaction figures are also updated in the parallel currencies.

•  Exchange rate differences also arise in the parallel currencies.

•  You can also carry out a foreign currency valuation in the parallel currencies.

You may define the parallel currencies in SAP Customizing Implementation Guide: Financial Accounting Global Settings (New) > Ledgers > Define Currencies of Leading Ledger

60.   WHAT IS GROUP CURRENCY?

Group currency is the currency defined at the client level, and it is used in the consolidated financial statements. Before the consolidation process can be completed, all values in the individual financial statements must be translated from the local or transaction currency into group currency.

If you have defined the group currency as the 2nd local currency, this has no additional effects. But in all other cases, in the application component special purpose ledger, you have to define an additional ledger in which transaction figures are managed.

61.   WHAT IS A HARD CURRENCY?

This is a country-specific 2nd currency used in countries experiencing high levels of inflation.

62.   WHAT IS GLOBAL COMPANY CODE CURRENCY?

Global company code currency is the currency defined for the company (or the consolidated company).

63.   WHAT IS ACCOUNT CURRENCY?

When defining the G/L accounts in the system, you are required to define a currency in which an account will be maintained, and this is called account currency (Figure 1.33). This is defined in the “company code” area of the G/L master record. The concept behind account currency is using the same chart of accounts even though the corporate groups’ company codes can still maintain their accounts in different local currencies corresponding to the currency of the country in which they are operating.

FIGURE 1.33  Account Currency Field in a G/L Account

The account currency is:

•  The currency used for postings made to this account.

•  The currency in which transaction figures are updated and the account balance is displayed.

64.   WHAT IS REFERENCE CURRENCY?

Reference currency is the currency key used to carry out all foreign currency translations for a specific exchange rate type. If foreign currency translation is necessary among several different currencies, you can simplify the maintenance of the exchange rates by specifying a reference currency. By taking this route, you need to specify the rates of all currencies in relation to the reference currency for this exchange rate type. All foreign currency translation is then carried out in two stages via the reference currency.

You can only use the reference currency for exchange rate type M (average rate) and not for buying or bank selling exchange rate types. SAP recommends defining a reference currency for the average rate and then entering exchange rate spreads for the buying and bank selling rates. This combination is particularly efficient because you only have to enter the exchange rates for the individual currencies to the reference currency for the average rate exchange rate type. The system calculates all of the other exchange rates.

EXAMPLE

Let USD be the reference currency. To translate from GBP to INR, the system uses the GBP/USD and INR/USD exchange rate specifications.

65.   WHAT TWO OPTIONS CAN BE USED TO SET UP ACCOUNT CURRENCY?

When defining the account currency, you have the two options shown in Table 1.3.

TABLE 1.3  Options for Account Currency Setup

Option

Details

Entering the local currency in the com-pany code

The system automatically uses the local currency that you have defined when creating the company code as the default value. This allows posting to the G/L account in any currency. When you make a posting in a foreign currency, the amount is translated into the local currency. The system maintains the transaction figures:

•  In the local currency (total of all the amounts posted in the local currency)

•  In the individual currencies (total of all the amounts posted in various currencies)

Entering a currency other than the local currency (that is, entering a foreign currency)

The posting is possible only in this currency. An exception to this is an exchange rate difference resulting from valuating G/L account balances. The transaction figures and the account balance are kept in the foreign currency entered and in the local currency.

66.   WHAT ARE ALL THE PREREQUISITES FOR POSTING IN A FOREIGN CURRENCY?

The following are the necessary prerequisites before posting in a foreign currency:

•  Local currency must be already defined for the company code (in the global parameters).

•  Foreign currency must be defined in the currency code table.

•  Exchange rates must be defined for the foreign currency and the local currency.

•  Translation ratios must be maintained for the local currency and the foreign currency.

67.   HOW ARE EXCHANGE RATES MAINTAINED IN SAP?

An exchange rate is defined for each pair of currencies and for each exchange rate type defined in the system. The exchange rate is defined at the document header level.

68.   WHAT IS AN EXCHANGE RATE TYPE?

The exchange rate type is defined according to various purposes like valuation, translation, planning, conversion, and so on. The standard system includes the exchange rate types for:

•  M Average rate

•  G Bank buying rate

•  B Bank selling rate

The system uses the exchange rate type “M” for posting and clearing.

Transaction Code
OB07

Using exchange rate types, SAP has simplified the exchange rate maintenance (Figure 1.34). If you need to carry out currency translations between several currencies, instead of entering translation rates between every single currency, you only need to specify the translation rate between each currency and the base currency. All currency translations then take place in two steps:

•  Into the base currency

•  From the base currency into the target currency

EXAMPLE:

Consider that the base currency is USD. You want the system to have a translation from INR to GBP. At the first step, INR is translated into USD. In the next step, USD is translated into GBP. However, you should have already defined, in the system, the following entries:

•  Ratio for INR and USD

•  Ratio for GBP and USD

Note that the system translates INR to GBP as if there is an exchange rate maintained between INR and GPB.

FIGURE 1.34  Exchange Rate Types

69.   WHAT IS A TRANSLATION FACTOR?

The relation between a pair of currencies per exchange rate type is known as the translation factor. For example, the translation factor is 1 when you define the exchange rate for the currencies USD and INR:

USD 1/ INR 1 = ----

You also specify whether you want to use an alternative exchange rate type for specific currency pairs. The ratios you enter here for currency translation are displayed again when maintaining the exchange rates.

Transaction Code
OBBS

70.   IS THERE AN EASY WAY TO MAINTAIN EXCHANGE RATES IN SAP?

SAP offers a variety of tools to maintain the exchange rates on an ongoing basis. The tools include:

•  Exchange rate spreads

•  Base currency

•  Inversion

Use the SAP program RFTBFF00 for populating the exchange rate table automatically from an input file in a multicash format from a commercially available input file.

71.   WHAT IS AN EXCHANGE RATE SPREAD?

The difference between the bank buying rate and the bank selling rate is known as the exchange rate spread, which remains almost constant (Figure 1.35). When you maintain the exchange rate spread, it is sufficient if you maintain the average rate for that currency in question in the system because you will be able to determine the buying/selling rate by adding or subtracting the spread to or from the average rate.

Transaction Code
OBD6

EXAMPLE

If the average rate between GBP and USD is 0.50805 and the spread is 0.00100, the bank buying rate derived will be 0.50705.

To make this calculation, you must enter the following in the system:

FIGURE 1.35  Exchange Rate Spread

72.   HOW ARE DIRECT AND INDIRECT QUOTATIONS USED?

It is possible to maintain the exchange rates in SAP by either direct or indirect quotations. What decides the usage of a particular type of quotation is the business transaction or the market standard (of that country).

SAP adopts two prefixes to differentiate the direct and indirect quotes during entering/displaying a transaction:

•  “ ”: Blank, no prefix. Used in direct quotations.

•  “/”: Used in indirect quotations.

When there is no prefix entered (blank), the quotation is construed as a direct quote by the system. Here are some possible scenarios:

•  The company in question is mainly using the indirect quotation.

Use “ ” (blank) as the prefix for the default notation for the indirect quotation. Use “*” as the prefix for the rarely used direct quotation. If someone tries to enter a transaction using a direct quotation without the “*” in the exchange rate input field, the system will issue a warning.

•  The company in question is mainly using the direct quotation.

You do not need to make any specific settings because the default is the “ ” (blank) prefix for the direct quotation, and “/” for the indirect quotation. So unless you make a transaction entry with the “/” prefix, the system considers all the entries direct quotations.

•  There may be times when you have to make a prefix mandatory irrespective of the type of quotation. In this case, define the direct quotation prefix as “*” and the indirect one as the system default “/” prefix. This makes these prefixes mandatory. Otherwise, the user will get a warning to correct the entry.

The exchange rate table in SAP looks like the one in Figure 1.36.

FIGURE 1.36  Exchange Rate Table

If the field content of “Indir.quot” is highlighted (usually in red), it means you have set the direct quotation method of exchange rate entry for that currency pair in customizing. Likewise, if the “Dir.quot” is shown in red, it means you have set the indirect quotation method of exchange rate for this currency pair in customizing.

Transaction Code
OB08

73.   HOW ARE TAXES HANDLED IN SAP?

SAP takes care of tax calculations, tax postings, tax adjustments, and tax reporting through the three FI components: G/L, AP, and AR. The processing of the following kinds of taxes is possible:

•  Tax on sales and purchases

- Input taxes (purchase tax)

- Output taxes (sales tax)

•  Additional taxes (these are country-specific and in addition to the tax on sales and purchases)

•  Sales tax (sales and use tax, as in the United States)

•  Withholding tax (income tax in India)

- Classic withholding tax

- Extended withholding tax

74.   AT HOW MANY LEVELS CAN TAXES BE HANDLED IN SAP?

SAP allows taxation at three levels:

1.  National level or federal level (Europe, South Africa, Australia, etc.)

2.  Regional or jurisdiction level (United States)

3.  National and regional levels (India, Canada, Brazil, etc.)

75.   HOW IS TAX CALCULATION STRUCTURED IN SAP?

SAP uses a technique called the condition method to calculate taxes (except withholding tax) in the system (Figure 1.37). The system uses tax (calculation) procedures defined in the system together with the tax codes for calculating the quantity of tax.

FIGURE 1.37  Condition Type (Tax Processing)

1.  The tax code is the starting point in the tax calculation. The tax code is country-specific, with every country having a country-specific tax procedure defined in the standard system, which is used as the template for defining various tax codes (Figure 1.38). The system uses the tax code to verify the following:

•  Tax type

•  Amount of tax calculated/entered

•  G/L account for tax posting

•  Calculation of additional tax portion, if any

2.  Tax rates are defined for each of the tax codes. The tax rates are then associated with tax types, which are included in the tax procedures. (Because of this relationship, it is technically possible for a single tax code to have multiple tax rates for various tax types.)

3.  The tax code is assigned to a tax procedure, which is tagged to a G/L master record. A particular tax procedure is accessed whenever that G/L account is used in a document processing.

FIGURE 1.38  Tax Procedures

76.   WHAT IS A TAX PROCEDURE?

A tax procedure contains the following (Figure 1.39):

•  Steps: To determine the sequence of lines within the procedure

•  Condition types: Indicates how the tax calculation model will work (whether the records are for fixed amounts or percentages, whether the records can be processed automatically, etc.).

•  Reference steps: From what area of the system it obtains the amount/value it uses in its calculations (for example, the base amount).

FIGURE 1.39  Tax Procedure TAXUS

•  Account/process keys: Provide the link between the tax procedure and the G/L accounts to which tax data are posted (Figure 1.40).

FIGURE 1.40  Account/Process Key for Tax Processing

This helps in automatic tax account assignments. To make sure these keys have the necessary information for automatic assignment, you need to define the following:

•  Posting keys (unless you have a specific requirement, it will be sufficient to use the G/L posting keys: Debit: 40, Credit 50)

•  Rules to determine on which fields the account determination is to be based (like the tax code or country key)

•  Tax accounts to which the postings need to be made

77.   HOW ARE TAXES CALCULATED IN SAP?

In SAP the tax is calculated as follows:

1.  The Access sequence helps in identifying the sequence of condition tables to be used and in identifying which field contents are the criteria for reading the condition tables (a group of condition types) (Figure 1.41).

FIGURE 1.41  Access Sequence with Fields Overview

2.  The tax calculated is normally posted on the same side as the G/L posting that contains the tax code. When exchange rate differences occur (due to tax adjustments in foreign currencies), these differences are generally posted to the specific account(s) for exchange rate differences. However, it is possible to specify (per company code) that the exchange rates for tax items can also be entered manually or determined by the posting or the document date and the resulting differences posted to a special account.

3.  SAP has a number of predefined account keys, and it is recommended that the standard keys be used.

78.   WHAT CONFIGURATIONS ARE REQUIRED FOR TAXES IN SAP?

You need to define the following when customizing:

1.  Base amount for tax calculation

For each company code you need to define whether the base amount includes the cash discount as well. If the base amount includes the discount, then the tax base is termed as gross; otherwise it is net. You may also define a similar base amount for calculating the cash discount. This also must be maintained for each of the company codes.

Transaction Code
OB69

2.  Tax codes

The tax code is a 2-digit code specifying the percentage of tax to be calculated on the base amount (Figure 1.42). While defining the tax code, you will also specify the tax type to classify a tax code relating to either input tax or output tax. The tax types are country-specific and determine how a tax is calculated and posted.

FIGURE 1.42  Tax Code “S1”

Transaction Code
FTXP

3.  Tax rate
The tax rate is the percentage of tax to be calculated on a base amount. You will be able to define tax rates for one or more tax types when you define a single tax code.

4.  Check indicators
By using the check indicators, you configure the system to issue error/warning messages when the tax amount entered manually is incorrect vis-à-vis the tax amount calculated by the system using the tax code.

79.   WHAT IS A TAX JURISDICTION CODE?

A jurisdiction code, used in countries like the United States, is a combination of the codes defined by tax authorities. It is possible to define up to four tax levels below the federal level. The four levels can be:

•  Subcity level

•  City level

•  Country level

•  State level

Before you can use the jurisdiction codes for tax calculations, you need to define the following:

1.  Create the access sequence (to include the country/tax code/jurisdiction fields).

2.  Create the condition types (which references the access sequence as defined above).

3.  Create the jurisdiction codes.

The tax rates are defined in the tax code on a jurisdiction basis. When posting taxes with a jurisdiction code, note that the taxes may be entered per jurisdiction code or per tax level.

80.   WHAT IS WITHHOLDING TAX IN SAP?

Withholding tax is a tax deducted at the beginning of a payment (at the source) that is withheld and paid or reported to the tax authorities on behalf of the person who is subject to the tax.

For example, a customer deducts and withholds the tax for a vendor for the services provided by the vendor. In the case of income tax (a form of withholding tax), the employer deducts the tax from the employee’s salary and remits it to the tax authorities on due or predetermined dates.

To the extent that the tax has been deducted, the vendor gets a withholding certificate (income tax certificate in the case of an employee).

There are two types of withholding tax:

•  Classic withholding tax

•  Extended withholding tax (EWT)

81.   WHAT IS THE DIFFERENCE BETWEEN WITHHOLDING TAX AND EXTENDED WITHHOLDING TAX (EWT)?

The classic withholding tax (CWT) is a procedure that has always been supported by the system that allows:

•  Withholding tax for accounts payable

•  Withholding tax calculation during payment

•  Withholding tax code per vendor line item

With the introduction of the extended withholding tax (EWT), it is now possible to:

•  Assign more than one withholding tax type to a business partner.

•  Make withholding tax calculations for partial payments

82.   HOW DO YOU SWITCH FROM CLASSIC WITHHOLDING TAX TO EXTENDED WITHHOLDING TAX?

To change over to extended withholding tax when you upgrade the SAP system to SAP 4.0 or other ERPs, you cannot simply activate extended with holding tax. In this case, you would not be able to carry out further processing to items already posted in the system. All relevant customizing, master, and transaction data must be converted so that it can then be used in extended withholding tax (Figure 1.43). SAP provides a tool that supports the withholding tax changeover by automatically converting the relevant withholding tax data.

The changeover needs to be carried out by completing each of the following steps:

Preparations

•  Carry out the Financial Accounting comparative analysis.

•  Archive cleared items.

•  Check the system settings for extended withholding tax.

•  Set up authorizations for the withholding tax changeover.

•  Block users.

FIGURE 1.43  Control Screen in Transaction Code “WTMG”

Converting Data and Activating Extended Withholding Tax

•  Create and edit a conversion run.

•  Prepare the data conversion.

•  Perform the data conversion.

•  Activate extended withholding tax.

Postprocessing

•  Carrying out the postprocessing of withholding tax data conversion.

Transaction Code
WTMG

83.   WHAT ARE TAX REPORTS IN SAP?

SAP comes with country-specific default tax reports to meet your tax reporting requirements. However, it is not uncommon to use third-party software for the same purpose. As a process, it is recommended that the closing operations are completed before running the tax reports. This will ensure that the system makes relevant adjustment entries (between payables and receivables, exchange rate differences, etc.) so the correct tax amounts are reported.

84.   WHAT IS A DOCUMENT IN SAP?

SAP is based on the document principle, meaning that a document is created out of every business transaction in the system. The document is the result of a posting in accounting in SAP, and it is the connecting link between various business operations.

There are two types of documents:

•  Original documents: These documents relate to the origin of the business transactions—for example, invoices, receipts, statements of accounts from banks, and so on.

•  Processing documents: These include accounting documents generated out of postings in the system, reference documents, sample documents, and so on. The processing documents other than the accounting ones are also known as special documents, and they aid in the simplification of document entry in the system.

Each document consists of:

•  A document header

•  Two or more line items

Before attempting to enter a document, you must call up the relevant document entry function because the system provides a variety of readymade document entry templates suited to different transactions, such as regular G/L entry, customer invoice posting, and so on. The details entered in a document can be simulated and displayed before the document is actually posted in the system. You may also choose to park the document and post it later.

85.   WHAT IS A DOCUMENT HEADER?

The document header (Figure 1.44) contains information that is valid for the whole document, such as:

•  Document date

•  Document type (control information)

•  Document number

•  Posting date

•  Posting period

•  Company code

Besides the above, the document header may also have information (editable, later on) such as trading partner, document header text, reference, cross-company code number, and so on.

FIGURE 1.44  Document Header

86.   WHAT IS A DOCUMENT TYPE?

SAP comes with a number of document types, which are used in various postings. The document type helps to classify an accounting transaction within the system, and it is used to control the entire transaction in determining account types that a particular document type can post to. For example, the document type “AB” allows you to post to all the accounts, whereas type “DZ” allows you to post only the customer payments. Every document type is assigned to a number range.

The common document types are shown in Table 1.4.

TABLE 1.4  Options for Account Currency Setup

Transaction Code
OBA7 (Define)
OBAB (Change)

87.   HOW DO YOU CONFIGURE THE DOCUMENT TYPES WHEN YOU USE NEW G/L?

With the introduction of New G/L, it is necessary that you set up the required document types as follows (Figure 1.45):

FIGURE 1.45  Defining Document Types with New G/L

•  Define Document Types of Entry View

The options for configuring the document types for entry view are outlined in Table 1.5.

TABLE 1.5  Document Types for Entry View

•  Define Document Types for Entry View in a Ledger

This customizing step is used for specifying the document types (and assigning the number ranges) for postings to the non-leading ledger(s).

•  Define Document Types for General Ledger View

This step will be required only when the fiscal year variant of the nonleading ledger in the company code (to which the postings are made) differs from the fiscal year variant of the leading ledger in this company code. If yes, use this step to define the document types and the number ranges for all the non-leading ledgers for documents in G/L view.

88.   HOW IS ACCOUNT TYPE CONNECTED TO DOCUMENT TYPE?

The document type is characterized by 2-character codes like AA, DG, and so on, whereas an account type is denoted by a 1-character code like A, D, and so on, that specifies which accounts a particular document can be posted to (Figure 1.46). The common account types include:

•  A   Assets

•  D  Customer (debtor)

•  K  Vendor (creditor)

•  M Materials

•  S   G/L

FIGURE 1.46  Account Type and Document Type

89.   WHAT ARE NET POSTINGS?

Usually, when a transaction—say, a vendor invoice (document type: “KR”)—is posted, the system posts the gross amount with the tax and discount included. However, SAP gives you the option of posting these items as net. In this case, the posting excludes tax or discount. Remember to use the special document type “KN.” (Similarly, you will use the document type “DN” for customer invoice—net against the normal invoice postings for the customer using the document type “DR.”) To use this net method of posting, you should have activated the required settings in the customization.

90.   WHAT ARE THE VARIOUS REFERENCE METHODS?

SAP recommends reference methods as a document entry tool to facilitate faster and easier document entry into the system when it is necessary to enter the same data over and over again. Besides making the document entry process less time consuming, it helps with error-free document entry.

The various reference methods used in SAP include:

•  Reference documents

•  Account assignment models

•  Sample documents

91.   WHAT IS A DOCUMENT CHANGE RULE?

The functionality document change rules configured in the system maintain the information relating to what fields can be changed and under what circumstances. As you are already aware, SAP’s document principle does not allow changing the relevant fields after a document has been posted. Any changes can only be achieved through reversal or additional postings. The fields like company code, business area, account number, posting key, amount, currency, and so forth can never be changed after the document has been posted. However, SAP allows changing some of the fields in the line items, such as payment method, payment block, house bank, dunning level, dunning block, and so on. These can be changed document by document or by using mass change for changing a number of documents all at once.

The changes to master data are tracked and stored per user for an audit trail.

92.   WHAT IS A LINE ITEM?

The line items contain information relating to account number, amount, debit/credit, tax code, and more. SAP allows a maximum of 999 line items in a single document. Besides the one you entered during the document entry, the system may also create its own line items called system generated line items—for example, tax deductions. Irrespective of the number of line items entered, it is important to make sure the total of these is zero (that is, total debits should equal total credits). Otherwise, the system will not allow you to post the document.

93.   WHICH BUSINESS TRANSACTIONS FOR WHICH SYSTEM CAN GENERATE THE LINE ITEMS?

Table 1.6 shows the different business transactions for which line items can be generated automatically.

TABLE 1.6  Business Transactions for Which the System Can Generate Line Items

Business Transaction

Line Items

Entering a customer or vendor invoice

•  Tax on sales/purchases (output tax when posting a customer invoice, input tax when posting a vendor invoice)

•  Payables and receivables between company codes (when posting cross-company code transactions)

Posting a customer or vendor payment and clearing open items

•  Cash discount (paid and received when posting payments)

•  Backdated tax calculation for tax on sales/purchases (after cash discount deduction)

•  Gains and losses from exchange rate differences (between invoice and payment)

•  Unauthorized deduction of cash discount (when a payment is slightly different from the amount due)

•  Residual items

•  Bank charges

Entering special G/L transactions

•  Bill of exchange charges

•  Tax adjustment for a down payment

94.   WHAT IS A DOCUMENT OVERVIEW?

When you change or display a document, the first screen you see is the document overview screen containing the most important information from the document header and the line items. You have a display line for each line item. You indicate what data should be displayed in this line by specifying the details in the line layout variant.

95.   WHAT ARE THE DOCUMENT NUMBER RANGES IN SAP?

A number range refers to a number interval defined in the system so when documents are posted, the system assigns a number from this range. You will define different number ranges for different document types. Each document in SAP is uniquely identified by the combination of document number, company code, and fiscal year.

The number range for a document type can be defined:

•  Per fiscal year, or

•  For a fiscal year in the future

If defined to last only one fiscal year, this needs to be defined every year. When number ranges are defined every year, the system starts from the first number in the range for that particular year. This way, the upper limit is not reached too fast.

If you specify the fiscal year as “9999, ” then the document number range is valid forever (well, almost!), and you do not have to do this exercise of maintaining number ranges every fiscal year. But every year the system starts from the last number used up in the previous year, and if a small number range is defined for a document type, you could easily run out of the number range quickly.

The document numbers can either be:

•  Internally assigned by the system, or

•  Externally input when the same is created

The number ranges (Figure 1.47) can be defined in such a way that the system generates the number automatically when a document is created. This is known as internal number assignment. Under this, the system stores the last number used for a document in the “current number” field and will bring up the next number when another document is created.

FIGURE 1.47  Document Number Ranges

If external numbering is used, the user needs to input a document number every time a document is created in the system. Because the user supplies the number every time, the subsequent numbering may not be sequential. Unlike internal numbering, the system does not store the last number in the “current number” field.

The numbers in a number range can either be numeric or alphanumeric. If numbers are numeric, the system will prefix the number with required zeros to make the number length uniform at 10 digits. If you are using alphanumeric numbering, then the number is padded with zeros from the right. If you are following year-specific numbering, it is better not to mix numeric and alphanumeric numbering for a particular document type in various fiscal years.

The system creates a minimum of one document when a transaction is created or completed. SAP recommends filing original documents (under the number of the processing document—the document generated in SAP). The best practice is to enter the (external) number of the original document in the “Reference” field of the document created in the SAP system. For easy cross-reference, the SAP document number thus created needs to be noted on the original document.

You must complete the following activities to properly configure the number ranges in the system:

•  Define the number ranges.

•  Copy the number ranges to company code(s).

•  Copy the number ranges to fiscal year(s).

Transaction Code
FBN1 (Define)
OBH1 (Copy to Company Code)
OAH2 (Copy to Fiscal Year)

With the introduction of New G/L functionality, note that the configuration settings for number range assignment have been grouped separately into two areas: document entry view and G/L view (Figure 1.48).

FIGURE 1.48  Document Number Ranges

96.   HOW DO YOU CHANGE THE NUMBER RANGES?

It may be necessary to change a number range if the number range originally assigned is not large enough. You can do the following:

•  Increase the upper limit of the number range or specify a new lower limit as long as another range does not already have the desired numbers.

•  Assign a new number range to the document type.

Changing Number Intervals

You can change the lower and upper limits for number range intervals. Changing the lower limit in a number range with internal number assignment is advisable only if a number has not been assigned yet. In changing the upper limit, make sure the new number does not fall below the current number. Ofcourse, the system ensures that the intervals do not overlap after you change the limits.

Changing the Current Number Level

With the internal number assignment, the current number is updated by the system automatically. Changing the current number is only permitted in special cases. For example, this may be necessary if the system starts assigning numbers from the lower limit of the interval again and finds that a number was not released yet. A document with this number therefore already exists in the system. In this case, you can increase the current number. The best practice, however, is not changing it.

97.   CAN YOU DELETE A NUMBER RANGE?

You can delete number ranges if no numbers have been assigned from that range. If numbers have already been assigned:

•  The system prevents deletion if it is a range with internal number assignment.

•  The system issues a warning message if the range has external number assignment.

If you delete a number range, you must assign new number ranges to the document types affected by the deletion.

98.   DO YOU NEED TO CHANGE THE VALIDITY OF A NUMBER RANGE?

No, normally this will not be required.

If you are using a number range that is independent of the fiscal year, you have already specified a year far into the future (this is where you have specified the year as “9999”). If you use fiscal year–dependent number ranges, you just need to define the number range for each fiscal year.

99.   HOW DOES THE SYSTEM POPULATE THE DEFAULT VALUES FOR A DOCUMENT?

The system brings the default values from several sources within the system:

•  User master record and parameter memory (say, when you post to a customer account “475737, ” then this account number is defaulted when you display the line items)

•  System (say, the system date is defaulted as the document date)

•  Account master record (say, the payment terms entered in a customer master are defaulted when you enter a document)

•  Default values for accounting functions, defined in IMG (say, the posting keys and the document type associated with invoice posting transaction)

100. WHAT ARE THE EDITING OPTIONS IN A DOCUMENT ENTRY?

The editing options functionality is used for making user-specific settings for:

•  Displaying data in the credit management area

•  Displaying line items

•  Displaying payment advice notes

•  Entering documents

•  Processing open items

The “Accounting Editing Options” screen contains editing options (Figure 1.49) for the following areas:

•  Document entry

•  Document display

•  Open items

•  Line items

•  Credit management

•  Payment advice notes

•  Cash journal

FIGURE 1.49  Accounting Editing Options

To access the editing options from the SAP “Easy Access” screen, choose Accounting > Financial Accounting > Accounts Receivable/Accounts Payable > Document Entry > Others, and then the required business transaction. On the initial screen, choose Settings > Editing Options. To select or reset editing options, select or deselect them on the respective tab. To save editing options in your user master record, choose Options > Change User Master. The changes will take effect beginning the next time you log on.

101. WHAT ARE HOLDING AND SETTING DATA?

In SAP, it is possible to hold (retain) or set (specify) data in various screens.

•  To hold data, choose System > User Profile > Hold Data from any menu bar. The next time you call up this screen with the same function, the system automatically enters the data in the appropriate fields. You can, however, overwrite the held data.

•  To set data on a screen, choose System > User Profile > Set Data from any menu bar. The next time you call up this screen with the same function, the system automatically enters the data in the appropriate fields. You cannot overwrite the set data.

•  To reset the held or set data, choose System > User Profile > Delete Data from any menu bar.

102. WHAT IS THE DIFFERENCE BETWEEN PARKING AND HOLDING DOCUMENTS?

Park documents in SAP is one of the two preliminary postings (the other being hold documents) in the system referring to storing incomplete documents in the system. These documents can later be call up for completion and posting. While parking a document, the system does not carry out the mandatory validity checking or any automatic postings (like creating tax line items) or balance checks. As a result, the transaction figures (account balances) are not updated. This is true in the cases of all financial transactions except in the area of TR-CM (cash management), where parked documents will update the transactions.

Parking of documents can be used to park data relating to customers, vendors, or assets (acquisition only). When a cross-company code document is parked, only one document is created in the initial company code. When this parked document is posted, all other documents relevant for all other company codes will also be created. However, the substitution functionality cannot be used with document parking because substitution is activated only upon transaction processing.

The added advantage is that a document that is parked by an accounting clerk can be called upon for completion by someone else. The parked documents can be displayed individually or as a list from where the required document can be selected for completion and posting. The number of the parked document is transferred to the posted document. The original parked document, if necessary, can be displayed even after the same has been posted to.

During a transaction, when the user finds that she or he does not have a required piece of information, he or she can hold document and complete it later. As in the case of parked documents, the document does not update the transaction figures.

The essential differences between these two types of preliminary postings are summarized in Table 1.7.

TABLE 1.7  Parking and Holding Documents

Attribute

Parking the Document

Holding the Document

View the document in “Account Display”?

Yes

No

Changes to the document?

Any user can access, view, and/change the document

Only the creator of the document can access, view, or change the document

Document number?

System assigned

Manually entered by the user

Use of data in the document for evaluation purposes?

Possible

Not possible

103. WHAT IS SIMULATING DOCUMENTS?

Simulating a document before you actually post it gives you an overview of the document items you have already entered. It helps in checking whether the entries are complete and correct. During simulation, the document goes through all the checks required for posting.

When you simulate a document, the automatically generated items, such as input tax and tax on sales and purchases, are displayed. But to simulate, you need to have entered the document header and at least one line item.

104. WHAT IS THE ACCOUNT ASSIGNMENT MODEL IN SAP?

The account assignment model is a reference method used in document entry when the same distribution of amounts to several company codes, cost centers, accounts, and so on is frequently used. Instead of manually distributing the amount among accounts or company codes, you may use equivalence numbers for distributing both the credit and debit amounts. A cross-company code account assignment model can also be created.

The account assignment model (Figure 1.50) may contain any number of G/L accounts, and the G/L account items need not be complete. The model can be used across several company codes, and it can even include company codes from non-SAP systems.

FIGURE 1.50  Account Assignment Model

•  You can use the account assignment model while parking a document (but you cannot use reference document for parking).

•  Use of account assignment model is limited to G/L accounts.

Unlike a sample document (discussed later), an account assignment model may be incomplete. It can be completed during document entry by adding, deleting, or changing the data already saved in the model.

Transaction Code
FKMT

105. WHAT IS A RECURRING ENTRY DOCUMENT?

A recurring entry original document (Figure 1.51) is used by the system as a reference document for enabling posting of periodically recurring postings such as loan repayments, insurance premium payments, rent, and so on. Because this document is not an accounting document, the account balances are not affected. In a recurring entry original document, you will not be able to change posting key, account, and amount. The recurring entry documents are defined with a special number range (“X1”). Unlike an account assignment model, this cannot be used for cross-company code postings.

FIGURE 1.51  Recurring Entry Document

.

The recurring entry document per se does not update transaction figures but acts only as a reference and as the basis for creating accounting documents. The SAP program SAPF120 creates the accounting documents from the recurring entry original document. There are two ways to set the exact date when this document should be posted to:

•  Posting frequency: Enter the day of the month and the period (in months) between two postings.

•  Scheduled run: Configure the run schedule specifying the calendar days on which the program should post these documents.

Transaction Code
FBD1

106. WHEN WILL YOU USE A SAMPLE DOCUMENT?

A sample document is like a template, which is created and stored so the information contained therein can be easily copied into new documents and posted in the system. But once a sample document is created, you will not be able to change the line items already contained in that document. All you can do is change the amounts in that sample document. But you can overcome this by either defining a new sample document that can contain other line items or adding new line items to the FI document that is created by copying from the original sample document.

Sample documents have separate number ranges (“X2”).

Transaction Code
FSM1

107. WHAT IS A LINE LAYOUT VARIANT?

Using a line layout variant, you can display the line item, the account number and name, and the posting amount. Using a different variant, you can display additional information such as tax information or the cost center. The standard system offers the following line layout variants:

•  Account/Name

•  Posting Key/Account/Business Area/Name/Tax

•  Account/Assignment

•  Company Code/Document

You can change these variants or add new ones in customizing.

108. WHAT FUNCTIONS CAN BE USED FOR LINE ITEM DISPLAY?

You can use the following functions for line item display in SAP:

•  Line Layout Variants

•  Selection Function

•  Sort Function

•  Totals Function

All these functions should support one another in this particular task. For example, an employee working with customer accounts who is responsible for customer dunning requires, for example, dunning information in the line item display. He requires a line layout with this information. On the other hand, summarized information is important for a credit controller. She will first need to look at a totals sheet to get the information she requires.

109. CAN YOU CHANGE DOCUMENTS IN SAP?

Though it is not recommended to change any of the documents (or the line items) that have already been posted, it is possible to change such documents. However, you must satisfy certain conditions to prevent any changes that could result in the undesired manipulation of data, which would then make reconciliation impossible.

If you want to change the line items for an account, the account needs to be managed using line item display.

•  The system prevents the data in certain fields (i.e., posting amount, account, posting key, fiscal year, and tax amount) of a posted document from being changed because they have already updated certain account balances during posting.

•  The system also prevents other fields from being changed in certain transactions. For example, with the net procedure of posting, you cannot change the cash discount amount when you post the payment.

•  The system prevents some fields from being changed if you use certain applications (you can no longer change the account assignment to a cost center if you use cost center accounting).

Whether or not you can change data in those fields that are modifiable still depends on the following factors:

•  The document change rules defined by your system administrator

•  Which other SAP applications, such as CO (Controlling) or MM (Materials Management), are installed

•  How these other applications have been customized

All document changes are logged. This also applies to changes to sample and recurring entry original documents, though with sample and recurring entry documents, you can change additional account assignments at any time. The restrictions do not apply to these special documents.

SAP uses the document change rules to manage changing documents/line items. Though it is possible to define your own conditions in the form of company-specific rules for changing documents, SAP recommends using the standard rules.

110. WHAT IS MASS CHANGES TO LINE ITEMS?

The functionality mass changes to line items is used to speed up the process of making changes to customer/vendor line items. You can change a group of line items simultaneously instead of having to change the line items of documents individually. The data in Table 1.8 can be changed using this functionality.

TABLE 1.8: Mass Changes to Line Items

Payment Data

Dunning Data

Payment method

Dunning block

House bank

Dunning key

Payment block (vendor only)

Dunning level (vendor only)

Terms of payment

Last dunning notice

111. WHAT IS CLEARING?

Clearing in SAP refers to squaring off open debit entries with open credit entries. Clearing is allowed in G/L accounts maintained on open item basis and in all customer/vendor accounts.

The clearing can either be manual or automatic. In the case of manual clearing, you will view the open items and select the matching items for clearing. In case of automatic clearing, a program determines what items need to be cleared based upon certain predetermined open item selection criteria and proposes assignments before clearing these assigned items. In both cases, the system creates a clearing document with the details and enters the clearing number against each of the cleared open items. The clearing number is derived from the document number of the clearing document.

You will also be able to do a partial clearing when you are unable to match open items exactly. The balance amount not cleared is posted as a new open item. You may also configure clearing tolerance and also define rules on how to tackle the situation when the net amount after clearing is not zero (i.e., writing off, posting the difference to a separate clearing difference account, etc.).

In the case of customers who are also vendors, you will be able to clear between these two provided the same is duly configured in the relevant master data (by entering the customer number in the vendor master record and the vendor number in the customer master record).

112. WHAT IS REVERSAL OF DOCUMENTS IN SAP?

In case you need to change some of the accounting information relating to an already posted document, you can only achieve the same by reversing the original document and posting a new one with the correct information. However, reversal is possible only when:

•  The origin of the document is in FI, not SD, MM, and so on. (In the case of documents from SD, the same can be reversed through a credit memo, and in the case of documents from MM, you need to use the appropriate functions in MM because the reversal in FI does not always reverse all the values.)

•  Information like business area or cost center is still valid (i.e., you have not deleted these business objects).

•  The original document has no cleared items. If there are cleared items, you need to reset the clearing before attempting the reversal.

•  The document relates only to the line items of customer/vendor/G/L.

•  The document contains only G/L, customer, or vendor account items.

While reversing, the system automatically selects the appropriate document type for the reversal besides defaulting to the relevant posting keys. (Remember that the document type for reversal documents should have already been configured when document types were defined in the configuration.)

As far as the date of the reversal document is concerned, the reversal document is normally posted in the same posting period as the original document; however, if that posting period is closed already, you may need to enter the posting date of the current open posting period.

The reversing can be made to update the transaction in either of the following ways:

•  The original and reversal documents increase the credit/debit figures by the same amount.

•  The reversal results in an account balance as if there has not been any posting to that affected account (this type of reversal is known as negative posting).

113. WHAT IS NEGATIVE POSTING?

As you are aware, any reversal results in opposite postings to the credit/debit sides of the original posting, leading to an increase in the account balances, and the trial balance is automatically inflated on both the sides. This is against the legal requirement in some countries (like France) wherein even after reversal, increased account balances should not occur. As a result, SAP came out with true reversal, which overcomes this problem by negative postings to the same line item(s) during reversal. The account balance that was originally increased was restored to the actual balance as if there was no posting to the account at all during the reversal (Table 1.9).

TABLE 1.9  Negative Postings (True Reversal)

114. WHAT IS FAST ENTRY?

Instead of the regular document entry screens, SAP provides fast entry screens for facilitating a quick way of entering repetitive line items in a transaction. For achieving this, you need to define a fast entry screen layout that will specify what fields you will require for data entry and in what order. You may configure these fast entry screen layouts for G/L account line items, credit memos, and customer/vendor invoices. Each of these fast entry screen layouts will be denoted by a 5-character screen variant in the system. Fast entry screens are used in complex (general) postings.

SAP’s enjoy postings are also used for similar data entry screens, but the difference is that in the case of fast entry you start from scratch in identifying the fields, positioning them in the line item, whereas in enjoy postings, the system comes with all the fields activated and you select the fields you do not want to be made available for data entry.

115. WHAT ARE CONTROL TOTALS IN SAP?

One of the control functions for entering and posting documents, control totals are used to post documents and check whether the data have been entered correctly (for example, invoices or checks) (Figure 1.52). To be able to use the control totals function, you should not select the “Do not update control totals” option in the editing options for document entry. Control totals are updated in the standard system.

FIGURE 1.52  Control Totals

You can use control totals either by (a) entering the total to be posted so the system then displays the difference after the amounts have been posted, or (b) entering an opening balance and posting the amounts so the system then displays the closing balance.

You need the following data to use control totals:

•  The amount to be posted (a total that you calculate before you enter a series of documents)

•  Posted amounts (the total debits and credits that the system calculates from the data you actually enter in the system)

•  Difference (difference between the expected total and the sum of the amounts actually posted)

•  The opening balance of an account

116. HOW ARE MASTER DATA DIFFERENT FROM TRANSACTION DATA?

There are three kinds of data residing in any SAP system: table data, transaction data, and master data.

Table data refer to the customized information for a particular client. This includes data like payment terms, discounts, pricing, tolerance limits, and so on that you do not normally change on a day-to-day basis.

Transaction data are the day-to-day recording of business information like purchase orders, sales returns, invoices, payments, collections, and so on. This includes both the system-generated (tax, discount, etc., that is automatically calculated by the system during document posting) and user-generated data.

Master data are the control information required to decide how transaction data get posted into various accounts (like customers, vendors, G/L, etc.). The master data are usually shared across modules (for example, customer master records are common to both FI and SD in SAP), obviating the need for defining the same in various application areas. The master data remain in the system for a fairly long period.

In the case of G/L master records, the data are created in two areas:

1.  Chart of accounts area (common to all company codes: chart of accounts, G/L account number, account name—short and long text, B/S or P&L indicator, account group, etc.)

2.  Company code area (specific to that particular company code: company code, tax code, currency, open item management, line item display, sort key, etc.)

In the case of customer/vendor master records, the data are created in two areas:

1.  Client-specific (general data like account number, name, telephone, bank information, etc., that are common to all the company codes using this master)

2.  Company code-specific (valid only for the company code, including terms of payment, dunning procedures, reconciliation account, sort key, sales area, purchasing information, etc.)

117. CAN YOU POST AN ACCOUNTS DOCUMENT IF CREDIT IS NOT EQUAL TO DEBIT?

In general, unless the debits are equal the credits in a document, you will not be able to post the document (you may use the simulate document functionality to check this). However, the system allows you to post some of the documents, even if this is not true in the case of noted items, which will contain only a debit or credit. Because there is no updating of accounting entries, the system will allow you to go ahead with the posting of these items.

118. WHAT IS A POSTING KEY?

A posting key in SAP is a 2-digit alphanumeric key that controls the entry of line items. SAP comes with many posting keys for meeting the different business transaction requirements: 40 (G/L debit), 50 (G/L credit), 01 (customer invoice), 11 (customer credit memo), 21 (vendor credit memo), 31 (vendor payment), and more.

The posting key determines:

•  What account can be posted to

•  Which side of the account (debit or credit) to be posted to

•  What layout screen must be used for that particular transaction

It is recommended not to change any of the default posting keys.

Transaction Code
OB41

119. WHAT IS THE SCHEDULE MANAGER?

SAP’s schedule manager (Figure 1.53) helps you to organize, execute, and monitor complex and repetitive business transactions (e.g., month-end processing) from an easy-to-use workspace that resembles an all-in-one organizer type of utility containing:

•  Calendar window

•  Daily overview window

•  Task overview window

•  User notes window

FIGURE 1.53  SAP Schedule Manager

The information window provides the details of what and how you can achieve the tasks by displaying useful information with hyperlinks to processes and steps within a process. This appears to the left of all the other windows. Depending on the requirement, this can be switched on or off.

The task overview window provides a complete drill-down facility in a tree structure of all the tasks you enter and monitor. The tasks are grouped into an upper-level task list that can be scheduled, released, and monitored using the daily overview window. Remember that the tasks maintained in the task overview window must be properly scheduled/released for execution. Just listing the tasks here will not start a transaction or a program or report.

The daily overview window is similar to an appointment column of any organizer, with fully customizable time intervals (in increments of, say, 30 minutes, 45 minutes, etc.). Ideally, the tasks appearing in the task list in the task overview window, when scheduled/released, will appear here against the appropriate time slot. By selecting a task here, you can monitor the same using the “monitor” icon or from the menu. A look at this daily overview window at the beginning of the day will remind you of the tasks scheduled for that day.

The calendar window is a calendar utility that helps you to organize better. However, this goes beyond the regular calendar by displaying in different colors particular dates indicating the statuses of tasks scheduled for that day. A green background, for example, indicates that everything is okay, but yellow indicates a warning.

Transaction Code
SCMA

120. HOW YOU CAN USE THE SCHEDULE MANAGER IN SAP?

The schedule manager has the following functionalities built in:

1.  Processes

This is the functionality that helps you to define the task list (also called the task group) and the individual tasks (a task is essentially a transaction or a program/report), which are later scheduled/released and monitored using the special monitoring function available. Any number of task lists can be created, and these lists are shown in a tree format for easy navigation. A task list may contain another task list or a chain of tasks in it, and tasks are grouped into a task list.

While defining the task itself, you can establish the owner of the task when this needs to be executed. The scheduling of tasks is also possible by simply dragging them into the appropriate time slots in the “daily overview” window. You may also use the “job wizard” while scheduling. A task, by mere scheduling, is not started automatically unless it is properly released. The tasks/task lists defined can be moved up or down in the hierarchy or deleted from a list. The tasks can also be documented using Microsoft Office Word or Excel.

2.  Scenarios

The schedule manager gives you three options for scheduling and monitoring:

a.  Start transaction/program/report online and schedule the jobs (tasks) in the scheduler: Here, you can create or select a new task list in the schedule, enter these in the daily overview, and monitor and control the tasks’ executions in the monitor.

b.  Start transaction/program/report online and schedule the jobs (tasks)/job chain (task chain): This is similar to (a), except you have the option of inserting a job chain defined in “flow definition” into the task list.

c.  Start transactions/reports online, schedule job or job chain, worklist: Here, you can also execute and monitor a complete worklist, involving several processing steps with all the step sequences. Besides scheduler, monitor, and flow definitions, you can use the “work-list monitor” for monitoring the processing status.

3.  Help Functions

Schedule manager supplements with useful functions like:

•  Runtime analysis

•  Working with variables

•  Releasing jobs

121. WHAT ARE THE ADVANTAGES OF A MULTILEVEL WORKLIST IN THE SCHEDULE MANAGER?

In the earlier releases of SAP, the period-end closing process consisted of a series of batch jobs. The sequence of the processing steps was established by the order in which the jobs were called. The objects were selected separately for each job. Through the selection criteria, it was possible to specify a unified scope of selection. This scope of selection had to be respecified for each processing step (that is, for each individual function of period-end closing). When an object was processed, errors that occurred in previous processing steps were not taken into account. For this reason, it was necessary to check the objects with errors after completion of a job. Any errors had to be corrected and then the job restarted for the entire scope of selection. In some areas (such as the period-end close in “product cost by period”), it was already possible to create a single-level worklist for the individual processing step. With this single-level worklist, the objects with errors could be called up for each processing step and the causes of the errors determined. The processing step could then be performed again for the object after the error was corrected. This worklist did not prevent objects with errors from being processed in the subsequent processing step (that is, in the subsequent job).

The schedule manager’s worklist is a multilevel worklist. This means that the worklist is generated for a sequence of processing steps rather than for just one processing step. Thus, the worklist makes possible an efficient execution of processing step sequences. Processes such as period-end closing can be performed much more efficiently with a multilevel worklist.

The multilevel worklist has the following advantages:

•  Faster processing of processing step sequences (such as in period-end closing)

Manual processing after completion of each job is no longer necessary. Manual processing is only necessary after executing a sequence of processing steps that consists of multiple jobs (for example, complete closing of an application component).

•  Repeat processing steps only for objects with errors

With the multilevel worklist, the processing steps are repeated only for the objects that have errors. If you had an object with errors in the single-level worklist, it was often necessary to carry out the following processing steps again for the entire scope of selection.

•  Decreased CPU time

The object selection only takes place once for each processing step sequence instead of for each single processing step. Objects are selected before the first processing step is executed.

•  The multilevel worklist provides performance benefits, particularly with complex structures in which dependencies between objects must be taken into account (such as complex project structures).

•  Direct notification to (business) owners for correcting errors

Jobs are planned and monitored by members of the EDP team. In many cases, they are not responsible for actually correcting the errors shown in the error logs. With the multilevel worklist, the actual employees (say, the business owners) responsible for correcting the errors can be informed directly through workflow-triggered mail messages.

CHAPTER

2

GENERAL LEDGER (FI-G/L)

1.     WHAT IS A CHART OF ACCOUNTS?

A chart of accounts is the list of G/L accounts used in one or more company codes. All the G/L accounts in a chart of accounts will have an account number, an account name, and some control information. The control information decides how the G/L account can be created.

2.     WHAT ARE THE MAJOR COMPONENTS OF A CHART OF ACCOUNTS?

A chart of accounts (Figure 2.1a) is defined with the following items:

•  Chart of account key

•  Name

•  Maintenance language

•  Length of the G/L account number

•  Controlling integration

•  Group chart of accounts (consolidation)

•  Block indicator

FIGURE 2.1a  Chart of Accounts

3.     WHAT IS AN OPERATING CHART OF ACCOUNTS?

This is the chart of accounts that is used for the day-to-day postings. Both FI and CO use this chart. It is mandatory that this chart of accounts be assigned to the company code. This is also known as an operating or a standard chart of accounts.

4.     WHAT IS THE DIFFERENCE BETWEEN A GROUP CHART OF ACCOUNTS AND AN OPERATING CHART OF ACCOUNTS?

A group chart of accounts, also known as a corporate chart of accounts, is used for consolidating all company codes (with a dissimilar operating chart of accounts) belonging to the same company (Figure 2.1b). This is the universe of all-inclusive G/L accounts from where the operating chart of accounts is derived. It is not necessary for this to be assigned to a company code.

5.     WHAT IS A COUNTRY CHART OF ACCOUNTS? WHY DO YOU NEED ONE?

This chart of accounts, also known as an alternate chart of accounts, contains the G/L accounts to meet the specific statutory/legal requirements of a company from where a company code operates. The assignment of this chart of accounts to a company code is also optional. It is possible that both the operating and the country chart of accounts are one and the same. In that case, you will not need two different charts of accounts.

FIGURE 2.1b  Mapping Country and Operating Charts of Accounts

In cases where the operating and country charts of accounts are different, the link needs to be established by entering the G/L account number from the country chart of accounts in the G/L master record (under the company code section) of the operating chart of accounts in the field “alternative account number” in the “control data” tab.

6.     CAN ONE CHART OF ACCOUNTS BE ASSIGNED TO SEVERAL COMPANY CODES?

Yes, one chart of accounts can be assigned to several company codes. However, the reverse is not possible. In other words, you cannot assign more than one chart of accounts to a single company code.

7.     HOW DO YOU CREATE G/L ACCOUNT MASTER DATA?

The G/L account master data can be created by any one of the following methods:

•  Manual creation

•  Creating with reference

•  Through data transfer workbench

•  Copying from existing G/L accounts

The manual creation of G/L account master records is both laborious and time consuming. You will resort to this only when you cannot create master records using any of the other methods listed above.

You will follow the second method, creating with reference, when you are already in SAP and have an existing company code (reference company code) from which you can copy these records to a new company code (target company code).

You will be able to do this by accessing the menu: SAP Customizing Implementation Guide > Financial Accounting (New) > General Ledger Accounting (New) > Master Data > G/L Accounts > G/L Account Creation and Processing > Create G/L Accounts with Reference.

Transaction Code
OB_GLACC01

While doing this, you can copy the account assignments as well, ensuring that the integration of G/L with other applications is intact. SAP facilitates that you can (1) limit the number of G/L records thus copied to the target company code, (2) create new records if necessary, and (3) change the account number/name.

When you have G/L accounts in a non-SAP system and you feel that these accounts will meet your requirements, you will then use data transfer workbench of SAP to transfer these records into SAP and change the same to suit the SAP environment. Because this will not have account assignment logic as required in SAP, you need to be careful in defining these assignments.

You will resort to the last option of copying from existing G/L accounts only when you feel there is a chart of accounts in the system that entirely meets your requirements. Otherwise, follow the second method described above.

You will be able to do this by accessing the menu: SAP Customizing Implementation Guide > Financial Accounting (New) > General Ledger Accounting (New) > Master Data > G/L Accounts > G/L Account Creation and Processing > Alternative Methods > Copy G/L Accounts > Copy Chart of Accounts/Copy Company Code.

8.     WHAT IS COLLECTIVE PROCESSING OF G/L ACCOUNTS?

Collective processing helps you to make systematic changes to a number of G/L accounts in a single step. For example, you have used the creating with reference method to create G/L accounts in a new company code, and you want to change the account names as well as the G/L account type (P&L or B/S). Then you will use this mass processing (collective processing) method to achieve the same. You can make changes to:

•  Chart of accounts data

•  Company code data

Use this menu path: Accounting > Financial Accounting > General Ledger > Master Records > G/L Accounts > Collective Processing > Chart of Accounts Data / Company Code Data / Descriptions. You can also use the IMG menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > General Ledger Accounting (New) > Master Data > G/L Accounts > G/L Account Creation and Processing > Change G/L Accounts Collectively > Change Chart of Accounts Data > Change Company Code Data > Change Account Name.

Remember that the collective processing helps only to edit and you cannot use this method if you need to create new master records.

9.     WHAT IS INDIVIDUAL PROCESSING OF G/L ACCOUNTS?

As opposed to the collective processing of G/L accounts, where you edit a number of accounts in a single step, individual processing helps you to edit or create G/L account master records one at a time. Here you can edit (including display, change, block, unblock, and delete) or create a New G/L account in three different ways:

1.  Centrally: You will be editing or creating a G/L account master record in both the chart of accounts area and the company code area in one go. This is also known as one-step G/L creation.

Transaction Code
FS00

2.  In the chart of accounts area: You first edit or create the record here before doing the same in the company code area.

Transaction Code
FSPO

3.  In the company code area: You edit or create the record here after the same has been done in the chart of accounts area.

Transaction Code
FSSO

Put together, steps 2 and 3 relate to step-by-step creation of G/L account master records.

10.   CAN YOU CHANGE AN EXISTING BALANCE SHEET G/L ACCOUNT TO A P&L ACCOUNT?

Technically, you will be able to change all the fields except the account number of a G/L account in the chart of accounts area. However, in this particular instance, when you change the G/L account type from B/S to P&L, make sure you again run the balance carry-forward program after saving the changes so the system corrects the account balances.

11.   CAN YOU CHANGE THE TAX CATEGORY IN A G/L MASTER?

You will be able to change the company code–related fields like tax category, currency, and so on provided there has not been any posting to these accounts. Pay attention to the following:

•  If you need to denote an existing G/L account to henceforth be managed on open item basis or vice versa, then make sure that the account balance is zero in either case.

•  If you are trying to change an existing reconciliation account to a regular G/L, then make sure the account has not been posted to.

•  If you are attempting to change an existing ordinary G/L account into a reconciliation account, make sure the account has a zero balance.

12.   WHAT IS AN ACCOUNT GROUP?

The account group (or G/L account group)—a 4-character alphanumeric key—controls how G/L account master records are created in the system (Figure 2.2). This helps to group G/L accounts according to the functional areas to which they must belong. The account group is mandatory for creating a master record. The same account groups can be used by more than one company code if they all use the same chart of accounts. However, each G/L account is assigned to only one account group.

The account group determines:

•  What number interval is to be used while creating the master record.

•  What screen layout is to be used while creating the master record in the company code area.

While defining the account groups in the system, you also need to define the corresponding field status for each of these groups. Otherwise, you will not be able to see any fields because all of them would be hidden by default.

SAP comes with several account groups such as the following:

•  SAKOG/L accounts general

•  MAT.Materials management accounts

•  FIN.Liquid funds accounts

FIGURE 2.2  G/L Account Groups

In most of the situations, you will not require groups other than the ones already available in the standard system. However, if you need to create a new one, it is easier to copy an existing one and make modifications to the same instead of creating from scratch.

Transaction Code
OBD4

13.   WHAT IS A SCREEN LAYOUT?

The account group determines which screen layout should be used while creating a G/L account master record. For each of the account groups, you can define different screen layouts, which essentially determines the field status of a field (Figure 2.3).

The field status is whether the field is one of the following:

•  Suppress (field is invisible, hidden from display)

•  Req.entry (display on, entry required)

•  Opt.entry (display on, entry not mandatory)

•  Display (display only)

FIGURE 2.3  Field Status

All the above are shown as radio buttons against each of the fields in the screen layout, and you should select any one to set the status to that field; by default, all of the fields are suppress.

Two levels of controls of field status are available to decide which takes priority while deciding the screen layout:

•  Field status at the account group level

•  Field status at the activity (create/change/display) level—that is, at the transaction level

You may also have the field status defined for posting keys (40-debit and 50-credit for the G/L account postings). Also remember to define the field status for reconciliation accounts because you will not be able to define any such status in the subledger accounts (for example, customer or vendor).

SAP has built-in rules—called link rules—to link these two levels and to decide the final status of a field in the screen layout. The link rules also help to overcome the differences in field status settings from different settings at the client level (field status for posting keys) and at the company code level (field status settings at the account group level).

14.   WHAT IS A FIELD STATUS GROUP?

The field status of an individual field or group of fields is marked into a field status group, which is then assigned to individual G/L account master records (Figure 2.4). You may attach field status groups to a field status variant so the same field status groups are used in various company codes.

FIGURE 2.4  Field Status Variant/Field Status group

Transaction Code
OBC4

The field status variant is named similar to the company code. For example, if your company code is 1000, the field status variant is also named 1000, and the same is assigned to the company code (Figure 2.5).

FIGURE 2.5  Assign Field Status Variant to Company Codes

Transaction Code
OBC5

15.   WHAT IS ONLY BALANCES IN LOCAL CURRENCY?

When you create G/L account master records, it is necessary to decide whether you want an account to have the transactions updated only in local currency (Figure 2.6). Then you will set this indicator accordingly in the company code area of the master record. You should set this indicator for the clearing accounts as follows:

•  Cash discount clearing accounts

•  GR/IR clearing accounts

FIGURE 2.6  “Balances in Local Currency” Indicator in G/L Account

You should not set this indicator for reconciliation accounts for customers or vendors. Setting it in all other instances is optional. It is usually set for particular balance sheet accounts, including:

•  Accounts that are not managed on an open item basis and not kept in foreign currencies.

•  Accounts that are managed on an open item basis and have the same types of items posted in different currencies but always allow clearing to be made if the local currency amounts correspond.

EXAMPLE

Consider an invoice for USD1, 000, which on that day of posting translates into an amount of INR45, 000 with an exchange rate of I USD = INR 45. Imagine that when the goods are received, the exchange rate was 1 USD = INR 44.

•  If the indicator is set, the system ignores the exchange rate as if the line items have been maintained only in the local currency (INR) and the items are cleared.

•  If the indicator is NOT set, the system makes a posting for the exchange rate difference (INR 1, 000) before clearing the two line items.

16.   WHAT IS LINE ITEM DISPLAY?

To display line items of an account, you need to set the indicator “line item display” to “on” in the “account management in company code” block of the “control data” tab of that account’s master record (Figure 2.7). This is mandatory for customer and vendor accounts.

FIGURE 2.7  “Line Item Display” Indicator in Account Master

For each line item, an entry is saved in an index table that contains the connection between the line item and the account. The line items can be displayed using classical display or SAP List Viewer (ALV). And you can use several display variants to suit your needs to display various fields when you feel that the standard variant is not meeting your requirements.

In the New G/L, the line item display is always possible for the general ledger view. You need to set this indicator if you (a) also want to see the line items in the entry view, and (b) want open item management.

17.   WHAT IS ARCHIVING? HOW IS IT DIFFERENT FROM DELETING?

Archiving refers to deleting data from the documents from the database and storing it in a file, which can then be transferred to an archiving system later on. Archiving does not physically delete the documents.

Deleting is removing the documents from the database. To archive and delete, you need to consider the following:

•  Block posting to these archived master records.

•  Mark (the master records) for deletion.

- Mark for deletion at the chart of accounts area to delete the records from all the company codes. However, if you do not want to delete from all the company codes but only from one or more company codes, then do the same in the company code area of the master record(s).

•  Archive all the transaction figures from the relevant documents.

•  Call up a special program to delete the records.

- The program will check whether that particular document could be deleted. If yes, it will proceed to “archive” and then to “deletion.”

18.   WHEN DO YOU BLOCK AN ACCOUNT?

You may use blocking to:

•  Block an account from further postings

•  Block the creation of an account (at the company code level or chart of accounts area)

19.   WHAT ARE INTERCOMPANY POSTINGS IN SAP?

Intercompany postings arise when a company code in a centralized procurement, for example, pays for itself and on behalf of other company codes. When posted, the transaction results in three documents for:

•  Paying company code (say, 1111) in its books

•  Other company codes (say, 2222 and 4444)

•  The intercompany transaction itself

Before making intercompany transactions, you need to configure both intercompany payables and intercompany receivables. For each combination of these company codes, you will be required to maintain a clearing account that must be referenced in each of these company codes. You will also be able to configure whether you manually input the transaction number or allow the system to automatically assign the numbers. In the case of system-generated transaction numbers, this 16-digit number consists of (1) a 10-digit document number (1222222222) of the paying company code, followed by (2) 4 digits representing this paying company code (1111), and (3) 2 digits representing the last two digits of the financial year (07) (for example, 1222222222111107).

20.   CAN YOU MANUALLY CLEAR THE OPEN ITEMS? WHEN?

Under manual clearing, you will select the open items based on the incoming payment so the selected open items are cleared (knocked off). In cases like refunds from a vendor or transactions involving bank subaccounts, clearing accounts, and so on, you will use manual clearing.

When cleared, the system flags these line items as “cleared, ” creates a clearing document, and enters the clearing document number and clearing date in these open items. Besides the clearing document, the system may also generate additional documents in cases like partial or residual processing and for posting the loss/gain to the assigned G/L account.

While doing this, if there is a payment difference, the same can be treated the way it is configured in the system:

•  If the difference is within the tolerance limit defined in the system using the tolerance groups (defined at the company code level), the cash discount is adjusted, or the system automatically posts the difference to a gain/loss G/L account.

•  When the payment difference exceeds the limits of defined tolerance, then the incoming amount may be processed as a partial payment (the original open item is not cleared, but the incoming payment is posted with a reference to that invoice), or the difference is posted as the residual item (the original open item is cleared, and the system creates a new open item for the difference amount) in the system.

21.   HOW DO YOU PERFORM PERIOD CLOSING IN SAP?

You do a period closing in SAP with three steps:

•  Completing the preclosing activities

•  Financial closing

•  Managerial closing

22.   WHAT IS PRECLOSING?

You need to ensure the following as preclosing activities:

•  Post all the recurring entries for expenses and accruals.

•  Ensure that all the interfaced programs have been run so the required data have been transferred to the system.

•  Post all the depreciation, material receipts, invoices, salaries, and so on. In short, ensure that all the transactions for the period in question have been duly recorded and posted into the system.

23.   WHAT IS FINANCIAL CLOSING?

If you have not yet migrated to SAP ERP or if you are not using the new GL functionality, you may perform the following activities step by step to complete the financial closing. If you use New G/L functionality, then you will use the “closing cockpit” to accomplish closing, which is easier and faster. “Closing cockpit” functionality is explained in the “General Ledger Accounting (New)” section.

Revaluate/Regroup

•  Revalue balance sheet items managed in foreign currencies. Use the report RFSBEW00 to valuate G/L balance sheet accounts managed in a foreign currency. (The report generates a batch input session to post the revenue or expense resulting from any exchange rate differences.)

•  Clear receivable or payable with “exchange rate difference.”

•  Valuate all the open items using the report SAPF100. This is used to valuate all the open receivables and payables, using the period-end exchange rates. Here also, the report generates a batch input session to post the entries resulting from any exchange rate differences.

•  Regroup GR/IR using the program RFWERE00 to allocate the net balance (depending on whether the balance is a net debit or credit) in the GR/IR account to one of two G/L accounts (created to actually depict the net effect of the balance in the GR/IR account).

Ensure Accounting Accuracy

Use the program SAPF190 to compare the totals created by the system in the (1) indexes (customers, vendors, and G/L) and documents (customers, vendors, and G/L) with those of the (2) account balances (customers, vendors, and G/L) to ensure transaction accuracy.

Run Required Reports

Generate the financial statements (balance sheet and profit and loss accounts), using the financial statement versions. You may also generate the key figure/ratio reports using the G/L account information system.

24.   WHAT IS A FINANCIAL STATEMENT VERSION?

The financial statement version (Figure 2.8) helps to define the financial statements (both the balance sheet and profit and loss statements). When you copy the settings from an existing company code to a new one, you will also be copying the financial statement version defined for the source company code.

FIGURE 2.8  Financial Statement Version

You can define a new financial statement version and build the financial statements from scratch. You may create the financial statements both for (1) external reporting (company code financial statements) and (2) internal reporting (business area financial statements).

You may also create the balance sheets for a group of company codes using FI-SL (special purpose ledgers). The financial statements may be defined to provide information from (1) a period accounting point of view (per G/L account groups) or (2) a cost of sales point of view (functional area financial statements).

All the above statements can be configured and defined to provide different levels of details. A financial statement version can have a maximum of 10 hierarchy levels, with each level assigned with an item (account category). As you go down the hierarchy, you define the account categories in more detail, with the lowest level being represented by the G/L accounts. The system displays the relevant amount for each of these items (Figure 2.9).

FIGURE 2.9  Items in a Financial Statement Version

25.   WHAT ITEMS ARE REQUIRED IN A FINANCIAL STATEMENT VERSION?

Irrespective of the details you require in a financial statement version, it is mandatory that you have at least the following items defined:

a.  Assets

b.  Liabilities

•  Net Result: Profit

•  Net Result: Loss

c.  P/L result (during annual closing, when you run the program RFBI-LA00, the system calculates the profit or loss by subtracting the total liabilities from total assets and updates the relevant Net Result item − Profit or Loss)

d.  Not assigned (posted amounts but not yet assigned to any of the account groups)

26.   HOW CAN YOU MAKE SURE THE CORRECT BALANCES ARE IN A FINANCIAL STATEMENT VERSION?

In order to have a balanced statement (profit and loss and balance sheet), you need to ensure that the accounts are correctly and completely assigned to the nodes of the financial statement version. You may do this by necessary assignments at both the account balance level and the node balance level.

At the account balance level, you need to ensure that the account is shown in two different nodes, but you will turn “ON” the “debit indicator” of the account on one node and turn “ON” the “credit indicator” on the other node. Imagine that you have a bank current account 10001000. When you turn “ON” the debit indicator, this account shows only the debit balances and is construed as the asset. On the other hand, when the credit indicator is turned “ON, ” the balances on this node now indicate that you owe to the bank (overdraft).

You may also use the node level assignment. In this case, the system uses the “debit/credit shift” and shows only the effective balance at the node and NOT at the individual account level.

27.   HOW DO YOU DO ANNUAL CLOSING IN SAP?

Annual closing is like any other period closing, and you will be performing all the activities that are required for a period-end close. You will also be completing the following:

•  Carry forward vendor and customer accounts

•  Carry forward the G/L account balances of all the balance sheet items

•  Close the profit and loss accounts and carry forward the balance (profit or loss) to the retained earnings account(s)

For G/L account carry forward, use the program SAPF011.

It will be faster and easier to use the “Closing Cockpit” to accomplish this if you use the New G/L.

28.   WHAT IS MANAGERIAL CLOSING?

Managerial closing involves completion of the following:

•  Do a preliminary Controlling period closing.

•  Settle/reallocate costs across the Controlling organization.

•  Draw and review internal reports.

•  Reopen the Controlling period.

•  Correct and adjust the accounting data, if required.

•  Reconcile FI and CO by running the FICO reconciliation ledger.

•  Run the readjustment programs to ensure that the business areas and the profit centers are balanced.

•  Draw reports and analyze.

[A] 2.1 NEW GENERAL LEDGER ACCOUNTING

29.   WHY DID SAP INTRODUCE NEW GENERAL LEDGER ACCOUNTING?

Before the advent of the SAP ERP/ECC versions, various releases of SAP R/3, including SAP R/3 Enterprise (4.70), companies had to handle G/L accounting by using different SAP applications. Depending on the particular company or industry requirements, or local accounting principles, one had to implement application components or functions that sometimes had their own user interfaces. For example, you might use special purpose ledger (FISL) to meet certain reporting requirements, such as having totals in additional table fields. Likewise, the SAP Profit Center Accounting (PCA) application resided in a separate application. The software for both the FI-SL and the PCA offered certain functions that were not automatically reconciled with functions in the G/L accounting software. This had resulted in closing activities involving additional reconciliation efforts—and delays.

The New G/L, starting with SAP ERP 2005, covers all these functions and requirements, but retains the familiar accounting interface—such as currency translation—and continues to provide functions that support postings (Figure 2.1-1). Upstream software for S&D and MM works with the New G/L in exactly the same way as before. The familiar and well-tested tables (BSEG: document table; BSIS: open items for New G/L accounts; and BSAS: cleared items for G/L accounts) are still part of the New G/L and form the database for many standard reports and customer-specific reports. New G/L functions for financial allocation or statistical key figures, for example, share the same interface design as functions for Controlling.

If you are familiar with SAP R/3, then you will be comfortable using New G/L because the user interface is almost the same and is intuitive.

FIGURE 2.1-1  New G/L Functionality in IMG

30.   WHAT ARE THE TECHNICAL ADVANTAGES OF USING NEW G/L?

The following are some of the major technical advantages of New G/L:

•  The New G/L does away with the need for separate ledgers like cost-of-sales ledgers, special purpose ledgers, reconciliation ledgers, or profit center ledgers, with the introduction and portrayal of business models occurring within a single solution.

•  Users who are already familiar with SAP R/3 require very little training because the user-interface is similar to Classic G/L.

•  New G/L stores all the data in a single totals table, eliminating data redundancy, and you just need to input data only once.

•  Additional reconciliation activities during closing are not required because the data are always automatically reconciled with other applications.

•  Additional fields, standard SAP fields, and customer-defined fields for flexible reporting have been made easier.

31.   WHAT ARE THE BUSINESS ADVANTAGES OF USING NEW G/L?

The following are some of the major business advantages of using New G/L:

•  Easy and flexible international business reporting

•  Fast closing

•  Financial and management accounting integrated in a single interface

•  More transparency with improved audit trails

•  Parallel accounting possibility

•  Reduced TCO (Total Cost of Operations)

•  Usage of customer fields

32.   WHAT ARE ALL THE FEATURES OF NEW G/L?

The traditional or Classic G/L accounting in FI was focused toward providing a comprehensive external reporting by recording all business transactions in the system. However, to meet current requirements, this has now been enhanced, and New G/L provides the following:

•  Parallel accounting: Maintaining several parallel ledgers to meet different accounting principles.

•  Integrated legal and management reporting: Unlike the traditional G/L, the New G/L enables you to perform internal management reporting along with the legal reporting. So you are in a position to generate financial statements for any dimension (say, profit center) in the business.

•  Segment reporting: With the introduction of segment dimension, SAP now makes it possible to produce segment reports based on IFRS (International Financial Reporting Standards) and the US GAPP (Generally Accepted Accounting Principles) accounting principles.

•  Cost of sales accounting: Now it is possible to perform cost of sales accounting in the new FI-G/L.

33.   WHAT IS THE LEDGER CONCEPT IN NEW G/L?

New G/L uses the Special Purpose Ledger (FI-SL) technique to save total values in the tables, many of which are preconfigured upon delivery (Figure 2.1-2). In New G/L, a ledger or ledger group can portray one or more valuation views. All company codes are assigned to a leading ledger for each client. This ledger contains the group-valuation view. You can add additional ledgers (non-leading ledgers) for each company code. By assigning different characteristic values and fiscal year definitions, you can use these additional ledgers for different purposes, such as parallel accounting or management reporting.

FIGURE 2.1-2  Ledgers in New G/L

With the focus of New G/L on how data are updated rather than changes to the interface, it is now possible to directly perform postings that previously required several different components. This is also true with the transfer postings between profit centers or other characteristics (such as segments) that were previously stored in FI-SL. You can now use a G/L account posting that specifies the corresponding profit center. The advantage of this kind of posting is that the system always reconciles the profit centers and G/L account instantaneously, because all the data are stored in the same table. The document numbers by document type are still based on the number range object from the G/L component of SAP R/3 (RF_BELEG). However, in cases involving a posting to a ledger with a fiscal year that differs from that of the leading ledger, the system issues document numbers from a different number range object (FAGL_DOCNR).

You can handle parallel accounting using the ledger approach as an alternative to the account approach. To provide different valuation views for period-end closing, you can either perform automatic postings using the valuation programs (such as foreign currency valuation) or use manual postings to a specific ledger.

For postings related to daily operations, the software normally updates all ledgers assigned to the company code because the leading ledger exists in all company codes (across all clients). You can, however, define additional ledgers for each company code, possibly with different fiscal year variants. An incoming invoice, such as a payment on an account, always updates all ledgers related to the respective company code. The period check is always performed for the leading or representative ledger. If a ledger group does not contain the leading ledger, one of the ledgers in the group becomes the representative ledger. This approach means that postings are made only if the period of the leading or representative ledger allows. SAP ERP does not validate any other fiscal year definitions that exist in other ledgers of the ledger group. The software updates the other ledgers in every case, which does not prevent completion of the posting. Note that you cannot make postings specific to ledgers or to ledger groups to accounts managed on an open-item basis.

34.   WHAT IS THE LEADING LEDGER IN NEW G/L?

The standard SAP system comes delivered with “0L” as the leading ledger, together with the “totals” table “FAGLFLEXT.” The leading ledger is the principal ledger that uses the fiscal year variant and posting period variant, among other control parameters, from the company code. The leading ledger manages all the local currencies of the company code. Only the values from the leading ledger are posted to Controlling (in the standard system). Note that there will be only one leading ledger.

35.   WHAT ARE THE TWO VIEWS IN NEW G/L?

With New G/L, users can switch between the entry view (regular view or data entry view; Figure 2.1-3) and the G/L view (Figure 2.1-4). A user can enter/display/change documents in exactly the same way as before (that of Classic G/L) using the entry view. This is the view most of the users will be working with.

FIGURE 2.1-3  Entry View

However, one can easily toggle to the G/L view, which is always specific to a ledger. Depending on the system setting, you can also display one or more G/L views. That is why in certain ledger views, it might be useful to derive specific characteristics or set a zero balance for all the segments involved in each document.

FIGURE 2.1-4  G/L View

36.   IS IT NECESSARY FOR A CLIENT TO USE ONLY NEW G/L?

For all the new installations, SAP recommends using New G/L, and the functionality will be active by default. However, for an existing customer, using it is optional. He or she can continue to use the Classic G/L accounting and can migrate to New G/L whenever he/she wants (after migrating to SAP ERP). You should also remember that New G/L will be activated when there is an upgrade.

37.   WHY DO YOU NEED TO ACTIVATE NEW G/L IN THE SYSTEM?

By activating New G/L accounting, the accounting functions are made available (Figure 2.1-5).

FIGURE 2.1-5  Activate New G/L Accounting in IMG

Once New G/L functionality is activated, in the SAP Reference IMG, the previous Financial Accounting menu is replaced by the “Financial Accounting (New)” menu (Figure 2.1-6). Under “Financial Accounting Global Settings (New)” and “General Ledger Accounting (New), ” you can make the settings for New G/L accounting. You activate the tables of New G/L accounting so your posting data are written to them.

FIGURE 2.1-6  New G/L Accounting Menu in IMG

If you already use Classic G/L accounting in your production system, you need to perform migration of data before you activate New G/L accounting. Migration is only possible as part of a project. In the standard system, the tables from Classic G/L accounting (“GLT0”) are updated, as well as the tables in New G/L during the activation. This enables you to perform a ledger comparison during the implementation of New G/L to ensure that your New G/L accounting has the correct settings and is working correctly.

38.   WHEN DO YOU DEACTIVATE UPDATES TO CLASSIC G/L IN THE SYSTEM?

It is recommended that you deactivate the update of tables for Classic G/L accounting once you have established that New G/L is working correctly (Figure 2.1-7). To do this, in customizing, choose Financial Accounting Global Settings (New) > Tools > Deactivate Update of Classic General Ledger.

FIGURE 2.1-7  Deactivating Update of Classic G/L—IMG

Remember that when you activated New G/L accounting, not only are the tables of New G/L accounting updated in the standard system, but the balances in the tables of Classic G/L accounting (Table GLT0) are as well. This default setting is maintained so you can use comparison reports during the implementation phase of New G/L to ensure that New G/L accounting delivers the correct results. Once you have established that New G/L accounting is set up and operating correctly, you can deactivate the updates from Classic G/L accounting (Figure 2.1-8). To do this, deselect the indicator “Write Classic General Ledger (GLT0).”

FIGURE 2.1-8  Deactivating Update of Classic G/L

In the standard system, reading data from the tables of Classic G/L are deactivated, meaning that the programs of Classic G/L accounting (such as classic financial statements) read the balances from the tables of New G/L accounting. If you want the programs of Classic G/L accounting to read the tables of Classic G/L accounting, select the indicator “Read Classic General Ledger (GLT0).” Note to select this indicator only if the indicator “Write Classic General Ledger (GLT0)” is also selected.

39.   WHAT NEW TABLES ARE INCLUDED IN NEW G/L?

The two important tables of Classic G/L—BSEG and BKPF—remain in New G/L also, with all the documents relevant for the leading ledger updated in these tables. However, you have some additional fields like LDGRP, RLDNR, and so on in BSEG (document header) and fields like SEGMENT in BKPF (document line items).

SAP has introduced three new tables in New G/L to handle totals, store G/L-specific line items, and calculate valuations for year-end closing in parallel ledgers.

a.  New totals table

In addition to using the new totals table in the standard software, you can define your own table using a new table (FAGLFLEXT) as a template. You might need to define your own table (but check if you really need this!). This step is important because the report writer software or drill-down tools do not recognize new totals tables that you create. The new totals table contains additional standard fields for storing totals. With the standard table, you can easily activate support for many scenarios by customizing the software. The table thus supports activities like:

•  Business area updating

•  Cost center updating (Field: RCNTR)

•  Cost-of-sales accounting

•  Functional area (Field: RFAREA)

•  Preparation for consolidation

•  Profit center updating (Field: PRCTR)

•  Segment reporting (Field: SEGMENT)

You can add other fields (SAP provides ready-made standard fields like “plant”) that are supported in the standard or in your own fields—known as customer fields—in the totals table with minimum effort. A mere extension of these fields to the new table is not sufficient; you must activate all such fields as enhancements for each of the ledgers. The new totals table can contain several ledgers that store period totals to combine characteristics. You can now create totals for fields like profit center, segment, and partner in addition to fields for general-ledger account, company code, and fiscal year.

b. Storing ledger-specific line items

Two new tables—FAGLFLEXA and FAGLFLEXP—store the ledger-specific line items (actual and planned) and contain additional information for use in the entry view. These tables let you update different characteristics and document-splitting information, different period shifts, and different currencies in specific ledgers for individual documents. These let you perform reporting tasks for specific dimensions at the line-item level and select data from fields that are not found in the single-item indexes (BSIS and BSAS) from the G/L in SAP R/3.

c. Valuations for year-end closing in selected parallel ledgers

A third table—BSEG_ADD—contains documents that are posted in connection with valuations for year-end closing in selected parallel ledgers. If you do not portray parallel accounting or you use the account approach to portray parallel accounting, these documents are inapplicable. This ledger will not have any split information. If you do not use additional ledgers, then this table will NOT be updated.

40.   WHAT IS THE MAJOR DIFFERENCE BETWEEN FAGLFLEXA AND FAGLFLEXT?

While the table FAGLFLEXT is used to store the ledger-specific line items in split form, the table FAGLFLEXA is used to store the split totals. The table FAGLFLEXA replaces the table GLT0 of Classic G/L.

41.   HOW DO YOU MAP TABLES BETWEEN CLASSIC AND NEW G/L?

Table 2.1-1 explains how the various tables of Classic G/L have been mapped to new tables in New G/L accounting.

TABLE 2.1-1  Classic and New G/L: Table Mapping

42.   WHAT ARE THE SEGMENTS IN NEW G/L ACCOUNTING?

With New G/L accounting, SAP used the segment field as a standard account assignment object. These segments are used to replace the account assignment objects (like business area, profit center, and profitability segment) used earlier. Now, the usage of segment reporting (below the company code level) gives a detailed look at the different activity areas of a company, such as business divisions, products, and markets, because these segments can be defined in addition to company codes, Controlling areas, profit centers, functional areas, business areas, and so on.

Similar to business area and functional area, segments are not assigned to any Controlling area or company code and are technically defined at the client level.

Once New G/L is activated, a “segment” field appears in the profit center master record.

43.   HOW MANY SEGMENTS CAN YOU HAVE IN TABLE FAGLFLEXT?

In a Classic G/L scenario, the special purpose ledger (FI-SL) has 45 object number tables, each with 15 key fields. The FI-SL totals table can contain a maximum of 45 key fields. These 45 key fields also contain some fixed standard fields like company code, G/L account, profit center, and segment. However, in New G/L, fields like company code, account, profit center, and segment are standard in the table key. In addition to that, two segments are available where the customer can include an additional 15 fields (other SAP standard fields like the plant- or customer-defined fields). It is important to note that a high number of additional fields can result in high data volume, which can cause performance problems in processes like reporting, foreign currency valuation, and allocation.

44.   HOW DOES THE BW DATA SOURCE LIKE FAGLXX REPLACE GLT0 IN NEW G/L?

The only data source for New G/L that SAP delivers is 0FI_G/L_10, which only extracts data from the leading ledger. If data from the non-leading ledger are requested, then you need to create the data source. With the change in the table logic with the table FAGLXX (New G/L) replacing GLT0 (Classic G/L), create the data sources using the Transaction Code FAGLBW03. Replace “xx” in the place-holder “3FI_G/L_xx_TT” with the ledger description. For example, for a ledger “LL, ” the data source will be “3FI_G/L_LL_TT.” In some cases an extract structure is required to create a data source. This structure has to be generated using transaction FAGLBW01. This has to be done if the ledger for which the data source is needed but is not based on the delivered standard totals table FAGLFLEXT (Figure 2.1-9).

Transaction Code
FAGLBW03

FIGURE 2.1-9  Assigning a Data Source to a G/L

45.   CAN A TOTALS TABLE BE USED TO MANAGE BOTH LINE ITEMS AND TOTALS?

No, there is no provision to manage both the line items and the totals in one table. The line items on totals need to be managed in different tables.

46.   HOW DO YOU ENHANCE AND BRING IN ADDITIONAL FIELDS TO A TOTALS TABLE?

SAP allows you to bring in additional fields (Figure 2.1-10) by:

•  Adding a standard field (like a material number). These fields can easily be added using the “customizing” function.

•  Adding a customer field. These fields are inserted using an “include” function in COBL.

FIGURE 2.1-10  Standard and Customer Fields in New G/L Setup

47.   WHAT IS THE CUSTOMER FIELD ENHANCEMENT IN NEW G/L?

Though SAP does not restrict or recommend on how many customer dimensions you need to have, note that this needs to be decided by implementation considerations because performance could be impacted by having too many customer fields. It is possible to work with a few different ledgers with one characteristic each. There is not much difference on extending the customer fields. If you have enhanced BSEG using COBL, technically you can do the same, but in New G/L, the new fields need to be inserted using an include called “CI_COBL” in COBL.

All such customer-defined fields are extended within the line-item structures and are available in the entry view for general inquiry/reporting. Fields can also be customized for inclusion in the totals table, making them available in the ledger view.

Note that only fields included in the totals table have balances carried forward.

48.   WHAT IS DOCUMENT SPLITTING IN NEW G/L?

The document splitting functionality in New G/L is a tool for determining missing account assignments according to problems in common accounting processes (like invoices, payments, or clearing). For each FI document, document splitting applies account-assignment information to nonassigned accounts according to the assignment rules set in the customizing area.

The document-splitting functionality is based on the following model:

Accounting documents contain accounts with assignments, such as revenues or expenses. Such accounts provide dependent accounts (accounts payables, accounts receivables, and taxes, for example) with account assignments based on context (such as invoices or payments). The model is process oriented. Account assignments from original processes are projected into the subsequent processes, thereby enabling account assignments according to problems in the subsequent processes.

Consider the example of a vendor invoice: You can assign profit centers to expense accounts manually, derive the assignment automatically, or make the assignment using a substitute cost center. Document splitting places these profit centers in the payables accounts of the invoice document.

This functionality can help you create balance sheets for entities that extend beyond the scope of the company code. Typical examples include balance sheets at the segment or profit center level or balance sheets based on company-specific or industry-specific entities. There are also mechanisms to determine all account assignments outside of document splitting in the delivering component itself. This determination would include postings from SAP human capital management or materials management application areas.

49.   WHAT ARE THE TWO TYPES OF DOCUMENT SPLITTING IN NEW G/L?

Document splitting is built at two technical points:

a.  Document creation

b.  Accounting interface

50.   HOW DO YOU DO DOCUMENT SPLITTING DURING DOCUMENT CREATION IN NEW G/L?

A classic example of document splitting during document creation is the clearing transaction wherein cash discount and realized exchange rate differences are split according to source (according to the proportions of the account assignments in the expense or revenue lines of the original document, such as an invoice). What is special here is the specific reference to the original transaction or line item. Controlling functions in the software are updated accordingly and reconciled with the G/L accounting functions.

Another example of item-related document splitting is foreign currency valuation of open items. This function transfers exchange rate differences to the Controlling software. It is important to note that the balance-valuation function has no reference to items or transactions. Here, the dimension-specific balance of the account (such as the balance for each segment) is used as the basic value.

51.   HOW DO YOU DO DOCUMENT SPLITTING AT ACCOUNTING INTERFACE?

Technically, the process of document splitting (Figure 2.1-11) at accounting interface has two levels of details:

1.  The standard account-assignment projection, which results from customized settings. Account assignments are projected from the base rows to the target rows. To minimize the effort required for implementation, SAP ERP provides a number of preconfigured methods. You can activate only one method per client. With method “0000000012, ” the solution delivers settings that support most standard processes (such as invoice, payment, or payment on account).

FIGURE 2.1-11  Document Splitting Methods

2.  The inheritance by subsequent processes of business transactions, such as the clearing of vendor and customer invoices. With this variant, the solution transfers the original account assignments of the invoice to the clearing lines. This variant is a fixed feature in the program and cannot be altered. After the clearing transaction, the original item (such as the payables or receivables line) and the clearing item for the respective account assignment are balanced to zero (Figure 2.1-12).

FIGURE 2.1-12  Document Splitting: Levels of Details

52.   HOW IS DOCUMENT SPLITTING IN NEW G/L DIFFERENT FROM SPLITTING IN SAP R/3 FI-SL?

The document split function in New G/L has been enhanced as follows:

•  Additional functions from SAPF181, such as post-capitalization of assets and the splitting of follow-up costs (discount, currency differences, and so on).

•  The split information is also available for the closing activity in FI (foreign currency valuation, regrouping, and so on, and therefore also at the segment level).

•  CO-relevant valuation postings (for example, expense from exchange rate differences) can be transferred to CO in split form.

53.   HOW DOES PROFIT CENTER/SEGMENT SPLITTING OCCUR FOR B/S-ONLY ENTRIES?

The value for profit center/segment must be entered or derived in order to produce an offsetting split or zero-balancing transaction item in the G/L view of the document. The splitting rules can be configured to assist with this, provided the process is clearly defined and appropriate accounts/document types are consistently used.

54.   HOW DOES DOCUMENT SPLITTING WORK FOR RESIDUAL POSTINGS?

You should pay attention to some of the considerations/cautions of document splitting on residual postings. For example, have you considered what happens if the profit center or segment is changed in the system prior to a residual posting being completely cleared?

All clearing postings utilize a passive split, whereby the original split information about the item is used as the basis for the clearing update.

55.   WHAT HAPPENS IF YOU ACTIVATE/DEFINE “DEFINE SPLITTING CHARACTERISTICS FOR CO” IN IMG?

This depends on the characteristics supplied by SAP and the characteristics of the customer. The characteristics that are stored here can be transferred in split from CO in connection with the determination of the follow-up cost (like foreign currency valuation, realized exchange rate difference, discount, etc.). The only precondition is that the G/L account should have been created as a cost element.

56.   CAN A SEGMENT ASSIGNMENT (VIA THE PROFIT CENTER) BE OVERRIDDEN ON AN FI POSTING?

Yes, it can. During data entry it is possible to overtype/override (manual entry) the segment relationship. However, note that this may/may not be desirable. Instead you should go in for a substitution routine to enforce the relationship so the manual overriding is not allowed.

57.   WHAT IS THE ZERO BALANCE SWITCH IN DOCUMENT SPLITTING?

When you set this indicator in customizing the characteristics for document splitting, the system will check to see if the balance is zero for that characteristic (Figure 2.1-13). If the balance is not zero, then the system creates additional clearing lines on clearing accounts to produce a zero balance. This checkbox needs to be selected only when you need to report a balance on that particular characteristic (say, profit center).

FIGURE 2.1-13  Document Splitting Characteristics for G/L

58.   WHAT IS THE MANDATORY FIELD SWITCH IN DOCUMENT SPLITTING?

When you set this indicator in customizing the characteristics for document splitting, then all the postings for which no value is set after the document split for that specified field are rejected by an error message. You should not select this if you want these postings to take place even though no value is set after the splitting. But you need to be aware that the complete balance of that dimension is at risk.

59.   CAN YOU SELECTIVELY DEACTIVATE DOCUMENT SPLITTING IN A FEW COMPANY CODES?

Yes. The activation of document splitting, by default, applies to the entire client. However, you can exclude company codes for which you do not need this splitting functionality. But note that once you exclude certain company codes from document splitting, you will no longer be able to create any cross-company code transactions with the splitting functionality (Figure 2.1-14).

FIGURE 2.1-14  Document Splitting: Deactivate for Select Company Codes

60.   HOW HAS PROFIT CENTER ACCOUNTING BEEN MAPPED TO NEW G/L?

You need to (a) define the update of the characteristics profit center and partner profit center in the ledger by selecting the scenario “Profit Center Update” (FIN_PCA), and (b) define the field “profit center” as a splitting characteristic in the document splitting. Now to create a balance sheet on the profit center, you just need to set the “zero balance” indicator. The last thing you must do is activate the required entry field to ensure that the profit center is set in all postings.

61.   WHAT IS EXTENDED DOCUMENT SPLITTING?

SAP provides you with the standard document functionality with default splitting rules/methods. In case the standard functionality is not sufficient, you can create your own rules/methods and make any necessary settings so the system applies the rules/methods you defined and not the standard ones. When you use your own document splitting rules/methods, this is known as extended document splitting. It is important to note that you will not be able to switch between the standard rules and your own rules.

62.   WHAT ARE THE VARIOUS METHODS TO ACHIEVE FAST CLOSING?

Most of the closing tasks are organization-specific. Depending on your SAP implementation and your requirements, you can use some or all of the following methods to achieve fast closing in your organization:

•  Elimination of reconciliation ledger postings by enabling real-time CO to FI integration

•  Elimination of profit and loss (P&L) and balance sheet adjustments with online splitting functionality

•  Elimination of transfer payables/receivables to profit center accounting (PCA) by using segment reporting in New G/L

•  Elimination of PCA allocation by using New G/L allocations

•  Use of a Closing Cockpit to obtain a simplified overview of the entire closing process

•  Use of cross-system intercompany reconciliation to speed up intragroup reconciliation processes

63.   HOW DO YOU ELIMINATE RECONCILIATION LEDGER POSTINGS?

It is now possible to completely eliminate reconciliation ledger postings by enabling the real-time CO-to-FI integration, using New G/L functionality in SAP ERP (Figure 2.1-15).

FIGURE 2.1-15  Reconciliation Posting Using Transaction Code KALC

Though real-time integration from FI to CO has been available since SAP R/2, when a posting involved cross-company codes (or business areas), this information was stored initially in CO and then transferred to FI at period close (Figure 2.1-16). The reconciliation ledger, which was maintained in the CO module, was used for CO reconciliation with FI. Typically, you would execute the transaction KALC (reconciliation ledger posting) at each period end, thereby creating FI documents to reconcile CO with FI. The drawback was that the reconciliation postings were not created on the cost-object level, and it was difficult to match the FI reconciliation posting with the corresponding CO transaction postings.

FIGURE 2.1-16  Variant for CO-to-FI Real-Time Integration

In New G/L, using the reconciliation ledger is not recommended because you cannot have segment or profit center details in the reconciliation posting, which can cause problems for reconciliation and segment reporting. So you need to deactivate the reconciliation ledger before the CO postings are updated online in the reconciliation ledger and enable real-time integration CO and FI.

To enable real-time CO-FI integration, you need to define variants that control the integration. These variants define the cases in which CO transactions create financial documents. For example, you can set up a variant so that any cross-company, cross-profit center, cross-segment, and functional area CO postings create FI follow-up documents. Define the variants by following the menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Real-Time Integration of Controlling with Financial Accounting > Define Variants for Real-Time Integration.

Once the variants are defined, you need to assign them to the company codes, define rules for selecting CO line items, and set up the account determination (to transfer secondary cost element postings to FI, because they are not defined as G/L accounts) for the integration.

64.   HOW DO YOU TRANSFER CO DOCUMENTS RETROSPECTIVELY?

When you enable real-time CO-to-FI integration, you always specify a date known as “Key Date: Active from.” Then the integration happens for all the postings on or after this key date, but not before (Figure 2.1-17).

FIGURE 2.1-17  Retrospective Transfer of CO Documents to FI

SAP provides functionality for transferring documents retrospectively (in a situation where your New G/L was active, say, from January 1, 2009, but this real-time CO-to-FI integration was activated only on June 28, 2009).

Transaction Code
FAGLCOFITRNSFRCODOCS

You may also use the menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Real-Time Integration of Controlling with Financial Accounting > Transfer CO Documents Retrospectively.

65.   HOW DO YOU ELIMINATE P&L/BALANCE SHEET ADJUSTMENTS BY ONLINE SPLITTING?

Before New G/L, at period-end programs, SAP F180 (balance sheet adjustment) and SAP F181 (P&L adjustment) populated the cost objects details in the offsetting lines based on the original cost objects in PCA. It was time consuming to verify, reconcile, and explain the adjustment postings. With the profit center accounting (PCA) now integrated into New G/L accounting with SAP ERP, the online splitting and zero balancing functions enable you to create balance sheets not only for company codes but also for entities such as the profit center and segment. As a result, it is no longer necessary to execute a periodic adjustment posting for balance sheet and P&L statements, because all information is already available on the document level in New G/L. The elimination of these programs significantly speeds up the closing process.

66.   HOW DO YOU ELIMINATE TRANSFER PAYABLES/RECEIVABLES TO PCA BY SEGMENT REPORTING?

You can now eliminate the transfer of payables/receivables to PCA using segment reporting in New G/L. With New G/L segment reporting functionality, profit center/segment details are updated in the G/L in real-time, so you do not need to update PCA to get segment reporting. These reports are now available in New G/L. It is no longer necessary to transfer balance sheet items to PCA periodically for segment reporting. In other words, you can eliminate transferring balance sheet items to profit center accounting from the period-closing process. Although PCA is integrated into New G/L, it does not mean you have to turn off PCA. You can still use PCA parallel to New G/L and continue to use the adjustment programs (Figure 2.1-18).

Transaction Code
1KEK

FIGURE 2.1-18  Transfer Payables/Receivables Elimination

67.   HOW DO YOU ELIMINATE PCA ALLOCATIONS BY USING NEW G/L ALLOCATIONS?

The distribution and assessment functionality from profit center accounting (PCA) and FI-SL are available in New G/L. This enables criteria-based amount distributions on the cost-object (segment, profit center) level in the G/L. Define the cost allocations in the SAP easy access menu path: Accounting > Financial Accounting > General Ledger > Periodic Processing > Closing > Allocation > Actual Distribution. It uses cycle and segment methods to define distribution and assessment rules (Figure 2.1-19).

Transaction Code
FAGLGA31

FIGURE 2.1-19  Eliminating PCA Allocations through New G/L Allocations

Other functions from FI-SL, such as rollup and planning, are also part of New G/L. You can execute these tasks directly in New G/L. You have a unified data structure instead of multiple related databases, which gives you the advantage of eliminating reconciliation tasks.

Even though the cost allocations in the profit center and New G/L both depend on the same logic, you need to take note of the following:

•  Actual cycles should always be assigned to version-1 because the system updates actual postings in New G/L in version-1. To manage various planning scenarios, you can create planning versions in customizing. To maintain planning versions in New G/L, use the Transaction Code GCVP.

•  Assessment accounts should be created in New G/L and should be different from the secondary cost elements.

•  Both distribution and assessment create FI postings.

And you also need to be aware that the cost center allocations are still in CO and should be performed in cost center accounting.

68.   WHAT IS A CLOSING COCKPIT?

An extension of the schedule manager functionality, the Closing Cockpit is a new concept in SAP ERP, which you can use for scheduling the tasks you execute on a regular basis (Figure 2.1-20). Using the same logic as the schedule manager, it provides a simplified overview of the entire closing process, and you can define all your closing tasks on a single screen.

FIGURE 2.1-20  Closing Cockpit

With the Closing Cockpit, the closing process becomes more transparent, and you can find errors easily because you will be able to schedule, execute, and monitor your tasks for a selected organizational level.

Transaction Code
CLOCOC

69.   HOW DO YOU USE THE CLOSING COCKPIT?

To effectively use the Closing Cockpit, you need to follow four steps:

1.  Define organizational hierarchies and template

Define your organizational hierarchy (for example, company code) so the system executes the closing process for the defined organizational structure(s) (Figure 2.1-21). From Closing Cockpit, select “Template/Task List” on the menu bar, and then select “Organizational Hierarchies” to define/select the hierarchy for the template (the system generates a proposal for a task list template according to the selected hierarchies and organizational objects available in the system).

FIGURE 2.1-21  Defining Organizational Hierarchy

2.  Define folders and create tasks

The system generates sample folders (such as Payroll, Sales and Distribution, Financial Accounting, Asset Accounting, etc.) categorizing the closing tasks (Figure 2.1-22).

FIGURE 2.1-22  Folders and Tasks

You can delete/change the existing folders or create new folders. Once the folders are defined, create the closing tasks in the folders (by right-clicking on the relevant folder or by copying/changing an existing task).

Note that SAP delivers templates in the standard business context for month-end closing (“1-FC-MONTH”) and year-end closing (“1-FC-YEAR”) that you can map to your own organization.

It is possible to define all the steps in the overall process in the task list template as a note, transaction, program (with or without a variant), or flow definition (Figure 2.1-23).

FIGURE 2.1-23  Type of Task

•    Define dependencies

Programs and transactions included in the task list template are frequently dependent on each other due to business-related or system-related factors. You can define a finish-to-start dependency so the dependent tasks do not start until the prerequisite task completes successfully. You can do this by dragging and dropping the successor task into the dependencies area. Then you insert the predecessor task by right-clicking on the successor task and choosing “Insert Dependency” (Figure 2.1-24).

FIGURE 2.1-24  Dependencies

For example, the “Post-Depreciation” task is dependent on tasks like “Check Incomplete Assets (RAUNVA00).” When you drag to build the dependencies, the system inserts the relevant dependent tasks. The system can only start the successor task (“Post-Depreciation” task in the example here) automatically if all the predecessor tasks have the processing status terminated without errors.

•    Create and release the task list

To perform tasks included in a task list, you need to create variant parameters. With the separation of the task list template from the task list, you can define the structured process flow as a generic template (task list template) and then make a task list available for processing with specific parameter values. The task list generated from the task list template automatically updates the time-related program parameters of the selection variants when you enter corresponding header information in the task list.

CHAPTER

3

ACCOUNTS PAYABLE AND
(FI-A/P)/ACCOUNTS
RECEIVABLE (FI-A/R)

1.     WHAT IS A CUSTOMER?

In SAP, a customer is known as a business partner from whom receivables are due as a result of services rendered—that is, goods delivered, services performed, rights transferred, and so on. A customer in SAP is represented by a master record.

2.     WHAT ARE CUSTOMER/VENDOR MASTER RECORDS?

There are three categories of data maintained in a typical master record for a customer (Figure 3.1):

•  General data

•  Company code data

•  Sales area data (for customers)/purchasing organization data (for vendors)

FIGURE 3.1  Vendor Master Record—Various Data

The general data include general information like account number, name, telephone, bank information, trading partner, vendor (if the customer is also a vendor), group key, bank key, bank account, alternate payee, and so on that are common to all the company codes using this master.

The company code data contain terms of payment, payment methods, tolerance group, clearing with vendor, dunning data (dunning procedure, dunning recipient, dunning block, dunning clerk, etc.), reconciliation account, sort key, sales area (purchasing organization in the case of vendor master), head office, and more. Except for sales (purchasing for a vendor) information, all other details are usually maintained by the accounting people who can also access the sales data/purchasing data when the master is maintained centrally.

The sales area data in the company code area of a customer master record contain the following:

•  Billing data (payment terms if different from the payment terms maintained at the company code level, account assignment group, etc.)

•  Order related (sales district, sales office, sales group, customer group, etc.)

•  Price related (pricing group, pricing procedure, etc.)

•  Shipping data (shipping strategy, delivery priority, etc.)

Transaction Code

The purchasing organization data (Figure 3.2) in the company code area of a vendor master record contain the following:

•  Conditions (order currency, payment terms, incoterms, minimum order value, etc.)

•  Sales data (account with vendor)

•  Control data (as in the screenshot below)

FIGURE 3.2  Vendor Master Record—Purchasing Data

During creation of a master record, the system checks for duplicates for the same customer with “Search-ID” (Match Code) configured on the customer’s/vendor’s address information.

As in the case of the G/L account master record, the creation of a customer/vendor master record is also controlled by the account group called “customer account group/vendor account group” (CPD/CPDL/KREDI/LIEF), which controls the numbering for customer/vendor master records, field status, and whether an account is a regular one or a “one-time” account, among other factors.

3.     WHAT ARE ONE-TIME ACCOUNTS?

When you face a situation where you have customers you only supply one time or only a few times, you can create a special customer master record for such one-time accounts. Unlike regular master records, no data specific to a single customer are stored in the one-time master record, because this account is used for more than one customer. All the customer-specific data (like address, bank details, etc.) are not entered until the document for the transaction is entered into the system. When you post to a one-time account, the system automatically goes to a master data screen. Here you will enter the specific master data for the customer, which is stored separately in the document. Otherwise, you can process the master record for a one-time account in the same way you process all other customer master records. You can also dun open items from it with the dunning program or pay items using the payment program. However, you cannot clear amounts with a vendor.

Because the customer master records for one-time accounts are created with their own account groups, the customer-specific fields (such as name, address, and bank details) are hidden from display when you enter the customer master record. In the case of reconciliation accounts for one-time customers, it is possible to have two different reconciliation accounts for domestic and foreign receivables. For this, you need to create two one-time master records.

4.     WHAT IS AN ALTERNATE PAYEE?

A customer who pays on behalf of another customer is known as an alternate payee (or alternate payer). Though the alternate payee pays on behalf of another, the system maintains all the transaction details in the account of the original customer. Designating “alternate payee” does not absolve the customer of his or her obligation to pay.

The alternate payee can be maintained in client-specific data or the company code area. When maintained in the company code area, you can use that payer only in that company code. If it is defined at the client level, you can use the same across all company codes.

There are three ways of selecting the alternate payee when an invoice is processed:

1.  The alternate payee (say, 1000) entered in the customer master record is the one selected by the system as default.

2.  When there is more than one alternate payer (say, 1000, 1900, 2100, etc.) defined for a single customer in the master record (you will do this by clicking on the “allowed payer” button and create more than one payer), you may select a payer (say, 2100) (other than the default, 1000) while processing the invoice. Now the system will ignore the alternate payer (1000) coming from the master record.

3.  If you have put a tick mark in the “individual entries” checkbox in the “alternate payer in document” section in the customer master record, then this will allow you to propose a new alternate payer—say, 3000 (other than those already defined in the system). Now, after defining this alternate payer, you can use the same in processing the invoice. In this case, this alternate payer (3000) takes precedence over the payers (1000 and 2100) in steps 1 and 2.

5.     HOW IS A TRADING PARTNER USED?

A trading partner is used to settle and reconcile intercompany transactions: both sales and purchases. This is generally achieved by entering the company ID (NOT the company code) to which a customer belongs in the “trading partner” field under the tab “account control” in the customer master record. You can do a similar entry in the vendor master record.

6.     WHAT IS BLOCKING A CUSTOMER ACCOUNT?

A customer can be blocked centrally or for posting only. It is possible to block a customer in all the company codes or in only one company code. You can block a customer account for a variety of reasons:

•  You can block a customer account so postings are no longer made to that account.

•  You will block a customer account before marking a customer master record for deletion.

•  It may also be necessary to block a customer that you use only as an alternative dunning recipient so nobody can post to that customer by mistake.

•  You can block a customer for payment. When blocked for payment, the payment program still processes the open items in the account during the payment run, but it does not pay any open items from the blocked accounts. However, you can display a list of customers blocked for the payment program.

•  You can block a customer for dunning. When you block an account for dunning, the dunning program still analyzes the open items in the account during the dunning run, but no dunning notice is created.

When you have also implemented the sales and distribution (SD) application component, the following blocks are possible for a customer:

•  Posting block

•  Order block

•  Delivery block

•  Invoicing block

Because you will not be able clear any open item, it is recommended that you block a customer account only when there are no open items in that account. Of course, you can cancel a customer account block at any time by simply removing the relevant block indicator.

7.     CAN YOU ARCHIVE A CUSTOMER MASTER RECORD IMMEDIATELY?

It is possible to archive customer master records that are no longer required. When archived, the data are extracted from the SAP database, deleted, and placed in a file so you can then transfer this file to an archive system. However, you will not be able to archive a customer account immediately because the system first has to check the following:

•  Is there a transaction figure for that account in the system?
The account must not contain any transaction figures in the system. Transaction figures from previous years that have not been archived will also prevent the system from deleting the account master record.

•  Is the account marked for deletion?
The account must be marked for deletion (using the deletion flag) in its master record. But remember to block an account for posting before you mark it for deletion.

Note that when you mark a customer master record for deletion, you can set the deletion flag for all company codes or just for one specific company code. Even after the deletion flag has been set for a customer account, you can still cancel the deletion flag at any time as long as the master record has not yet been physically deleted from the system.

8.     CAN YOU POST TO A CUSTOMER ACCOUNT THAT IS MARKED FOR DELETION?

You can still post to an account that has already been marked for deletion because you might still need to clear open items. When you post to an account that is marked for deletion, the system just issues a warning that you are posting to an account that is marked for deletion. It does not prevent you from posting to that account.

9.     CAN YOU ASSIGN A CUSTOMER/VENDOR MASTER RECORD TO A BUSINESS AREA?

It is not possible to assign customer/vendor master records to a business area. The business area is usually determined from the business area(s) assigned to the related G/L account posting(s), and therefore you do not have to carry out the account assignment manually.

In an invoice, the customer/vendor item takes the business area(s) of the expense or revenue posting. If the business area is unique in the document (the system checks that any business area entered in the customer/vendor item is the same as that in the offsetting G/L account item and issues an error message if this is not the case), it is copied into the line item automatically. If there is more than one business area, no value is entered in the customer/vendor item and a transfer posting to the receivables/payables account is carried out subsequently.

The taxes are always posted without a business area. The system then, at a later date, makes a transfer posting from the tax account to the business areas for the revenue or expense accounts.

During payments, customer/vendor items in payment documents take the business area from the invoice. The cash discount and exchange rate difference postings take their business area from the customer/vendor item from which they originated. If posted without a business area, and the business area is only determined subsequently by means of a transfer posting to the GL, note that you need to carry out this subsequent step for the cash discount and exchange rate postings.

The system cannot automatically derive the business area that triggers the down payments because the invoice that belongs to the down payment is not entered until later. The business area in the customer/vendor item is therefore either not assigned or is assigned manually.

Like taxes, the bank item is posted without a business area (unless one is assigned manually).

10.   WHAT IS TOLERANCE IN TRANSACTION PROCESSING?

Tolerances are defined in the system to facilitate dealing with the differences arising out of accounting transactions and to instruct the system on how to proceed further (Figure 3.3). Normally, you define tolerances (either in absolute terms or in percentages) beyond which the system will not allow you to post a document should there be differences.

In SAP, tolerances are defined per company code, and there are several types:

•  Employee tolerance

•  Customer/vendor tolerance

•  G/L account clearing tolerance

You will define employee tolerance groups in the system and assign the employees to these groups. While defining the tolerance group, you will specify:

1.  Upper limits for various posting procedures

•  Amount per document

•  Amount per open account item

•  Cash discount, in percent

FIGURE 3.3  FI Tolerance Group (Employee Tolerance)

2.  Permitted payment differences

How much over or under payment an employee is allowed to process. This is defined both in absolute value and in percentages.

Besides defining the above two, at the company code level, you will also define similar tolerances for customer/vendor tolerance groups (say, DEB1) (Figure 3.4). Once defined, each of the customers (vendors) is assigned to one of these groups. Here also, you define the “permitted payment differences”:

FIGURE 3.4  Customer/Vendor Tolerances

While processing, the system compares the tolerance of an employee with the customer tolerance (or vendor tolerance or the G/L) and applies the more restrictive of the two.

11.   WHAT IS DUAL CONTROL IN MASTER RECORDS?

Dual control helps to prevent unauthorized changes to the important and sensitive fields in the master records in the system. (All such sensitive fields are defined in the Table T055F during customizing the application, and these fields are defined per company code and per client.) Consider, for example, a sensitive field like “payment block” in a vendor master record. When a user changes this field’s content, the system requires another user (usually of higher authority) to approve this change, and an audit trail is maintained of all such changes. Unless the change is approved, in this example, this particular master is blocked by the system for considering the same in the next payment run.

Transaction Code

Activity

Customer

Vendor

Display changes (accounting area)

FD04

FK04

Display changes (centrally)

XD04

XK04

Confirm changes, individually

FD08

FK08

Confirm changes, in a list

FD09

FK09

12.   WHAT IS A SALES CYCLE IN SAP?

The sales cycle consists of all activities starting from quotation/inquiry, sales order, delivery, billing, and collection (Figure 3.5). The various processes in SAP to complete a sales cycle are shown in Figure 3.5.

Typically, the following are the documents created during a sales cycle:

•  Inquiry

•  Quotation

•  Sales Order

•  Delivery Note

•  Goods Issue

•  Order Invoice

•  Credit/Debit Note

FIGURE 3.5  Sales Cycle

13.   WHAT IS AUTOMATIC ACCOUNT ASSIGNMENT IN SD?

During goods issue in the sales cycle, the system is usually configured to update the relevant G/L accounts automatically and to create the relevant accounting documents (Figure 3.6). This customization in IMG is also called material account assignment and is achieved through a number of steps:

1.  Determine valuation level (company code or plant).

2.  Activate valuation grouping code and link the same with chart of accounts for each valuation area.

3.  Link valuation class with material type (FERT, HAWA, HALB, etc.) with account category reference (combination of valuation classes).

4.  Maintain account modification codes for movement types.

5.  Link account modification codes with process keys (transaction/event keys).

6.  Maintain a G/L account for a given combination of chart of accounts + valuation grouping code + account modification code + valuation classes.

FIGURE 3.6  Automatic Account Determination in SD

The process of automatic account determination is as follows:

1.  Depending on the plant entered during goods issue (GI), the company code is determined by the system, which in turn determines the relevant chart of accounts.

2.  The plant thus entered in goods issue determines the valuation class and then the valuation grouping code.

3.  The valuation class is determined from the material master.

4.  Because the account modification code is assigned to a process key that is already linked to a movement type, the transaction key (DIF, GBB, AUM, BSX, etc.) determines the G/L account because posting transactions are predefined for each movement type in inventory management.

14.   WHAT IS ACCOUNT DETERMINATION IN SD?

The billing documents created during the sales cycle result in automatic postings to G/L accounts on the FI side (Table 3.1). In general, account determination is based on the following five factors:

•  Chart of accounts

•  Sales organization

•  Account assignment group of the customer

•  Account assignment group of the material

•  Account key

The system determines the chart of accounts from the company code in the billing document, and the sales organization is determined from the corresponding sales order. The account assignment group is taken from the respective masters of customer/material. The account key helps the user to define the various G/L accounts, and this key is assigned to the condition type (KOFI) in the pricing procedure.

TABLE 3.1  Account Determination in Sales and Distribution

These G/L accounts are automatically (see Table 3.1) determined when you make the following configuration in the system:

1.  Assigning an account determination procedure to a billing document type

2.  Assigning this account determination procedure to a condition type

3.  Assigning this condition type to an access sequence

4.  Configuring the condition tables

15.   WHAT IS CREDIT MANAGEMENT IN SAP?

Credit management helps in determining credit limits of customers, aids in the creation of credit check policies, and helps companies monitor and evaluate their customers. This is a cross-functional responsibility in SAP, covering both the sales and distribution and Financial Accounting modules.

As in the case of any automated process like dunning, payment, and so on, credit management in SAP requires certain prerequisites to be defined beforehand:

1.  Customer master data is created both in SD and FI.

2.  Credit control area has been defined and assigned to company code (Figure 3.7).
SAP uses credit control area for credit management. As explained elsewhere, credit control area is an organizational element defined to which one or more company codes are attached. In the case of customers defined under more than one company code, they may fall under different credit control areas. But note that:

•  A client can have more than one credit control area, but the converse is not true. One credit control area cannot be assigned to more than one client.

•  A credit control area can be assigned to more than one company code, but the converse is not true. One company code cannot be assigned to more than one credit control area.

While defining the credit limit for a customer:

•  You will define a maximum limit per credit control area (example: credit control area AAAA > USD 500, 000, credit control area BBBB > USD 200, 000).

•  You will define a global maximum limit for all credit control areas put together (USD 600, 0000).

3.  Credit data (per credit control area maximum limit, as well as the total for all areas, in the control data screen) for the customer has been created.

4.  Risk categories have been defined and assigned to customers.

5.  Credit groups (document credit group) for document types have been defined. Document credit groups combine order types and delivery types for credit control.

6.  Defined in SD at what time (when the order is received or when a delivery is made, etc.) the credit check should happen.

FIGURE 3.7  Client–Credit Control Area–Company Code–Customer

16.   WHAT IS THE CREDIT MANAGEMENT PROCESS IN SAP?

The credit management process starts when a sales order is entered in SD. Imagine this leads to exceeding the credit limit defined for the customer. Now:

1.  The system creates three comparison totals considering (1) open receivables; (2) sales order values, value of goods to be delivered, and billing document value from SD; and (3) special G/L transactions (e.g., down payments and bills of exchange).

2.  Based on #1, the system throws (1) an error message and prevents saving the order or (2) a warning message and the system does not prevent saving the order, but the order is blocked.

3.  Credit representative, using the information functions (SD information system, FI information system, credit overview, credit master list, early warning list, oldest open item, last payment, customer master, account analysis, etc.), processes this blocked order from either the blocked SD documents list or the mailbox and releases the order, if necessary.

4.  Delivery is created, the billing document is generated and posted, and A/R is updated.

5.  Customer pays the invoice, and A/R is posted.

17.   WHAT IS A CREDIT CHECK?

A credit check is defined for any valid combination of the following:

•  Credit control area

•  Risk category

•  Document credit group

18.   WHAT IS THE DIFFERENCE BETWEEN A STATIC CREDIT CHECK AND A DYNAMIC CHECK?

Under a static credit check, the system calculates the credit exposure of a particular customer as the total of:

a.  Open order (delivery not yet done)

b.  Open delivery (value of deliveries yet to be invoiced)

c.  Open billing documents (not transferred to accounting)

d.  Open items (AR item not yet settled by the customer)

The customer’s credit exposure is not to exceed the established credit limit.

A dynamic credit check is split into two parts:

•  Static limit: Total of open items, open billing, and open delivery values

•  Dynamic limit (open order value): The value of all undelivered and partially delivered orders totalled and stored on a time-scale in the future (10 days, 1 week, etc.) known as the horizon date.

During the dynamic credit check, the system will ignore all orders beyond the horizon date. The sum total of static and dynamic limits should not exceed the credit limit established for the customer.

19.   WHAT REPORTS ARE IN CREDIT MANAGEMENT?

SAP provides you with the following reports in credit management:

•  RFDKLI10

Customers with Missing Credit Data

•  RFDKLI20

Reorganization of Credit Limit for Customers

•  RFDKLI30

Short Overview of Credit Limit

•  RFDKLI40

Overview of Credit Limit

•  RFDKLI41

Credit Master Sheet

•  RFDKLI42

Early Warning List (of Critical Customers)

•  RFDKLI43

Master Data List

•  RFDKLI50

Mass Change of Credit Limit Data

•  RVKRED06

Checking Blocked Credit Documents

•  RVKRED08

Checking Credit Documents That Reach the Credit Horizon

•  RVKRED09

Checking the Credit Documents from Credit View

•  RVKRED77

Reorganization of SD Credit Data

20.   WHAT IS THE DIFFERENCE BETWEEN A PARTIAL PAYMENT AND A RESIDUAL PAYMENT?

When processing the incoming payment to apply to one or more of the open items of a customer, there may be a situation where the incoming payment is more than the tolerances allowed. In this case, you can still go ahead and process the payment by resorting either to partial payment or residual payment.

Partial payment results in posting a credit to the customer’s open item, but leaves the original item intact. As a result, no open item is cleared. During partial payment, the system updates the “invoice reference” and “allocation” fields.

The residual payment clears the particular open item against which the payment is applied. However, because there are not enough amounts to clear the entire open item, the system creates a new open item as the difference between the original invoice item and the payment applied. Note that the new invoice/open item created by the system will have the new document date and new baseline date, though you can change these dates.

21.   WHAT IS A PAYMENT ADVICE?

A payment advice helps in automatic searching of open items during the clearing process to match an incoming payment. This is possible because of you can use the payment advice number instead of specifying parameters in the selection screen. A typical payment advice may contain details like the document number, amount, currency, reason for under payment, and so on. The payment advices are of various categories. The first 2 digits of the payment advice number distinguish one payment advice from another:

•  Bank advice

•  EDI advice

•  Lockbox advice (created during clearing process, available in the system whether or not clearing was successful)

•  Manual advice

•  Advice from a bank statement

Most of the payment advices are deleted as soon as the clearing is successful in the system.

22.   HOW DO REASON CODES HELP IN INCOMING PAYMENT PROCESSING?

Reason codes configured in the system help to handle the payment differences of individual open items in an invoice (either using payment or advice or in the normal course). To each of the reason codes, you will define the posting rules and the G/L accounts in the IMG.

Once done, when there is a payment difference against a particular open item, the system looks for the reason code:

•  When the charge-off indicator has been set for that reason code, then the system posts the payment difference to a G/L account. When this indicator is not set, then a new open item is created for the payment difference.

•  When the disputed item indicator has been set, then the system ignores these line items from counting for the customer’s credit limit.

23.   WHAT IS DUNNING IN SAP?

The SAP system allows you to dun (remind) business partners automatically (Figure 3.8). The system duns the open items from business partner accounts. The dunning program selects the overdue open items, determines the dunning level of the account in question, and creates dunning notices. It then saves the dunning data determined for the items and accounts affected. You can use the dunning program to dun both customers and vendors. It may be necessary to dun a vendor in the case of a debit balance as a result of a credit memo.

Dunning is administered through a Dunning Program that uses a dunning key (to limit the dunning level per item), a dunning procedure, and a dunning area (if dunning is not done at the company code level).

FIGURE 3.8  Dunning Key

Transaction Code
F150

24.   WHAT IS A DUNNING PROCEDURE?

SAP comes delivered with a number of dunning procedures that you can copy and use to create your own (Figure 3.9).

Transaction Code

FIGURE 3.9  Dunning Procedure List

A dunning procedure controls the following (Figure 3.10):

•  Dunning interval/frequency

•  Grace days/minimum days in arrear

•  Number of dunning levels (at least one level)

•  Transactions to be dunned

•  Interest to be calculated on the overdue items

•  Known or negotiated leave, if any, that needs to be considered in selecting the overdue items

•  Company code data like (a) Is dunning per dunning area?; (b) Is dunning per dunning level?; (c) the reference company code; and (d) the dunning company code

•  Dunning forms/media to be selected for the dunning run

FIGURE 3.10  Dunning Procedure Overview

25.   WHAT IS A DUNNING AREA?

A dunning area is optional, and it is required only if dunning is not done at the company code level. The dunning area can correspond to a sales division, a sales organization, and so on. The individual dunning areas can use different procedures or the same dunning procedure.

The dunning areas with the required dunning procedures are to be entered into the customer or vendor master record if you use different dunning procedures. Otherwise, the system uses the standard dunning procedure. The dunning area is then entered in the line item. The system enters the dunning area into the master record automatically with the corresponding data.

Transaction Code
OB61

26.   WHAT IS THE DUNNING PROCESS?

The dunning process involves three major steps:

1.  Maintaining dunning parameters

As the first step in dunning, you need to maintain certain parameters that identify the current dunning run. Entering the date of execution and the dunning run identifier is the starting point, after which you will continue to maintain other parameters like:

•  Dunning date to be printed on the notice

•  Document posted up to

•  Company code

•  Account restrictions (optional)

Now you can save the parameters and display the log generated (to see if there were any errors), the dunning list (list of accounts and items), and some dunning statistics (blocked accounts/items, etc.).

2.  Creating dunning proposals

Once scheduled, the dunning program prepares the dunning proposal as follows:

(a)  The dunning program determines which accounts to dun:

i.  System checks the fields “Dunn.procedure” and “Last dunned” in the customer master record to determine whether the arrears date or the date of the last dunning run lies far enough back in the past.

ii. Checks whether the account is blocked for dunning according to the “dunning block” field in the customer master record.

iii. Program processes all open items, relating to the accounts thus released in (ii) that were posted to this account on or before the date entered in the field “Documents posted up to.”

iv. Program checks all the open items, as released in (iii), in an account to decide:

•  Is the item blocked?

•  Is it overdue according to the date of issue, the base date, the payment conditions, and the number of grace days granted?

v.  Program then proceeds to process all open items thus released in (iv):

•  How many days is the item overdue?

•  Which dunning level is used for a particular open item?

vi. Program determines the highest dunning level for the account based on (v). The highest dunning level determined is stored in the master record of the account when you print the letters. This dunning level determines the dunning text and a special dunning form, if defined.

vii. Program then proceeds to check each account:

•  Do the customers/vendors have a debit balance with regard to all open overdue items selected?

•  Are the total amounts to be dunned and the percentages of all open items more than the minimum amounts and percentages defined in the dunning procedure?

•  Is the dunning level for the account or the overdue items higher than it was for the last dunning run? If not, are there new open items to be dunned (with a previous dunning level of 0)? If not, does the dunning procedure for this level specify that dunning be repeated?

(b)  Program creates the dunning proposal list.

(c)  Edit dunning proposal list.

You can edit the dunning proposal to:

•  Raise or lower the dunning level of an item

•  Block an item from being dunned

•  Block an account for the current dunning run or remove the block

•  Block an account in the master record for dunning or remove the block

•  Block a document for dunning or remove the block

(d)  The sample printout shows how the printed notice would look. (A maximum of 10 notices can be seen on the screen.)

(e)  You may also display logs to see the changes made in the editing earlier as a confirmation of what you wanted to change in the system-generated proposal. If necessary, you can go back and change the proposal.

3.  Print dunning notices

You can use a single form or multiple forms, which will have different text based on the dunning levels. There may also be a requirement to use a completely different form for legal dunning. Once the print option is activated, the program prints the notices, and the dunning-related information, like the dunning level, last dunned, and so on, is updated in the customer/vendor masters. SAP provides the option to optically archive the notices as the system prints the dunning notices. There is also a provision to restart the printing if it is interrupted before it is completed.

27.   CAN YOU DUN CUSTOMERS ACROSS CLIENTS IN A SINGLE DUNNING RUN?

No. All the data processing is carried out per client.

28.   WHAT DIFFERENTIATES ONE DUNNING LEVEL FROM ANOTHER?

This dunning level determines the dunning text and (if one is required) a special dunning form (Figure 3.11). The dunning program determines what dunning level should be used in the dunning run. The dunning level so determined is stored in the master record of the account when the dunning letter is printed. The dunning level may also determine whether there will be some dunning charges.

FIGURE 3.11  Dunning Level

29.   HOW MANY DUNNING LEVELS CAN BE DEFINED?

You may define up to 9 dunning levels. If there is only one dunning level, then it is called the payment reminder.

30.   WHAT IS AN ACCOUNTS PAYABLE SUBMODULE?

Accounts payable, a submodule under Financial Accounting (FI), takes care of vendor-related transactions because the module is tightly integrated with the purchasing transactions arising out of the procurement cycle. The module helps in processing the outgoing payments either manually or automatically through the automatic payment program. It also helps in vendor evaluations.

31.   WHAT DOCUMENTS RESULT FROM PROCUREMENT PROCESSES?

In Materials Management (MM):

•  PR: Purchase Requisition (manual or automatic using MRP)

•  PO: Purchase Order

In Financial Accounting (FI):

•  Invoice Verification

•  Vendor Payment (manual or automatic)

In both MM and FI areas:

•  Goods Receipt

You may also group these documents into order documents, GR (Goods Receipt) documents, and IR (Invoice Receipt) documents. While GR/IR documents can be displayed both in MM and FI views, the order documents can only be viewed in MM view.

32.   WHAT IS A PURCHASE CYCLE?

FIGURE 3.12  Procurement Cycle

The purchase cycle or procurement cycle encompasses all the activities starting from purchase requisition, purchase order, goods movement, goods receipt, invoicing, invoice verification, payment to vendors, and ending with updating of vendor account balances (Figure 3.12).

33.   WHAT IS A PURCHASE REQUISITION?

A purchase requisition (PR) is the document that outlines a company’s purchasing needs of a material/service from vendor(s). A PR, typically an internal document that can be created automatically or manually, identifies the demand for a product and authorizes the purchasing department to procure it. In automatic creation of PR, this is done as a result of MRP (material requirements planning). The PR, after identifying the vendor, is processed further to result in an RFQ (request for quotation) or directly to a purchase order (PO).

34.   WHAT IS A REQUEST FOR QUOTATION (RFQ)?

An RFQ (request for quotation), which can be created directly or with reference to another RFQ or a PR or an outline agreement, is actually an invitation to vendor(s) to submit a quotation for supplying a material or service. The RFQ will contain the terms and conditions of the agreement. You may send the RFQ to one or several vendors, and you can monitor it by sending reminders to those who have not responded to the RFQ.

35.   WHAT IS AN OUTLINE AGREEMENT?

An outline agreement, a declaration binding both the buyer and the seller, is the buyer’s intention to purchase a material/service with certain terms and conditions agreed to between both parties. The essential difference between the outline agreement and a quotation is that the outline agreements do not contain the details like delivery schedule or quantities. The outline agreements can be contracts or scheduling agreements.

36.   WHAT IS A CONTRACT?

A contract, also referred to as a blanket order, is a long-term legal agreement between the buyer and the seller for procurement of materials or services over a period of time. The contract, created directly or with reference to a PR/RFQ or another contract, is valid for a certain period of time, with start and end dates clearly indicated. The two types of contracts are quantity contracts and value contracts.

37.   WHAT IS A RELEASE ORDER?

A release order is a purchase order created against a contract. The release orders usually do not contain information on quantities or delivery dates and are also called blanket releases, contract releases, or call-offs.

38.   WHAT IS A SCHEDULING AGREEMENT?

A scheduling agreement is also a long-term agreement with the buyer and seller for procurement of certain materials or services subject to certain terms and conditions. These agreements can be created directly or with reference to other documents like another scheduling agreement, or RFQ or PR. These agreements promote just-in-time (JIT) deliveries, reduce paperwork, reduce supply lead times, and ensure low inventory for the buyer.

39.   WHAT IS A QUOTATION?

A quotation contains information relating to the price and other conditions for supply of a material or service by a vendor and is termed as the vendor’s willingness to supply it based on those conditions. You can compare the data from quotations using a price comparison list, and this can help you to identify the best vendor for that item. After you receive the quotations, you will typically enter the quotation data (pricing/delivery) in RFQ. The SAP system can easily be configured to automatically print rejections for vendors whose quotations are not selected.

40.   WHAT IS A PURCHASE ORDER?

A purchase order (PO) is a legal contract between a vendor and a buyer that includes the material/service to be purchased/procured on certain terms and conditions. The order mentions, among other things, the quantity to be purchased, price per unit, delivery-related conditions, payment/pricing information, and other information.

A PO can be created:

•  Directly

•  With reference to a PR/RFQ/contract or another PO. Remember, all items on a PO should relate to the same company code.

41.   WHAT IS A PO HISTORY?

The purchase order history (PO history) lists all the transactions for all the items in a PO, like the GR/IR document numbers.

42.   WILL AN FI DOCUMENT BE CREATED DURING A PURCHASE ORDER?

No. There will not be any document created on the FI side during creation of a PO. However, there can be a document for posting commitment to a cost center in CO. (The offsetting entry is posted at the time of GR.)

43.   WHAT IS FI-MM INTEGRATION.

The FI-MM integration is based on the following:

•  Movement types

•  Valuation class

•  Transaction keys

•  Material type

The movement type is the classification key indicating the type of material movement (for example, goods receipt, goods issue, physical stock transfer) (Figure 3.13). The movement type enables the system to find predefined posting rules determining how the accounts in FI (stock and consumption accounts) are to be posted and how the stock fields in the material master record are to be updated.

FIGURE 3.13  Movement Types

Valuation class refers to the assignment of a material to a group of G/L accounts. Along with other factors, the valuation class determines the G/L accounts that are updated as a result of a valuationrelevant transaction or event, such as a goods movement. The valuation class makes it possible to:

•  Post the stock values of materials of the same material type to different G/L accounts

•  Post the stock values of materials of different material types to the same G/L account

The transaction key (also known as the event key or process key) allows the users to differentiate between the various transactions and events (such as physical inventory transactions and goods movements) that occur within the area of inventory management. The transaction/event type controls the filing/storage of documents and the assignment of document numbers.

Material type groups together materials with the same basic attributes—for example, raw materials, semifinished products, or finished products. When creating a material master record, you must assign the material to a material type. The material type determines:

•  Whether the material is intended for a specific purpose—for example, as a configurable material or process material

•  Whether the material number can be assigned internally or externally

•  The number range from which the material number is drawn

•  Which screens appear and in what sequence

•  Which user department data you may enter

•  What procurement type the material has—that is, whether it is manufactured in-house or procured externally, or both

Together with the plant, the material type determines the material’s inventory management requirement—that is:

•  Whether changes in quantity are updated in the material master record

•  Whether changes in value are also updated in the stock accounts in Financial Accounting

44.   WHAT HAPPENS WHEN YOU POST A GOODS RECEIPT?

When you post a goods receipt (GR), the stock account is debited (stock quantity increases) and the credit goes to GR/IR clearing account, which is the intermediate processing account before you actually process the vendor invoice or payments to the vendor:

•  Debit: Inventory Account

•  Credit: GR/IR Clearing Account

During this, (1) a material document is created, (2) an accounting document to update the relevant G/L account is created, (3) a PO order history is updated, and (4) the system enables you to print the GR slip.

45.   WHAT IS INVOICE VERIFICATION (IV) IN SAP?

Invoice verification involves:

a.  Validating the accuracy of the invoices (quantity, value, etc.)

b.  Checking for blocked invoices (that varied to a greater extent from that of the PO)

c.  Matching of invoices received from vendors with those of the purchase order/goods receipt. At this point, the PO history is updated for the corresponding PO line item(s) of the matched invoice.

d.  Passing of matched invoices to FI module. The system posts the following entries:

•  Debit: GR/IR Clearing Account

•  Credit: Vendor Accounts (Accounts Payable Open Line Item)

•  Credit: G/L Reconciliation Account

The different scenarios in invoice verification include:

•  GR-based invoice verification indicator is not set in the PO detail screen.
Although this setting enables you to post the invoice referenced to a PO prior to making a GR, the system will block the invoice for payment (because this kind of posting results in a quantity variance because there has not been a GR).

•  GR-based invoice verification indicator is set in the PO detail screen.
When the PO number is referenced, the system brings up all the unmatched items of GR in the selection screen. You will not be able to post the invoice for its full value unless the PO has been fully received.

46.   WHAT DO YOU DO WITH THE TAX WHEN YOU POST AN INVOICE?

When you enter an invoice, based on the configuration settings, the system checks the tax code and calculates the applicable tax or validates the tax amount you entered:

•  Manual entry: Input the tax code and the tax amount. The system will validate and issue a message in case it does not find the tax code or if the amount is different.

•  Automatic entry: Leave the tax code and tax amount fields blank. Click on the “Calculate Tax” indicator. The system picks up the corresponding tax code and calculates the tax amount automatically.

47.   WHAT VARIANCES ARE IN INVOICE VERIFICATION?

The system needs to be configured properly with tolerances so you are not hampered with variances when you try invoice verification. You need to define the lower and upper limits for each combination of the company code and the tolerance key defined for the various variances. The system, then, checks these tolerance limits and issues warnings or prevents you from proceeding further when you process an invoice.

The variances arise because of mismatches or discrepancies between the invoice and the PO against which the invoice has been issued. Normally you will encounter:

•  Price variance: if there is a discrepancy in invoice price and PO item prices

•  Schedule variance: if the planned delivery date is later than the invoice postings

•  Quantity variance: if the delivered quantity (or delivered quantity less previously invoiced quantity) is not the same as the invoiced quantity. When the invoiced quantity is more than the GR, the system requires more GRs to square off the situation

48.   WHAT IS THE PAYMENT PROGRAM IN SAP?

The payment program enables you to process international payment transactions—both outgoing and incoming—with both customers and vendors. It comes with a lot of flexibility so you can define several payment features that vary from country to country, such as payment method, payment form, or data carrier specifications. As always, the standard SAP system contains the common payment methods (check, transfer, bill of exchange, etc.) and the corresponding forms that have been defined separately for each country. It also comes with the country-specific payment methods (like the POR procedure for Switzerland).

The payment program also supports (a) clearing open items between customers and vendors, (b) intercompany payments with one company code paying centrally for others, (c) paying or clearing any type of open item (say, down payments), and (d) restricting access to the payment program through authorizations.

The payment program is used by Accounts Receivable (FI-AR), Accounts Payable (FI-AP), Treasury (TR), and Bank Accounting (FI-BL).

49.   WHAT SETTINGS ARE REQUIRED FOR CONTROLLING THE PAYMENT PROGRAM IN SAP?

Besides making the specifications such as which company code makes the payments and how many days of tolerance are provided in processing the payments, you also need to maintain the following control settings that are required for processing a payment by the payment program:

•  What is to be paid? To do this, you specify rules according to which the open items to be paid are selected and grouped for payment.

•  When is the payment to be made? The due date of the open items determines when payment is carried out. However, you can specify the payment deadline in more detail via configuration.

•  To whom will the payment be made? You specify the payee (the vendor or the alternate payee, as the case may be).

•  How is the payment made? You determine rules that are used to select a payment method.

•  From where is the payment made? You determine rules that are used to select a bank and a bank account for the payment.

50.   WHERE DO YOU MAINTAIN THE SPECIFICATIONS FOR CONTROLLING THE PAYMENT PROGRAM?

The specifications for controlling the payment program are made when:

•  Configuring the payment program

•  Entering data in your business partner master records

•  Entering data in the open items

•  Entering data for the payment run

51.   WHAT ARE THE PREREQUISITES FOR RUNNING THE PAYMENT PROGRAM?

Before you are ready to run the automatic payment program, the following should have been defined/configured in the system:

•  House bank and the corresponding bank accounts

•  Payment methods to be used for the company code. SAP comes with predefined payment methods, both for AR and AP. The following payment methods are available for you to choose from, depending on the requirements:

- Accounts payable

Cheque/transfer/postal giro transfer/bill of exchange

- Accounts receivable

Bank collection/bank direct debit/refund by check/refund by bank transfer/bill of exchange payment request

•  Bank chain, if necessary. Bank chains are used to make payments via more than one bank—for example via the correspondence banks of the house bank, the recipient bank, or the intermediary banks. You can define up to three banks.

•  Payment forms. SAP delivers standard forms, which can be modified, or new forms can be created for use.

52.   HOW DO YOU CONFIGURE THE PAYMENT PROGRAM?

You may do most of the configuration settings by accessing the various configuration tasks on the “Customizing: Maintain Payment Program” screen (Figure 3.14).

Transaction Code
FBZP

FIGURE 3.14  “Customizing: Maintain Payment Program” Screen

53.   WHAT IS A SENDING COMPANY CODE?

Sending company code is the one your business partners are familiar with. When you make cross-company code payments, you can specify the sending company code as well as the paying company code for each company code. If the sending company code is different from the paying company code, the system notes the sending company code in the payment transfer medium or payment advice as information for the business partner. The sending company code affects how the system groups items from different company codes into one payment (Table 3.2).

TABLE 3.2  Sending Company Code

Items are only grouped into one payment for company codes with the same paying company code and the same sending company code. If the sending company code is not specified, the system automatically regards the paying company code as the sending company code. You only need to specify the sending company code if you want to pay using a cross-company code transaction but do not want to pay the items of all participating company codes together.

54.   HOW DO YOU CONFIGURE SENDING AND PAYING COMPANY CODES FOR THE PAYMENT PROGRAM?

Use the following transaction code and configure the sending company code, tolerance days, and paying company code specifications.

Transaction Code
OBVU

1.  Sending company code (Figure 3.15)

If company code “A” is making payments on behalf of company code “B, ” then “B” is the sending company code. If you do not specify the sending company code, it is assumed that the paying company code is the sending company code.

2.  Tolerance days

3.  Paying company code specifications

In the case of centralized payments, you will make all the payments through a particular company code known as the paying company code. However, even if there is no centralized payment, you need to have one of your company codes as the paying company code.

FIGURE 3.15  Sending Company Code Specifications

The paying company code and the company code to which payment is made must be in the same country and have the same local currency and parallel currencies (Figure 3.16). Both company codes must also have the same settings for enhanced withholding tax functions (active or not active).

FIGURE 3.16  Paying Company Code Specifications

You will make the following specifications:

•  Minimum amounts for incoming and outgoing payments

•  Forms for payment advice and EDI

•  Bill of exchange parameters

55.   WHAT IS A PAYMENT METHOD?

The payment method specifies the procedure, such as check, transfer, or bill of exchange, by which payments are made. The payment methods are defined in two steps:

a.  Maintain all the specifications that are required for each payment method in each country. This is necessary for all the payment methods used by your organization in each country.

b.  Maintain the payment methods you use for each company code. Here, you also specify the conditions of their use.

56.   WHAT PAYMENT METHODS ARE NORMALLY AVAILABLE IN SAP?

In a standard SAP system, you will see the following payment methods already defined and ready to use:

Accounts receivable

•  Bank collection

•  Bank direct debit

•  Refund by cheque/bank transfer

•  Bank bills

•  Bill of exchange request

Accounts payable

•  Cheque

•  Transfer

•  Postal giro transfer

•  Bill of exchange

57.   WHAT IS PAYMENT METHODS IN COUNTRY FOR THE PAYMENT PROGRAM?

You will use the following transaction code to define all the payment methods that will be permitted for a country and the specifications for each of these permitted payment methods (Figure 3.17).

Transaction Code
OBVCU

Here, you may define all the payment methods permitted per country.

FIGURE 3.17  Payment Methods in Country

The following are to be configured under this category for each of the payment methods for that country (Figure 3.18):

•  Payment method for outgoing/incoming?

•  Payment method classification

•  Master data requirements

•  Posting details—document types

•  Payment medium details—print programs

•  Permitted currencies (leave blank to allow all currencies)

FIGURE 3.18  Specifications for Payment Method in Country

58.   HOW DO YOU CONFIGURE PAYMENT METHODS IN COMPANY CODE?

You will use the following transaction code to define all the payment methods that will be permitted for a company code and the specifications for each of these permitted payment methods (Figure 3.19).

Transaction Code
OBVU

Here, you may define all the payment methods permitted per company code.

FIGURE 3.19  Payment Methods in Company Code

The following are to be configured under this category for each of the payment methods permitted for that company code (Figure 3.20):

•  Amount limits (minimum/maximum payment amounts)

This provides the value range within which the payment method can be selected by the payment program. It is important that you specify a maximum amount, without which payment method cannot be used at all. Note that the value range maintained here does not apply if you have specified the payment method in the open item.

•  Whether payment abroad or in foreign currency is allowed (foreign payments/foreign currency payments)

This specification as to foreign payments is necessary (a) when you have your customer or vendor abroad and/or (b) when the payment is made through a bank abroad. In the case of foreign currency payments, specify whether it is possible to use the payment method in question to pay in foreign currency, in which case any currency can be used. It is also possible to specify particular currencies per payment method and country. In this case, if that particular payment method is selected, then the payments are processed only in one of the currencies specified.

•  Payment item grouping

You have two options of grouping the payment items: single payment for marked item and payment per due date.

•  Bank optimization (bank selection control)

SAP provides you with three options in bank selection: optimize by bank group, optimize by postal code, and no optimization.

FIGURE 3.20  Payment Method in Company Code Specifications

59.   WHAT IS PAYMENT METHOD SELECTION BY THE PAYMENT PROGRAM?

You must specify which payment methods to be used in the payment run at the start of every payment run. However, the selection of the payment method for a particular payment run is subject to the payment methods permitted for that payment run, payment methods maintained in the master record, and the payment method in the open item. Even the order in which the payment methods are maintained makes a difference (Table 3.3).

TABLE 3.3  Payment Method Selection by Payment Program

For a payment method to be used by the payment program:

•  The payment method must be specified in the customer/vendor master record or open items. Note that the method in the open item takes precedence when payment methods are mentioned both in the master record and open items.

•  The specifications needed for the payment method are mentioned in the master record.

•  A bank that is permissible for the payment method under consideration is determined for payment.

•  The permissible minimum and maximum amounts must be adhered to for the payment amount.

•  In the case of payments abroad, the payment method in question should allow for payments to customers/vendors or their banks abroad. For foreign currency payments, the payment method must allow such a payment.

When the program determines a payment method meeting the above conditions, then that payment method is used. Otherwise, the program carries out all these checks for the next payment method in the list until it comes across a payment method that meets the conditions.

60.   WHAT IS OPTIMIZATION BY BANK GROUPS?

If you specify optimization by bank groups for a payment method, then the payment program selects two banks that belong to the same bank group. (To use bank selection by bank group, you need to assign a freely definable bank group to all banks in your master records.) If several house banks come into consideration, the bank with the highest priority (ranking order) is selected. If an optimization is not possible, the optimization function does not apply.

In Table 3.4, A depicts the house banks with their priority and the bank group. B shows the banks as in the customer/vendor master data.

TABLE 3.4  Settings for Bank Optimization by Bank Group: Optimization Possible

Now look at Table 3.5.

TABLE 3.5  Settings for Bank Optimization by Bank Group: Optimization Not Possible

This kind of bank optimization by bank group ensures that money is transferred from your house bank to your customer’s/vendor’s bank at the earliest time possible.

61.   WHAT IS BANK OPTIMIZATION BY POSTAL CODE?

The bank optimization by postal code ensures that the payment program selects the appropriate house bank according to the location (postal code) of the customer/vendor. It is recommended that you assign your house banks to a range of postal codes so this optimization works well (Table 3.6).

TABLE 3.6  Settings for Bank Optimization by Postal Code

If no house bank is defined for the postal code area of the customer/vendor, or if the selected house bank cannot be used, the payment program selects the house bank with the highest priority from the priority list. In this case, optimization does not take place.

62.   WHEN DO YOU USE THE PAYMENT PER DUE DATE GROUPING OPTION?

If you select the payment per due date indicator in grouping of items while configuring the payment methods per country, it is an instruction to the payment program that a payment needs to be created for each due date. All the items that are to be paid are then grouped according to due date, and several payments are generated grouped by due dates instead of a single payment.

63.   WHAT IS BANK DETERMINATION FOR THE PAYMENT PROGRAM?

You will use the following transaction code to define all the necessary specifications for configuring the bank determination for the payment program (Figure 3.21).

Transaction Code
OBVCU

You will be defining:

•  Ranking order

•  Bank accounts

•  Available amounts

•  Value date

•  Expenses/charges

FIGURE 3.21  Specifications for Bank Determination

Ranking order

Specify which house banks are allowed for:

•  Every payment method or

•  Both payment method and currency

Maintain the priority, and sort the list of permissible banks in ranking order according to this priority (Figure 3.22).

FIGURE 3.22  Ranking Order in Bank Selection

Bank accounts

For every combination of payment methods and house banks, specify via which bank account (for example, giro) the payment should be made (Figure 3.23).

FIGURE 3.23  Bank Accounts for Payment Method/House Bank Combination

Available amounts

For every account at a house bank, you need to specify the amounts that are available for the payment run. You may specify the amounts both for incoming and outgoing payments (Figure 3.24).

FIGURE 3.24  Available Amounts per Account per House Bank

Value date

Value dates are the number of days that elapse between the posting date of the payment run and the value date at the bank. This is required to take into account the delay between the payment and its reflection in the bank’s books. Maintain the value dates for all the combination of payment method/house bank and the amount limit (Figure 3.25).

FIGURE 3.25  Value Date Settings in Paying Company Code

Expenses/Charges

Maintain the required charges for each of the amount limits, using a charge indicator for the paying company code (Figure 3.26).

FIGURE 3.26  Maintain Expenses/Charges

64.   WHAT ARE VALUE DATES?

Value dates are the number of days that elapse between the posting date of the payment run and the value date at the bank. Either you can define the value dates yourself based on your experiences with previous payments made with that payment method, bank account, payment amount, and currency, or you can have the system automatically determine the value date. In the case of the latter, the system will use a bank calendar and individual agreements with the bank as decision criteria to arrive at these days.

The payment program uses the value dates in two ways:

•  By adding the number of days needed for the payment to be debited from your account to the posting date of the payment run and thereby establishes the value date of the payment. This date is noted in the payment document. Such information is particularly important for the “Cash Management and Forecast” application. If no value dates are determined, the system takes the posting date of the payment run as the value date.

•  To check the available amounts at each of the accounts/house banks. In this case the value dates are used to plan the available amounts on a graduated time scale. You generally only need this facility if you post payments by bill of exchange before the due date. In all other cases, you just need to maintain this as “999.”

Because all the payments (regardless of the amount) that are made by transfer are debited from your bank account on the next day, you should enter “1” in the field “Days to Value Date.” However, the period within which a check is cashed can be dependent on the amount—for example, for amounts of up to 10, 000 USD, the time between the posting date and the value date may be 4 days, and for all other amount limits, it may be 2 days (Table 3.7).

TABLE 3.7  “Value Date” Settings for Payment Program

65.   HOW DO YOU CONFIGURE AVAILABLE AMOUNTS?

The configuration of available amounts is to enable the payment program to check whether the selected bank accounts have sufficient funds for payment. You may specify available amounts separately for incoming payments/outgoing payments for the different accounts maintained at the house banks. Define the size of the amount that can be paid for all the outgoing payments, and you specify the amount up to which such payments can be made into a bank account for the incoming payments. When this limit is exceeded, the payment program selects another account of the bank. The program does not carry out amount splitting if it comes across a bank account with an insufficient amount for making a payment. Also, if it finds no bank account from which it can post the entire amount for a payment, it does not carry out the payment at all.

You can also specify the amounts based on currency and probable value date (days) at the bank. The value date helps in determining the available amounts because there is a time lag between the payment run date and the value dating at the bank. You generally need to include this value date facility only if you post payments by bill of exchange before the due date. In all other cases, you can enter “999” (Table 3.8).

TABLE 3.8  “Available Amounts” Settings for Payment Program

66.   HOW DO YOU EXECUTE THE PAYMENT PROGRAM?

The following are the steps involved in executing the payment program:

1.  Maintain payment parameters.

To start with, you need to maintain the parameters for the payment run like date of execution of the payment run, the payment run identifier, and so on. Once this is done, you need to specify:

•  The posting date for the payments

•  The document date up to which the program should consider the items for payment

•  The paying company code

•  Payment methods to be considered

•  The next posting date

•  Any accounts that should be excluded from the run

The payment run then needs to be scheduled either immediately or at a specified time/date.

2.  Payment proposal

The system creates a payment proposal, based on the payment parameters maintained in #1. The system selects the eligible open items based on the following sequence:

a.  Due date is determined via the baseline date and the terms of payment for each of the line items.

b.  Program calculates the cash discount period and due date for the net payment.

c.  Grace periods (company code-specific grace periods for payables, maintained in the field “grace period in days for payable” under “cash discount & tolerances”) are then added to this due date.

d.  Which special G/L accounts are to be included (by entering the special G/L code of the transaction in question when you make the company code specifications), based on what you have already maintained as the parameters in #1.

e.  The system will determine whether to include an item during the current payment run or for the future one based on the specifications you made in #1.

f.  The program also determines whether to block an item.

The payment proposal thus created can be displayed for further processing. The log can be checked for system messages, and the exception list can be generated for further evaluation.

3.  Payment proposal

With the payment proposal available, you can now edit the proposal to:

a.  Change the house bank from what was maintained earlier or suggested by the payment program

b.  Change payment method, if necessary

c.  Change payment due date to relax or restrict certain open items

d.  Block/unblock line items

4.  Payment run

After the payment proposal has been edited, you can run the payment program that creates the payment documents and prepares the data for printing the forms or creating the tape/disk/DME. Before printing the forms, check the logs to determine that the payment program run was successful.

5. Print run

Payment medium programs use the data prepared by the payment program to create forms (payment advice, EDI accompanying sheet) or files for the data media. The data-created payment programs are stored in the following tables:

•  REGUHPayee or Payment Method data

•  REGUPIndividual Open Items data

•  REGUDBank Data and Payment Amounts data

You need to define variants for the print program:

•  Per payment method per country -> assign a print program

•  To run the print program -> at least one variant per print program per payment method

Transaction Code
F110

67.   HOW DOES THE PAYMENT PROGRAM DETERMINE THE HOUSE BANK FOR PAYMENT?

During the payment run, the payment program attempts to determine a house bank and a bank account that has a sufficient amount available for payment. The sequence of events is:

a.  The payment program searches a house bank (bank ID) for the given combination of payment method and currency. If there is no matching entry, then the program checks to find out whether a bank exists for “payment method without currency specification.”

b.  Then it goes on to determine the account ID on the basis of the bank ID, the payment method, and the currency.

c.  Finally, it finds out whether sufficient amounts are available for both bank ID and account ID.

During this processing, the following may happen:

•  The program finds no house bank fulfilling all the conditions. This means the payment cannot be made with that particular payment method with which the check was carried out. Now the system proceeds to carry out the same sequence of checks for the next possible bank. If no bank is determined, then this payment method also cannot be used. The program goes further to check whether another method is available, and so on. All these are noted in the log for the payment run.

•  The program determines only one house bank. The payment is made through that house bank.

•  There is more than one bank determined. The payment is made from the house bank with the highest priority according to the defined ranking order of the banks (note that this is not valid if you have specified payment optimization).

68.   CAN THE PAYMENT PROGRAM DETERMINE THE CHECK CASHING TIME FOR VALUE DATING?

You can instruct the payment program to add the number of days it will take to cash a cheque so the value date is correctly arrived at from the posting date. For this, you need to enter the number of days in “check cashing time” in the customer/vendor master record. If this field is blank, then the program determines the value date based on the entries maintained while configuring the value dates.

Let’s look at an example where the payment posting date was June 10, 2009, for a payment of USD 10, 000 to one of your vendors. The payment method was “cheque” (Table 3.9).

TABLE 3.9  Check Cashing Time: the Possibilities for Value Date

Entry in “Check Cashing Time” in Vendor Master Record

Entry in “Days to Value Date” while Configuring Value Dates

Value Date Arrived at By the System

2

4

June 12, 2009

Blank

4

June 14, 2009

Blank

Blank

June 10, 2009

69.   WHAT IS LOCAL PAYMENT?

When you deal with an organization that has branch offices, the payment program normally pays to the head office unless otherwise specified. This is because the program takes the required information from the master record of the head office. However, it is possible to make payments to the branch offices, and such a payment is called a local payment. For such a payment, the required details like bank, address, and so on are taken from the master record(s) of the branch office(s). The prerequisites for a local payment include:

•  If you want separate payment methods for different branch offices, then you need to set up these methods in the master records of the branch offices. If the branches require the same payment methods as those of the head office, then it is sufficient to maintain these at the head office’s master record. If the payment methods are defined in the master records of branch and head office, then any of these payment methods can be used.

•  The field “local processing” in “Correspondence” in the “company code data” of the vendor/customer master record needs to be selected.

70.   WHAT FACTORS INFLUENCE WHEN THE PAYMENT PROGRAM PAYS AN OPEN ITEM?

There are several factors that influence when an open item is considered for payment:

•  Payable or receivable?

In the case of payables, the items will be selected based on the following:

- With the grace period taken into account, the item will be selected for the current run if it:

Achieves a higher cash discount if paid in the current payment run than if paid in the following run

Would become overdue in the following payment run

- The item is always due together with the invoice it is linked to for all invoice-related credit memos.

- All other open items will be paid in the next payment run.

In the case of receivables, the payment program always aims to pay soon enough to take advantage of the highest possible cash discount. The payment is made with the first payment run that is carried out on or after the due date of the first cash discount term.

•  Cash discount/net payments strategy

•  Bill of exchange payment strategy: pay before the due date?

71.   HOW DO YOU ARRIVE AT AN APPROPRIATE CASH DISCOUNT STRATEGY FOR PAYMENTS?

The cash discount strategy can be one of the following three options:

1.  Pay as early as possible to get the maximum possible discount.

To achieve this, select the checkbox “Always max. Cash Discount” in the company code specifications while configuring the payment program. The program applies cash discount term 1 to these open items.

2.  Delay payments as much as possible, even foregoing a cash discount.

This is achieved by entering the discount percentage in the “outgoing payment with cash discount from” field in the company code specifications of payment program configuration. Once this is done, then the payment program settles items only if the discount percentage rate entered can be reached in the current payment run. Otherwise, payment is made when the amount is due net. If you wish to make payment as late as possible, enter 99 percent as the minimum percentage rate (during payment program configuration). Now the payments are always made net, and you will be foregoing all the discounts.

3.  A middle strategy between #1 and #2.

72.   CAN YOU PAY A VENDOR IN A CURRENCY OTHER THAN THE INVOICE CURRENCY?

With the release 4.5A, you can now pay to a vendor in a currency that is different from that of the transaction/invoice currency. This is achieved by entering the required currency code directly in the open item. Prior to this release, to pay in a different currency, you had to manually process the payment.

73.   WHAT IS A PAYMENT BLOCK?

A payment block prevents you from paying a vendor’s open item. The payment block is entered in the “payment block” field in a vendor master record or directly in the open line item.

Use the payment block indicators to define the payment block reasons. You may use the SAP delivered payment block indicators (A, B, I, R, etc.), or you can create your own. An indicator like “” is used when you want to skip the particular account, and a blank indicator indicates that the account/item is free for payment. However, for each of these block indicators, you need to configure whether changes would be allowed during processing the payment proposal. Then it is also possible that you block a payment or release a blocked one while processing the payment proposal.

You may also propose a payment block indicator while defining a terms of payment.

74.   HOW DO YOU RELEASE BLOCKED INVOICES FOR PAYMENT?

The system will block an invoice if it comes across with an item with a blocking reason. The blocking reason may be due to variances or inspectionrelated issues. When the system blocks an invoice for payment, the “payment block” field is checked by the system.

You will be using an invoice release transaction to select the blocked invoices for processing further. The release of blocked invoices for payments can be handled either manually or automatically.

75.   WHAT IS A PAYMENT MEDIUM WORKBENCH (PMW)?

The Payment Medium Workbench (PMW) tool helps to configure and create payment media sent by organizations to their house banks. This generic tool is to phase out the classic payment medium programs (RFFO) because it has the following advantages:

•  Better sort functions with payment advice notes

•  Easier to maintain/extend and easier to work with than the multiple payment medium programs

•  Superior control, verification of payment procedure, and improved performance with mass payments (>50, 000)

The PMW is embedded in a development environment, and you can access all Workbench objects (program objects, dictionary objects, and mapping tool objects) with just a double click. It covers:

1.  Payment media customization

•  Defining payment medium formats

The payment medium format controls how payment orders and debit memo orders to the bank are created. The specifications of the formats serve as the basis for definition of payment medium formats. The payment medium format can be country-dependent or country-independent and is assigned to one or more payment methods.

•  Adjusting payment medium formats

•  Adjusting the “note to payee”

•  Assigning payment medium format and note to payee

•  Creating, assigning, and transporting selection variants

2.  Payment media creation

•  Creating payment media without documents in file form

- Output of the created data media into DME administration

•  Creation of payment advice notes

- Output of the created payment advice notes as letter, fax, or IDoc

•  Creation of an output log (an error log, too, if necessary) for each program run

The PMW can be used by several components like FI-AP/AR, FI-TV, HR-PY, TR-CM, and TR-TM.

76.   WHAT IS AN ACCOUNT ASSIGNMENT CATEGORY?

The automatic account assignment logic takes care of posting to the correct G/L accounts for a stock material with the material type permitting inventory management, and the material master contains information as to which G/L account needs to be updated. But there are material line items (nonstock materials) created manually in purchase requisition/purchase order/outline agreement for which someone needs to decide the account assignment data and manually enter the same in the purchase requisition. It is indicated in the account assignment category where to allocate the costs relating to such materials. The account assignment category helps you to define (1) the type of account assignment (Sales Order-C, Project-P, Cost Center-K, etc.) and (2) which accounts are to be posted to when GR/IR is posted to.

77.   WHAT IS A CREDIT MEMO?

The credit memo is issued by the vendor who earlier has supplied you some services or materials. The occasion is necessitated when the delivered goods are damaged or you have returned some of the goods to the vendor. The system treats both the invoices and the credit memo in the same way, except the postings are done with the opposite sign.

If the credit memo is for the entire invoiced quantity, the system generates the credit memo automatically. On the other hand, if the credit memo relates to a portion of the invoiced quantity, you need to process the same manually in the system.

78.   WHAT ARE SPECIAL G/L TRANSACTIONS?

Special G/L transactions are not directly posted to the G/L (reconciliation accounts), though these are related to subledger accounts like AR/AP. The transactions to these accounts are shown separately in the balance sheet. There are specific posting keys/indicators defined in the system to regulate the postings to these items. You need to specify a special G/L indicator (like F-Down Payment Request, A-Down Payment) for processing such a transaction. And the system will use the specially defined posting keys (09-customer debit, 19-customer credit, 29-vendor debit, and 39-vendor credit) for posting these special G/L transactions.

There are three types of special G/L transactions (Figure 3.27):

•  Free Offsetting Entries (Down Payment)

•  Statistical Postings (Guarantee)

•  Noted Items (Down Payment Request)

FIGURE 3.27  Special G/L Indicators

79.   WHAT IS THE DIFFERENCE BETWEEN A FREE OFFSETTING ENTRY AND A STATISTICAL POSTING?

Free offsetting entries postings are part of the regular postings but with a freely definable offsetting entry, and they relate to the on-balance sheet items. On the other hand, in a statistical posting, you will always be posting to the same offsetting entry, and these are all the off-balance sheet items.

80.   WHAT IS A NOTED ITEM?

The noted items are never displayed on the financial statements because they serve only as reminders of a financial obligation, like outstanding payments, to be made or that are due to us, like the down payment request. This kind of posting does not update any G/L account in the system but helps to keep track of such obligations for easy follow-up. This is also sometimes referred to as a memo entry.

It is interesting that while the special G/L indicator for down payment request is “F, ” you need to enter the indicator “A” as the target special G/L indicator while you are in the “Down Payment Request Entry” screen. When you post this entry, the system creates a one-sided memo entry for the customer or vendor but does not update the G/L.

81.   WHAT IS A/R PLEDGING?

A/R pledging refers to the transfer of a receivable from the previous creditor (assignor) to a new creditor (assignee). As part of financing, you can set an accounts receivable pledging indicator for receivables from goods and services. The pledging indicator you define in customizing is saved in the customer master record and automatically transferred to the customer line item on posting It is then displayed in the customer line item display and in the customer lists for subsequent evaluation. Please note setting up this pledging indicator does not trigger any process with a third party (for example, bank or credit provider).

82.   WHAT IS ASSIGNING DOCUMENTS TO CUSTOMERS?

It is possible to assign documents that have been scanned into the system, such as business reports, newspaper articles, or graphics to each customer. However, to use the document management system, you need to have SAP ArchiveLink installed/activated in the system.

83.   WHAT ARE VENDOR/CUSTOMER EVALUATIONS IN FINANCIAL INFORMATION SYSTEMS?

The evaluations/analyses in Table 3.10 are possible through financial information systems.

TABLE 3.10  Customer/Vendor Evaluations

Customer

Vendor

Currency risk

Due date breakdown

DSO (Days Sales Outstanding) analysis

Overdue items

Due date breakdown

Payment history

Overdue items

Payment history

Terms offered/taken

The system creates drilldown lists for each evaluation, which are sorted and summarized according to freely definable grouping criteria (such as country, company code, or group key).

The following are the freely definable grouping criteria in the standard system:

•  Business area

•  Company code

•  Country

•  Credit control area (customers only)

•  Credit representative group (customers only)

•  Credit risk category (customers only)

However, you can use the following grouping criteria for due date analysis:

•  Accounting clerk (customers only)

•  Cash management groups

•  Dunning level (customers only)

•  Industries (customers only)

•  Reconciliation account

Besides the above two sets of grouping criteria, you can also break down the evaluation data according to other relevant fields like the postal code, document type, and so on from the secondary index and master record. However, it is not possible to use the fields from the document header or document segment for such breakdowns or sorting or summarizations.

84.   WHEN DO YOU USE A DUE DATE BREAKDOWN ANALYSIS FOR CUSTOMERS/VENDORS?

You can use the due date breakdown evaluations to display the following for your customers/vendors:

•  Sum total of the open customer or vendor items

•  Total of due items

•  Total of the items not yet due

It is possible that you can have the system to display the totals of the due items and the totals of the items due in the future according to periods as specified by you.

85.   WHAT IS DSO ANALYSIS?

The DSO (Days Sales Outstanding) analysis is an analysis of customer payment history, which is always made within a specific period. It is possible to select monthly values for this analysis. This analysis provides general information about the number of days (DSO days) a customer takes to pay an invoice. Using the drilldown feature of the analysis, you can display:

•  Balance (the average debts outstanding—open customer items—at the end of the selected period)

•  Average sales per period you select

•  DSO days (calculated by using the formula: balance/sales per period x 30)

86.   WHAT DO YOU DO BEFORE POSTING A DOCUMENT IN A/R AND A/P?

When you have finished entering the line items in a document and before posting that document, you can:

•  Add additional information: You can enter additional details in automatically generated line items (such as project or cost center) if supplementary account assignment is defined for the G/L account or if it is required by the field status definition.

•  Additional account assignment. If you have called up the “Post” function and requested individual, automatically generated items using the field status of the G/L account to which they belong, or using the master record of an additional account assignment, the system automatically branches to the document overview. You will notice that the lines that are to be changed are highlighted.

•  Change fields in vendor/customer (or G/L) line items: However, note that you will not be able to change the entries in the fields “Pstky” and “Account.”

•  Display the document overview showing the document header and all items you have just entered. It is possible to add a reference text to the header. From the overview, you can also enter more line items, call up the line items already entered to process them, and delete line items.

87.   WHAT ARE THE OPTIONS FOR CALCULATING INTEREST ON CUSTOMER/VENDOR ACCOUNTS?

The interest calculation in SAP is controlled by settings made in the interest indicator (assign an interest indicator to the master records of the customer/vendor accounts from which you want to calculate interest, and also make other settings for each interest calculation). The interest is calculated using the debit interest rate defined for the interest indicator in the system. The credit interest rates are used when interest is being calculated on items paid prior to their due date.

SAP provides you with the several options for calculating interest on customer/vendor accounts (Table 3.11).

TABLE 3.11  Interest Calculation Options for Customer/Vendor Accounts

88.   WHAT FIELDS ARE USED FOR ARREAR INTEREST CALCULATIONS IN THE CUSTOMER/VENDOR MASTER?

The following two fields (in the company code data area of) of customer/vendor master records are relevant for the calculation of interest on arrears:

•  Interest indicator: The interest program that calculates interest on arrears using the interest indicator specified in the customer master record (the most important specifications, like rules determining which items are selected for interest calculation and how the interest is calculated, for the interest calculation run are stored under the interest indicator). The interest indicator must be assigned the interest calculation type item interest calculation. If an account is to be included in the interest calculation run, an interest indicator for interest on arrears must be specified in the master record.

•  Last key date: After each interest calculation run, the program enters the upper limit of the calculation period into this field by batch input. This is the date you have specified for the calculation run.

CHAPTER

4

BANK ACCOUNTING
(FI-BI)

1.     WHAT ARE THE FEATURES OF BANK ACCOUNTING IN SAP?

Bank accounting, a submodule under Financial Accounting (FI), helps to handle accounting transactions that you process with your bank. It includes:

•  Management of bank master data (Bank Directory)

•  Cash balance management (Check/Bill of Exchange management)

•  Creation and processing of incoming and outgoing payments

Using bank accounting, it is possible to freely define all country-specific characteristics, such as the specifications for manual and electronic payment procedures, payment forms, and data media.

2.     WHAT IS A BANK DIRECTORY?

SAP stores the master data (details like bank key, bank name, bank country, bank accounts, bank address, etc.) relating to the banks in bank directory (Table: BNKA). The bank directory must contain the master data for all the banks that you require for payment transactions with your business partners. This includes your banks and your business partners’ banks.

3.     HOW DO YOU CREATE A BANK DIRECTORY?

There are two ways to create a bank directory (Figure 4.1):

•  Automatically

Obtain the national bank directory on a data medium (ASCII file) from a banking organization in your country, and import the bank directory into the SAP system using the program RFBVALL_0. This is currently possible for countries like Austria, Germany, Spain, Italy, Canada, the United Kingdom, South Africa, Switzerland, and Denmark. However, you can use the same program to import other file formats for other countries. When you create the bank directory with this method, note that you should update the bank directory regularly. You may use the IMG menu path: SAP Customizing Implementation Guide > Cross-Application Components > Bank Directory > Bank Directory Data Transfer > Transfer Bank Directory Data–Country-Specific

Transaction Code
BAUP

FIGURE 4.1  Automatic Creation of Bank Directory (Country-Specific)

For international bank data, you will import a bank directory file that you might have created using the “BIC Database Plus” into the SAP system, using the program RFBVBIC_0. This file can contain data from the banks of one country or of several countries. The following details are imported into SAP:

•  Bank key (complete) in field BNKA-BANKL.

•  Bank name (first 60 bytes) in field BNKA-BANKA.

•  Bank number (complete) in field BNKA-BNKLZ and BNKABANKL, if the bank number is selected as the bank key.

•  Branch (first 40 bytes) in field BNKA-BRNCH, if contained in the input file.

•  City (first 27 bytes) + postal code (8 bytes) in field BNKA-ORT01, if the postal code has no more than 8 characters; in all other cases, only the city (first 35 bytes) is transferred.

•  S.W.I.F.T. (complete) in field BNKA-SWIFT and BNKA-BANKL, if the S.W.I.F.T. code is selected as the bank key.

•  Street (first 35 bytes) in field BNKA-STRAS.

Transaction Code
BIC

•  Manually

You may use the following menu path to create the bank master data:
SAP Easy Access: SAP Menu > Financial Accounting > Banks > Bank Master Record > Create.

Transaction Code
FIOI

As far as the master data for the business partners’ banks are concerned, you can enter these when you are entering or editing the master data for the business partners. When you are entering customer or vendor master data, or entering a document in a one-time customer account, the system automatically branches to bank directory editing if you enter bank details that do not exist in the directory.

4.     WHAT IS A HOUSE BANK?

A house bank is the bank (or financial institution) in which the company code in question keeps its money and does the transactions from there on. A house bank in SAP is identified by a 5-character alphanumeric code. You can have any number of house banks for your company code, and the details of all these house banks are available in the bank directory. Figure 4.2 shows how the house banks are modeled in a bank directory in SAP.

FIGURE 4.2  House Banks in Bank Directory

•  Each house bank in the system is associated with a country key (US, IN, etc.), representing the country where the bank is located, and a unique country-specific code called bank key. The system uses both the country key and the bank key to identify a house bank (Figure 4.3).

FIGURE 4.3  House Bank ID (DB), Country Key, and Bank Key

•  For each of the house banks, you can maintain more than one bank account. Each account is identified by an account ID—for example, Chek1, Check2, Pybl1, and so on. Here, Chek1 may denote checking account 1, Pybl1 may denote payables account 1, and so on. You can name the accounts so they are easily identified. The account ID is referenced in the customer/vendor master record, and the same is used in the payment program by the system (Figure 4.4).

FIGURE 4.4  Bank Accounts of a House Bank (DB)

•  To access this account ID, you will also specify the bank account number (maximum length of this identifier is 18 characters). You may name this in such a way that it is also easy to identify.

•  For each bank account number so defined in the house bank, you need to create a G/L account master record, and while doing so, you will incorporate the house bank ID and the account ID in that G/L master record (Figure 4.5).

FIGURE 4.5  Bank Account Number and G/L Account Number of a House Bank (DB)

Transaction Code
FI12

5.     HOW DO YOU DISTRIBUTE THE BANK MASTER DATA?

If you wish to process bank master data and the related company addresses in any of the systems of an SAP system group, then the ALE business process allows for all changes to bank master data to be made via a consolidation system. The local systems send all the changes to the consolidation system, and the consolidation system sends the changes back to all the local systems. The banks can also be processed in the consolidation system. The address from the central address management is distributed together with the bank. The address data from central address management must be processed before the banks in the target system.

You need to determine a system within the system group as the consolidation system where you will make all the cross-system settings. Then you need to (a) define all the systems involved in the distribution (logical system settings), (b) maintain the distribution model via “Add BAPI,” and (c) generate the partner profiles to determine the point at which the data should be exchanged between the systems (Figure 4.6).

FIGURE 4.6  Steps to Distribute Bank Master Data

Note that you can only distribute the bank master data of banks whose bank keys have been set by the bank number or external assignment.

6.     WHAT IS LOCKBOX PROCESSING?

Lockbox processing (configured in the FR-TR module) of incoming payments is used predominantly in the United States. Here, the bank receives the checks from customers as incoming payment, creates payment advice for each of these customer check payments, and informs the payee about the payment in BAI file format. This lockbox file is sent to the payee, who imports the details into the system using this electronic file. The system updates the payments into the G/L by way of batch input processing.

7.     WHAT ARE THE IMPORTANT CONTROL PARAMETERS FOR LOCKBOX PROCESSING?

At present, only the procedure “LOCKBOX” is supported by SAP as the control data for lockbox processing. The payment information provided in the bank data file will create a payment advice per check. This payment advice will be used by the lockbox procedure to clear subledger open items. These data are needed for importing lockbox files (only BAI and BAI2 file formats are supported by SAP) sent by banks:

•  BAI record format

Specify the length of the document numbers (10 in the standard SAP System) and the number of document numbers in record types 6 and 4 of the BAI file. Your bank must agree on this format information (Figure 4.7).

FIGURE 4.7  BAI Record Format

•  BAI2 record format

It is not necessary to specify the length of the document or the number of document numbers in record types 6 and 4. This is because the BAI2 file is designed so each document number is on a different record type 4 with its corresponding payment and deduction amounts. Your bank must agree on this format information (Figure 4.8).

FIGURE 4.8  BAI2 Record Format

Transaction Code
OBAY

•  Posting functions (batch input sessions)

Specify which postings the system creates (G/L cash postings and/or customer cash application). It is recommended that both choices be selected if you are using the G/L and A/R modules. For the G/L, you can decide whether to post one aggregate amount to the incoming cash account or one line per check. This depends on your reconciliation with the bank. In addition, you can choose to create and name a batch input session to insert any missing or new customer bank details into the customer master records (this can only be done if the system identifies a valid document number) (Figure 4.9).

FIGURE 4.9  Posting Functions

8.     WHAT DO YOU DO IF THE FILE FORMATS ARE NOT EXACTLY THE SAME AS BAI AND BAI2?

While the BAI and BAI2 formats are supposedly standard, experience has shown that they can vary by bank, and many SAP clients have contracted for a customized format. What is required is that the format received must be mapped to reconcile with the SAP delivered data dictionary layout (Tables FLB01, FLB05, FLB06, etc.) to ensure proper processing.

If the format does not reconcile and the user does not want to have the bank change the format, SAP recommends that a user-written ABAP be used to reformat the file, or alternatively, the SAP data dictionary can be modified (this is a repair that will need to be reapplied in future releases).

9.     HOW DOES THE LOCKBOX PROGRAM IDENTIFY THE CUSTOMER?

The lockbox program first attempts to identify the customer with unique bank information in the customer master record matching to MICR information on the check, so maintenance of unique customer MICR information is important to ensure success. If there is more than one customer with the same MICR bank and account, then the program cannot apply the check to an account. This situation usually means that either the same customer has been set up twice or maybe what should have been only Ship-to or Sold-to customers for the same Payer have actually been set up as separate Payers. Alternatively, it may be necessary to set up a relationship where one customer is identified as the main Payer and has MICR info and the related customers do not have MICR info but instead have the main Payers customer number in the “Alternate Payer” field of the customer master record.

10.   WHAT ARE THE POSTING DATA FOR A LOCKBOX?

You need to store information needed to process particular lockbox data and generate postings. The destination and origin are routing information and are 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 clearing account

•  A/R posting

•  Debit payment clearing account and credit customer account

You need to complete the following:

•  Specify a company code that holds the lockbox

•  Enter the G/L account number that corresponds to the lockbox (clearing) bank account in the bank account number–bank (clearing) acct field.

•  Enter the the G/L account number that corresponds to the AR clearing account (the balance in this account will represent all unapplied (lockbox) payments) in the bank clearing acct–payment clearing acct.

•  Specify the document types and posting keys for these postings (Figure 4.10).

FIGURE 4.10  Posting Data for Lockbox

Transaction Code
OBAX

11.   WHAT IS A LOCKBOX FOR YOUR HOUSE BANK?

By defining lockbox accounts at the house banks, you can optimize the payment transactions. On the outgoing invoice you can inform your customer of the lockbox to which payment is to be made. You may define the lockbox accounts using the following menu path: SAP Customizing Implementation Guide > Financial Accounting (New) > Bank Accounting > Bank Accounts > Define Lockboxes for House Banks.

•  Specify your lockbox links (company code; key of the lockbox to which the customer is to pay; house bank ID; lockbox number at your house bank).

•  For customer master data, you can determine to which lockbox number the customer is to pay in the application menu (“payment transactions/company code data”).

•  Include two new fields in table VBDKRZ—for example, ZZBANK for the house bank ID at which you have the lockbox, and ZZLOCK for the lockbox number. Note that the names of these fields must begin with “ZZ,” because SAP has left these name ranges free for new, user-defined fields.

•  The user interface for the outgoing invoice needs to be expanded. To do this, you have to enhance program V05NZZEN as follows:

TABLES: KNB1, T049L. SELECT SINGLE * FROM KNB1 WHERE KUNNR = VBDKRKUNRG AND BUKRS = VBRK-BUKRS. SELECT SINGLE * FROM T049L WHERE BUKRS = VBRKBUKRS AND LOCKB = KNB1-LOCKB. VBDKR-ZZLOCK = T049L-LCKNR. VBDKR-ZZBANK = T049L-HBKID.

•  Include the new fields VBDKR-ZZBANK (key of the house bank at which you have the lockbox) and VBDKR-ZZLOCK (lockbox number) in the form for the customer invoices (SD application).

Transaction Code
OB10

12.   WHAT IS IBAN?

IBAN (International Bank Account Number) is a standardized, uniform representation of complete bank details in accordance with the European Committee for Banking Standards (ECBS) (Figure 4.11). A constant IBAN length has been stipulated for each country. An IBAN is a series of a maximum of 34 alphanumeric characters and is made up of a combination of the following elements:

•  The bank country key (ISO-Code)

•  Two check digits

•  Country-specific account number (consists of, for example the bank number and account number in Germany, or the bank number, account number, and control key in France)

FIGURE 4.11  IBAN in Bank Master Data

13.   HOW DO YOU CONFIGURE THE CHECKS FOR BANK MASTER DATA?

You can specify check rules for country-specific definitions. The rules apply to the bank number (“1” in Figure 4.12) or the bank key and bank account number (“2” in Figure 4.12). For each country key, enter the length of the bank number and the bank account number. The check rule determines whether:

•  The entry is numeric or alphanumeric

•  The length specified is only a maximum length or whether this must be strictly adhered to

•  Gaps are permitted in the bank account number or bank number

The system always carries out these formal checks. You can also select additional special checks (“3” in Figure 4.12) to avoid input errors. These include, for example:

•  Postal check account number in Germany and Switzerland

•  Bank account number in Belgium and the Netherlands

•  Bank number and bank account number in France

You may configure the country-specific checks using the following menu path: SAP Customizing Implementation Guide > SAP NetWeaver > General Settings > Set Countries > Set Country-Specific Checks.

Transaction Code
OY17

FIGURE 4.12  Country-Specific Checks for Bank Master Data

14.   WHAT IS A REPETITIVE CODE IN BANK ACCOUNTING?

Repetitive codes are the payment transfer data that remain unchanged and are used to simplify frequently recurring payments with the same payment details. The data include the sender bank, sender account, recipient bank, recipient account, payment method, and currency. Maintenance of a repetitive code reduces the administrative work required for frequently recurring payments with the same payment details. The only details that are different for each payment are the amount and the note to payee. In addition, in the United States, a company can agree on a repetitive code with its house bank. The bank then only needs the repetitive code, the amount, and (if required) the note to payee in order to process a payment order (Figure 4.13).

Transaction Code
OT81

FIGURE 4.13  Repetitive Code in Bank Accounting

15.   WHAT IS AN INTERMEDIATE BANK?

Intermediate banks are used in SAP in addition to the house banks and partners banks for making or receiving payments from business partners abroad. The payment processing involving an intermediate bank uses the bank chain, which may consists of a house bank, a partner bank, and a maximum of intermediate banks.

16.   WHAT IS A BANK CHAIN?

Before SAP brought in bank chain functionality, when making a payment to a business partner abroad, you had to specify your house bank and the business partner’s bank when processing payments. These two banks represented the start and end of the payment cycle, and it was up to the house bank to determine via which bank(s) the payment should be made. Using the bank chain function (for example, via the correspondence banks of the house bank, the recipient bank, or the intermediary banks), you can now specify this bank chain yourself, leading to faster payment transaction processing and considerable cost savings through reduced bank charges. SAP allows you to define up to three banks in a bank chain. To use the bank chain function, you must also implement the function “Automatic Payments” in either the Financial Accounting (FI) or the Treasury (TR) application component.

17.   HOW IS THE BANK CHAIN USED DURING A PAYMENT RUN?

For each payment, the payment program can determine a combination of intermediary banks that you previously defined. The order of the banks in the bank chain can depend on the following factors:

•  Currency

•  Customer’s bank details

•  House bank

•  Payment method supplement

•  Treasury business partner’s bank details

•  Vendor’s bank details

These factors are represented in the SAP system by means of scenarios for bank chain determination that you define in “Customizing for Bank Accounting.”

•  Copy one of the scenarios that are delivered in the standard system or define a new scenario (Figure 4.14).

FIGURE 4.14  Scenario for Bank Chain

•  Activate the scenario.

•  If you want payments to be made via a bank chain and independently of a business partner’s bank details, define a general bank chain.

Transaction Code
FIBC

If you carry out a payment run (whether for open items or for payment requests from treasury or cash management), the system determines the bank chain according to your customizing settings and those you made in the master data. If during payment proposal editing you have changed an entry (house bank or partner bank, for example) that is relevant to bank chain determination, the system redetermines the bank chain, which is then displayed on screen. The system is only able to determine the bank chain if a payment method is used for which a bank chain is needed (no bank chain is determined for payments by check, for example). When processing payments, you can use program RFZALI20 to create a payment list and an exception list. The payment list contains a summary of all payments and line items. The exceptions list contains blocked line items and open items that the payment program did not propose for payment. In the standard system, the bank chain in not included on either list. The bank chains are transferred each time a payment medium is created.

18.   HOW DO YOU HANDLE CASHED CHECKS?

If you receive data on cashed checks electronically from your bank, you can use program RFEBCK00 to import the data into the SAP system after having converted it to SAP format. This program imports the information on cashed checks delivered by the bank and generates the clearing entries (debit outgoing checks account, credit bank account). It also marks as “paid” the checks in the check register that could be posted. The clearing entries can be placed in a batch input session (batch input mode) or be posted immediately (call transaction mode). Because there is no standard for data on cashed checks in the United States and most other countries, a preprocessing program is needed to convert the bank format to the entry format of this program.

19.   WHAT IS ELECTRONIC CHECK DEPOSIT?

Electronic check deposit enables you to process data supplied by an external entry system (check reader). However, the data must be delivered in a format defined by SAP to process the data. The data are transferred from a file to the bank data buffer. Some of the fields have to be entered manually during this process. If the external entry system does not supply the entries for these fields, you must enter them as parameters when you run the program (optional entries for the check deposit list). To avoid importing the same file several times, you can have the external entry system uniquely indicate the file and then have the SAP system check this indicator.

If the data are complete, the electronic check deposit can also create the batch input session directly. If the transfer is incomplete, you can access manual check deposit for postprocessing the check deposit list you entered. You may use this as an entry function and then complete and post individual data with the manual check deposit.

Two batch input sessions are created to post the check deposits:

•  One session for bank account postings

•  One session for subledger postings

Using the appropriate parameter, you can specify whether the system should create both sessions and only the session for bank postings first. If you want to use the manual transaction for postprocessing the data, you cannot create any sessions. Further processing is then carried out by using the manual transaction. You either name the sessions when importing the data or have the program name the sessions with the house bank ID and account ID.

20.   WHAT IS MANUAL CHECK DEPOSIT?

This function manual check deposit is used to enter checks you receive. After the input is complete, you can access the additional functions to further process the entered checks. On the entry screen, the system will display different fields for each account assignment variant you choose. Depending on the number of account assignment fields in a variant, up to three lines are available for entering a memo record. You can change the account assignment variant at any time during processing. If you have used more account assignment fields than are available in the current variant, the system will display this information in an additional field. You can, for example, enter several document numbers and different invoice amounts for one memo record. This is useful if a customer pays several invoices with one check. The system highlights the account assignment field when you have entered several values in it.

Transaction Code
FF68

21.   WHAT IS THE MAIN FUNCTION OF AN ELECTRONIC BANK STATEMENT (EBS)?

The Electronic Bank Statement (EBS) is used to automatically assign payments (by check, bank transfer, etc.) received by/made from house bank accounts to the appropriate open items (which items have already been posted in the system).

22.   WHAT INFORMATION IS ON AN ELECTRONIC BANK STATEMENT (EBS)?

The electronic bank statement contains the following information:

•  Header data: general information on the house bank (bank number and account number, account currency, statement number, and statement date)

•  Line item data: list of individual business transactions that were posted to the account (line items)

23.   WHAT ARE THE FORMATS OF AN ELECTRONIC BANK STATEMENT (EBS)?

There are three formats available at present:

•  MultiCash format

This format is created from the account statement data received from the banks (usually SWIFT MT940) using the BCS (Banking Communication Standard) software. Standard for all banks, it can be easily run using a spreadsheet program or a software program. It consists of two files in format AUSZUG.TXT and UMSATZ.TXT. The AUSZUG.TXT contains the header information for the account statements, and UMSATZ.TXT contains the item information. This format allows you to import data from several account statements at the same time, including those from different banks.

•  Swift MT940

SWIFT MT940 should only be used in cases where it is not possible to use the MultiCash format. This format is available in two variants: with or without structured field 86.

•  DTAUS format

SAP does not recommend this format unless there are some valid and compelling reasons from the business side to go in for this. The DTAUS format originated in the mainframe era and has certain disadvantages:

- Individual data records are not separated by the special character denoting a “new line” (Carriage-Return Line-Feed <CR><LF>), and this renders the search for errors extremely difficult in cases where the bank has transmitted defective files.

- Even if a single byte is missing from the file, the whole file is rendered unreadable, because every subsequent data record is displaced by one byte.

This format only contains a single business transaction (for example, cash receipt) per file and therefore only represents a fraction of the items processed in an account. Using the DTAUS format usually entails importing more than one file into the system. In addition, certain business transactions (that are not supported by this format) may need to be posted manually. Moreover, the header record of DTAUS files does not contain any reference to the statement from which the items originated (such as statement date or number). This means that the import program cannot carry out the usual checks, such as those that prevent the same items from being imported more than once or that check that imported data are complete.

24.   WHAT PROBLEMS MIGHT YOU ENCOUNTER WHEN USING ELECTRONIC BANK STATEMENTS (EBS)? HOW YOU CAN OVERCOME THEM?

There are two main obstacles in customizing an electronic bank statement:

•  Creating the files UMSATZ.TXT (header data) and AUSZUG.TXT (line items) is a complex process. Experience has shown that many implementation errors arise from incorrect creation (format errors) of these files. Using actual files from the bank is also difficult because the files are usually very big.

•  The open items to be found and cleared using the electronic bank statement must usually be entered into the (test) system manually and with correct clearing information. This information must also exist in the correct fields in the individual line items in the UMSATZ.TXT file (for example, in the note to payee fields).

You may, however, overcome these obstacles by using the program RFEBKATX to create open items in a company code and the related (MULTICASH) account statement files for a house bank account. You can, then, import this directly using program RFEBKA00 and so test both your customizing settings and the general functions provided by program RFEBKA00.

25.   WHAT IS AN EXTERNAL TRANSACTION IN AN ELECTRONIC BANK STATEMENT (EBS)?

An external transaction (or business transaction code) is a bank-specific code for a business transaction. Issued by the bank in the electronic bank statement, each of the external transaction codes involves a different type of payment, and the SAP system requires this code to identify the business transaction. It converts these bank-defined codes into its own system-internal transaction codes (known as posting rules), which in turn trigger certain specific posting transactions in the system

Some examples of the external transaction code (ETC) are shown in Table 4.1.

TABLE 4.1  External Transaction Codes in Bank Accounting

26.   WHAT IS A POSTING RULE IN AN ELECTRONIC BANK STATEMENT (EBS)?

To configure the electronic bank statement, all the external transactions need to be assigned to a posting rule to enable the system to determine which bank or subledger accounts these transactions are to be posted to. The posting rules are represented in the system by a non-bank-specific code (for example, 0001 for debit memos). The posting rules are required to rationalize postings so you do not duplicate the postings on the SAP side. The chart below shows two external transactions, both of which require the same posting in your accounts. Accordingly, you just need to assign them to a single posting rule (say, 001—debit memo).

27.   WHAT DO PLUS (+) AND MINUS (−) SIGNS MEAN IN POSTING RULES IN AN ELECTRONIC BANK STATEMENT (EBS)?

Plus (+) signs are entered in customizing when assigning external transactions to posting rules. The + sign represents incoming payments and the minus (−) sign represents outgoing payments. A different posting rule can apply to the same external transaction depending on the + or − sign.

28.   WHAT IS A TRANSACTION TYPE IN AN ELECTRONIC BANK STATEMENT (EBS)?

The transaction types are used to group together banks providing the same external transaction codes in the electronic bank statement. By doing this, it is not necessary to assign the banks’ external transaction codes to internal SAP posting rules for every individual bank, but only have to make this assignment once per transaction type. Once a transaction type is defined, you need to assign each of your house banks to a transaction type.

29.   WHAT IS A POSTING AREA IN AN ELECTRONIC BANK STATEMENT (EBS) CONFIGURATION?

When configuring the electronic bank statement, you must deal with two posting areas: area 1 and area 2. Depending on the external transaction code and your customizing settings, a single line item from an electronic bank statement can automatically trigger up to two posting transactions:

•  Area 1 postings are made to bank or G/L accounts.

•  Area 2 posting are made to subledger accounts (these are additional postings).

30.   HOW DO YOU CONFIGURE THE GLOBAL SETTINGS FOR AN ELECTRONIC BANK STATEMENT (EBS)?

The following are the recommended sequences of configuring the global settings you need to make in customizing for electronic bank statements:

•  Define transaction types

Group together all banks that use the same external transaction code for certain business transactions under the same transaction type (Figure 4.15).

FIGURE 4.15  Create Transaction Types

•  Assign bank (accounts) to transaction types

Assign each of your bank accounts to a transaction type. You can specify a worklist of G/L accounts. This enables you to search several bank subaccounts for open items that the system could not clear during posting of the account statement when you postprocess the account statement. If you select the field “No Automatic Clearing,” an open item remains, even if the amount of the open item agrees with that in the account statement (Figure 4.16).

FIGURE 4.16  Assign Bank Accounts to Transaction Types

•  Create keys for posting rules

Assign posting rules to possible transactions in the account statement file (Figure 4.17). A list of assignments where one external transaction code is assigned to one posting rule is called a transaction type (Figure 4.18).

FIGURE 4.17  Create Keys for Posting Rules

FIGURE 4.18  Define Posting Rules

•  Assign external transaction types to posting rules

You assign (external) business transaction codes to an (internal) posting rule. This means that the same posting specifications can be used for different business transaction codes (Figure 4.19).

FIGURE 4.19  Assign External Transaction Types to Posting Rules

•  Define posting rules

You need to complete the following activities here:

(a)  Create the account symbols for the required posting transactions

Specify G/L accounts (such as bank, cash receipt, outgoing checks) to which postings are to be made from the account statement. You assign account symbols to the G/L account numbers. These are required for the posting rules in the step “assign accounts to account symbols” (Figure 4.20).

FIGURE 4.20  Create Account Symbols

(b)  Define account determination rules for each of the account symbols.

Define postings to be triggered by possible transactions in the account statement (such as bank transfer, debit memo). In the “posting specifications debit -> credit” that you define here, use the account symbols from the previous step, not the G/L account numbers. This prevents similar posting rules from being defined several times, the only difference between them being the accounts to which postings are made (Figure 4.21).

FIGURE 4.21  Assign Accounts to Account Symbols

You create posting specifications for postings to G/L or bank accounts (posting area 1) and subledger postings (posting area 2) for those of the posting transactions you choose.

31.   WHAT IS THE POSTING/CLEARING FLOW IN AN ELECTRONIC BANK STATEMENT (EBS)?

Say you have already imported the EBS into your SAP system. Imagine that one of your customers has paid an open invoice by bank transfer (to your house bank account):

a  The transaction triggers 2-level posting in your system:

i.  Bank posting (cash receipt is posted to a clearing account such as a cash receipt account)

ii. Subledger posting (system locates the customer and clears the item from this account)

b.  However, to complete this, the system will look for the following information from the statement:

i.  The business transaction (for example, transfer by credit memo) must be identified. The system must then apply a rule to determine how that business transaction is posted in the system (account determination).

ii. Clearing information must be found (document numbers, for example) so the customer open items can be cleared.

c.  The system will look for the above information in the following sequence:

i.  It finds the transaction type in the customizing table using the bank key (say, 075000022) and the bank account (say, 068173602).

ii. It determines the posting rule key in the customizing table from the transaction type and the external transaction code’s/bank’s business transaction code.

iii. From the posting rule key, it determines the posting specifications and the account determination rules that you defined in the configuration of the electronic bank statement.

d.  Now the system proceeds to clear the customer open item, and this is accomplished as follows:

The system finds the necessary information for this in the note to payee lines in the statement. Using the document number or the reference document number, the system finds and clears the document. The document number or the reference document number is found for the note to payee information using “interpretation algorithms.”

If the entire flow, as detailed above, is successful, then the system posts the data in the system. Though the entire process should normally be error-free, there can be situations where postprocessing (Transaction Code FEBAN) manual intervention would be required to correct errors, if any.

32.   WHAT IS A CURRENCY CLASS?

If you import bank statements containing currency keys that are different from the ISO currency keys that SAP delivers with its standard system, then you will require the currency classes. It is possible that you can combine alternative currency keys in a single currency class. Then the alternative currency keys within a currency class are assigned to the SAP currency key. This assignment is required so the electronic bank statement program can process the currency keys transmitted by your house bank and customers.

Transaction Code
OT74

33.   WHY MUST PLANNING TYPES BE ASSIGNED TO CERTAIN TRANSACTIONS?

You need to assign planning types to certain transactions made in the bank account to determine the bank accounts for which cash management payment advices are generated by certain information from the bank. (If a planning type is not assigned for certain cases, an advice note is not created.) This type of account statement can currently be processed only when you use the American BAI format or IDoc interfaces (logical message FINSTA—document type ACP). Note that this activity is necessary only when you use account statements from the present day that update cash management and forecast but do not update accounting. When assigned, the system can generate a cash management payment advice for the following information:

•  Adjustment amounts relating to check presentation amounts from the previous day

•  Current account balance

•  Total of first debit of checks presented on that day (checks within the state)

•  Total of second debit of checks presented on that day (checks outside the state)

34.   WHAT IS A PAYMENT REQUEST?

A document for generating payment media, payment requests can be generated automatically when payments that are due are posted. They are subsequently settled individually or collectively using the Treasury payment program.

CHAPTER

5

ASSET ACCOUNTING (FI-AA)

1.     WHAT IS ASSET ACCOUNTING (FI-AA)?

In SAP, the Asset Accounting (FI-AA) submodule manages a company’s fixed assets, right from the acquisition to retirement/scrapping. All the accounting transactions relating to depreciation, insurance, and so on of assets are taken care of through this module, and all the accounting information from this module flows to FI-G/L on a real-time basis (Figure 5.1).

FIGURE 5.1  FI-AA Integration with Other Modules

You will be able to directly post (the goods receipt (GR), invoice receipt (IR), or any withdrawal from a warehouse to a fixed asset) from MM or PP to FI-AA. The integration with FI-AR helps in direct posting of sales to the customer account. Similarly, integration with FI-AP helps in posting an asset directly to FI-AA and the relevant vendor account in cases where the purchase is not routed through the MM module. You may capitalize the maintenance activities to an asset using settlements through the PM module. FI-AA and FI-G/L have real-time integration where all the transactions such as asset acquisition, retirement, transfer and so forth are recorded simultaneously in both the modules. However, batch processing is required to transfer the depreciation values, interest, and so on to the FI module.

The FI-AA and CO integration helps in:

•  Assigning an asset to any of the Controlling objects like cost center, internal order/maintenance order, or an activity type. Internal orders act as two-way links to the FI-AA. They help to collect and pass on the capital expenditure to assets, and they collect the depreciation/interest from the FI-AA to Controlling objects. (Note that when there is a situation where the asset master record contains an internal order and a cost center, the depreciation is always posted to the internal order and not to the cost center.)

•  The depreciation and the interest are passed on to the cost/profit centers.

2.     WHAT IS THE LEAN IMPLEMENTATION IN FI-AA?

The lean implementation is the scaled-down version of the regular FI-AA configuration in IMG, with minimal configuration required to enable asset accounting. This is suitable in cases of small companies using the standard functionalities of asset accounting and also in situations where the “Asset Catalogue” is not that large (Figure 5.2).

FIGURE 5.2  Lean Implementation in FI-AA

You should not opt for lean implementation if:

•  You need more than two depreciation areas

•  You need to depreciate in foreign currencies as well

•  You have group assets

•  You need to define your own depreciation keys/transaction types/reports

•  You need a group consolidation

Transaction Code
OASI

3.     WHAT ARE THE KINDS OF ASSETS IN SAP?

An asset can be a simple asset or a complex asset. Depending on the requirement, assets are maintained with asset main number and asset sub-numbers. A complex asset consists of many subassets, each of which is identified with an asset sub-number. You may also use the concept of group asset in SAP.

4.     WHAT ARE COMPLEX ASSETS AND ASSET SUB-NUMBERS?

A complex asset is made up of many master records, each of which is denoted by an asset sub-number. It is prudent to use asset sub-numbers under the following circumstances:

•  You need to manage the subsequent acquisitions separately from the initial one (for example, your initial acquisition was a PC, and you are adding a printer later).

•  You want to manage the various parts of an asset separately even at the time of initial acquisition (for example, initial purchase of PC where you create separate asset master records for the monitor, CPU, etc.).

•  You need to divide the assets based on certain technical qualities (keyboard, mouse, etc.).

When you manage a complex asset, the system enables you to evaluate the asset in all possible ways, such as for a single sub-number, for all sub-numbers, and for select sub-numbers.

5.     WHAT IS A GROUP ASSET? WHEN YOU WILL USE THIS?

A group asset is almost like a normal asset except it can have any number of subassets denoted by asset sub-numbers. The use of group assets becomes necessary when you need to carry out depreciation at a group level for some special purposes like tax reporting. Remember the way of depreciation in SAP is always at the individual asset level. Hence, to manage at the group level, you need the group asset. Once you decide to have group assets, you also need to have special depreciation areas meant for group assets. You will not be able depreciate a group asset using a normal depreciation area.

Unlike complex assets, you can delete a group asset only when all the associated sub-numbers have been marked for deletion.

6.     WHAT IS ASSET SUPER NUMBER IN SAP?

The concept of asset super number in FI-AA is used only for reporting purposes. Here, you will assign a number of individual assets to a single asset number. By doing so, you will be able to see all the associated with the asset super number as a single asset (for example, brake assembly line) or as individual assets (for example, machinery, equipments in the brake assembly line).

7.     WHAT IS CHART OF DEPRECIATION? HOW IS IT DIFFERENT FROM A CHART OF ACCOUNTS?

A chart of depreciation contains lists of country-specific depreciation areas. It provides the rules for the evaluation of assets that are valid in a given country or economic area (Figure 5.3). SAP comes supplied with default charts of depreciation that are based on the requirements of each country. These default charts also serve as the reference charts from which you can create a new chart of depreciation by copying one of the relevant charts of depreciation. After copying, you may delete the depreciation areas you do not need. However, note that the deletion must be done before any assets are created.

FIGURE 5.3  Sample Charts of Depreciation

You are required to assign a chart of depreciation to your company code. Remember that one company code can have only one chart of depreciation assigned to it, even though multiple company codes can use a single chart of depreciation.

The chart of accounts can be global, country-specific, and industry-specific, based on the needs of the business. The chart of depreciation is only country-specific. Both the charts are independent of each other (Table 5.1).

TABLE 5.1  Chart of Depreciation and Chart of Accounts: Differences

Chart of Depreciation

Chart of Accounts

Established in FI-AA.

Established in FI.

A chart of depreciation is a collection of country-specific depreciation areas.

The chart of accounts is a list of G/L accounts used in a company code. The chart of accounts contain a chart of accounts area and a company code area.

The chart of depreciation is country-specific. Usually you may not require more than one chart of account. SAP comes delivered with many country-specific charts of depreciation as reference charts that can be copied to have your own chart of depreciation.

Depending on the requirement, you may have an operating chart of accounts, a country-specific chart of accounts, a global chart of accounts, etc.

One company code uses only one chart of depreciation.

One company code uses only one chart of accounts.

Many company codes in the same country can use the same chart of depreciation.

Several company codes in the same country can use the same chart of accounts.

8.     HOW DO YOU CREATE AN ASSET ACCOUNTING COMPANY CODE?

•  Define the company code in FI configuration, and assign a chart of accounts to this company code.

•  Assign a chart of depreciation to this company code in FI-AA configuration.

•  Add the necessary data for the company code for use in FI-AA, and your asset accounting company code is now ready for use.

9.     WHAT IS DEPRECIATION? WHAT ARE THE VARIOUS TYPES OF DEPRECIATION?

Depreciation is the reduction in the book value of an asset due to its usage over time (decline in economic usefulness) or due to the legal framework for taxation reporting. The depreciation is usually calculated taking into account the economic life of the asset, the expected value of the asset at the end of its economic life (junk/scrap value), the method of depreciation calculation (straight line method, declining balance, sum of year digits, double declining, etc.), and the defined percentage decline in the value of the asset every year (20% or 15% and so on).

10.   WHAT IS PLANNED DEPRECIATION? HOW IT IS DIFFERENT FROM UNPLANNED DEPRECIATION?

Depreciation can either be planned or unplanned:

•  Planned depreciation is one that brings down the value of the asset after every planned period—say, every month—until the asset value is fully depreciated over its life period. By this, you will know the value of the asset at any point of time in its active life.

•  Unplanned depreciation is a sudden happening of an event or occurrence not foreseen (there could be a fire that damages an asset and forces you to depreciate fully because it is no longer useful economically), resulting in a permanent reduction of the asset’s value.

11.   WHAT ARE THE THREE TYPES OF DEPRECIATION IN SAP?

In SAP, you will come across three types of depreciation:

•  Ordinary depreciation, which is nothing but the planned depreciation

•  Special depreciation, which is over and above the ordinary depreciation, used normally for taxation purposes

•  Unplanned depreciation, which is the result of reducing the asset value due to the sudden occurrence of certain events

12.   WHAT IS THE DEPRECIATION AREA?

The fixed assets are valued differently for different purpose (business, legal, etc.). SAP manages these different valuations by means of depreciation areas (Figure 5.4). Some depreciation areas are book depreciation, tax depreciation, depreciation for cost-accounting purposes, and so on.

FIGURE 5.4  Depreciation Area

A depreciation area decides how and for what purpose an asset is evaluated. The depreciation area can be real or derived. You may need to use several depreciation areas for a single asset, depending on the valuation and reporting requirements.

The indicator under the column “G/L” in Figure 5.4 determines how that particular depreciation area updates the values to a G/L Account (Figure 5.5).

FIGURE 5.5  How a Depreciation Area Posts to G/L

The depreciation area is denoted by a 2-character code in the system. The depreciation areas contain the depreciation terms that are required to be entered into the asset master records or asset classes. SAP comes delivered with many depreciation areas; however, the depreciation area 01—Book depreciation is the major one.

The other depreciation areas include:

•  Book depreciation in group currency

•  Consolidated versions in local/group currency

•  Tax balance sheet depreciation

•  Special tax depreciation

•  Country-specific valuation (e.g., net-worth tax or state calculation)

•  Values/depreciations that differ from depreciation area 01 (for example, cost-accounting reasons)

•  Derived depreciation area (the difference between book depreciation and country-specific tax depreciation)

13.   WHAT IS DEPRECIATION AREA TYPE?

The fixed assets are valued differently for different purpose (business, legal, etc.). SAP uses an additional attribute, called depreciation area type, for use in the “Annex 16” legal report to classify depreciation areas for fixed assets. (“Annex 16” is a legal report that Japanese companies must submit with their tax returns. It contains data about a company’s fixed assets and the amount of depreciation relevant to the fixed assets.) “Annex 16” uses the depreciation area type to determine the purpose of each depreciation area. The type is assigned according to the primary purpose of the depreciation area. Note that all the depreciation areas in the standard charts of depreciation have a depreciation type assigned already (for example, depreciation area 01 is of the type “balance sheet valuation”), and when you create a chart of depreciation, the system takes over this type from the standard reference chart of depreciation.

Transaction Code
OADC

14.   WHAT IS A DERIVED DEPRECIATION AREA?

The derived depreciation is a separate depreciation area that is derived from two or more real depreciation areas using a predetermined rule (Figure 5.6). You can use derived depreciation areas, for example, to calculate special reserves as the difference between tax and book depreciation. The book value rule in a derived depreciation area is checked each time a posting is made or depreciation is changed in the corresponding real area. Because the values are derived, the system does not store any values in the database but updates the derived values whenever there are changes in the real depreciation area or its depreciation terms. You may also use the derived depreciation only for reporting purposes.

FIGURE 5.6  Real and Derived Depreciation Areas

15.   WHAT IS THE FUNCTION OF DEPRECIATION AREAS?

Depreciation area 01, which can be set up as the book depreciation, can make automatic postings to the G/L (Figure 5.7).

FIGURE 5.7  Book Depreciation (01): Typical Settings

Other depreciation areas may get their values from depreciation area 01 but calculate and post different depreciation values to the general ledger. Other depreciation areas can be set up to show country-specific valuation (i.e., tax depreciation); values/depreciations that differ from depreciation area 01 (i.e., cost-accounting reasons); consolidated versions in local/group currency; book depreciation in group currency; and the difference between book, 01, and country-specific tax depreciation (derived depreciation area).

16.   HOW DO YOU SET UP DEPRECIATION AREA POSTINGS FROM FI-AA TO FI?

To do this, you must define how the various depreciation areas need to post to FI-G/L. It can be any one of the following scenarios:

•  Post-depreciation through periodic processing

•  Post both the APC (Acquisition and Production Costs) and depreciation through periodic processing

•  Post the APC in real-time but depreciation through periodic processing

•  No values are posted

However, you need to ensure that at least one depreciation area is configured to post values automatically to the FI-G/L. Normally, this depreciation area will be 01 (book depreciation). For the rest of the depreciation areas, it may be configured that they derive their values from this area and the difference thus calculated is automatically posted to FI-G/L. There may also be situations where you may define depreciation areas just for reporting purposes, and these areas need not post to the G/L.

17.   WHAT IS AN ASSET CLASS?

An asset class is the basis for classifying an asset based on business and legal requirements (Figure 5.8). It is essentially a grouping of assets having certain common characteristics. Each asset in the system needs to be associated with an asset class.

Asset class is the most important configuration element that decides the type of asset (like land, buildings, furniture and fixtures, equipment, assets under construction, leased assets, low value assets, etc.), the document number range, data entry screen layout for asset master creation, G/L account assignments, depreciation areas, depreciation terms, and so on. An asset class is defined at the client level and is available to all of that client’s company codes. It is possible to assign any number of charts of depreciation to each asset class, so you can have country-specific depreciation terms (the default values in the given chart of depreciation) for each combination of asset class and chart of depreciation.

FIGURE 5.8  Asset Class

Transaction Code
OAOA

The asset class consists of:

•  A header section: control parameters for master data maintenance and account determination

•  A master data section: default values for administrative data in the asset master record

•  A valuation section: control parameters for valuation and depreciation terms

The control parameters and the master data section of the asset class are always valid for all company codes within a client. However, it is also possible to specify that certain general master data is dependent on the chart of depreciation and to use it also to provide default data

The asset class can be:

•  Buildings

•  Technical assets

•  Financial assets

•  Leased assets

•  AuC (Assets under Construction)

•  Low value assets (LVA)

18.   WHY DO YOU NEED ASSET CLASSES?

An asset class is the link between the asset master records and the relevant accounts in the G/L. The account determination in the asset class enables you to post to the relevant G/L accounts. Several asset classes can use the same account determination, provided all these asset classes use the same chart of accounts and post to the same G/L accounts.

19.   WHAT IS AN ASSET CLASS CATALOGUE?

An asset class catalogue contains all the asset classes in an enterprise and that are thus valid across the client. Because an asset class is valid across the client, most of the characteristics of the asset class are defined at the client level, but some characteristics (like the depreciation key, for example) can be defined at the chart of depreciation level.

20.   CAN YOU CREATE ASSET CLASSES AUTOMATICALLY?

One of the benefits of lean implementation configuration is the ability to create asset classes automatically from the asset balance sheet G/L accounts (system generates these asset classes automatically in a one-to-one relationship to the accounts) (Figure 5.9). This tool selects the only necessary system settings, so the asset classes are created automatically in a very short time. During the process of creation, the system allows you to delete all the existing objects—asset classes, number ranges, account allocations, field selections, and so on—before creating the new ones.

The prerequisites for automatic asset class creation include:

•  Company code is assigned to a chart of depreciation

•  Depreciation areas have been defined

•  G/L account number is not more than 8 digits (otherwise, you need to assign the classes manually)

FIGURE 5.9  Generate Asset Class from G/L Accounts (1 to 1)

This processing view has seven navigation levels. The first navigation level is the overview screen containing the generating function. The next six navigation levels are detail screens for this overview screen. Work through all of the detail screens before you can start the generation of the asset classes in the first navigation level. The first detail screen (account selection) has to be processed first. There is no hierarchy for the remaining detail screens (no detail screens for the prior navigation level). They are not dependent on one another. You can work through each of these screens independently from the other.

It is important to understand that you may need to maintain the G/L account for accumulated depreciation manually. The system maintains the necessary account assignment only with regard to the depreciation area 01 (book depreciation). If you need more areas other than 01, you may need to do that manually in the IMG.

Transaction Code
ANKL

21.   WHAT IS CONTROL INFORMATION IN AN ASSET CLASS?

The control information in an asset class can be grouped into 2 sections:

•  General control information

•  Control information in the valuation section

The general control information includes:

•  Asset type (account determination, screen layout control for the master data, etc.)

•  Number/sub-number assignment

•  Special functions (control indicators for AuC, lock status, real estate, etc.)

The valuation section control information includes:

•  Deactivation of a depreciation area

•  Depreciation key and useful life

•  Index series

•  Screen layout for depreciation area

•  Control indicator (for managing negative values, maximum/minimum useful life allowed, activation of quantity and amount related check for collectively managed LVA and activation of amount check for individually checked LVA)

22.   CAN YOU DELETE AN ASSET CLASS?

Yes, you can delete an asset class as long as the company code is in the “implementation” status. When the company code is in implementation status and:

•  No assets have been created in an existing asset class, that class is deleted and generated again

•  There are assets in an existing asset class (but no transactions)

- You can delete all asset classes and their assets and generate them again or

- You can only add new asset classes

•  Transactions exist for the assets, you can only add new asset classes

If the company code is in production status, the system creates only asset classes that were not yet created. Existing classes remain unchanged.

23.   WHAT IS AN INDEX SERIES?

The index series is used for calculating replacement values (Figure 5.10). To use the index series functionality, you must have provided for using revaluation when the depreciation area involved was defined. You also need to use a depreciation key that allows you to depreciate from replacement values.

FIGURE 5.10  Index Series

You need index figures if you want to calculate using replacement values. You should maintain the index figures beginning with the point in time that the oldest asset with an index series was acquired, up to the time of the takeover of old assets data. The system needs these past index figures to correctly calculate the replacement values and insurable values for assets transferred during the old assets data takeover. It is absolutely necessary that you maintain your index series with the correct index figures before old assets data are taken over. Index figures of years prior to the data takeover (after the old assets data takeover has taken place) can only be changed with considerable effort.

Transaction Code
OAV5

24.   HOW DO YOU CALCULATE REPLACEMENT VALUE WITHOUT AN INDEX SERIES?

It is possible to calculate replacement values for all assets in later fiscal years—even after the productive start of the system—even if there is no index series at the time of the old assets data takeover. However, for previous acquisitions, you can then only use index series that provide for “historical calculation” in their index class. You can calculate the current replacement value with such an index series using the following formula:

Value (current year) = APC * index (current year) / index (acquisition year)

After calculating the replacement value in this way, you can change to a different index series in the following year, which calculates on the basis of the replacement value from the previous year.

25.   WHAT IS AN ASSET VALUE DATE?

The asset value date will be the start date of depreciation for the asset. The planned depreciation is calculated by the system based on this depreciation start date and the selected depreciation term for that asset. Be careful with the posting date and asset value date because both need to be in the same fiscal year.

26.   WHAT IS AN ASSET MASTER?

An asset master can be created by copying an existing asset in the same company code or another company code. It can also be created from scratch when it is done for the first time. Again, while creating the master, SAP allows you to create multiple assets in one go, provided all such assets are similar (having the same asset class and all belonging to the same company code).

From Release 4.5, the transaction codes for creating the asset master have been changed to AS series instead of the earlier AT series (for example, create asset is by AS01 (AT01 earlier), change asset is AS02 (AT02 earlier), and so on). If you are still comfortable with creating assets using the conventional screen than with the tab feature available now in the AS transaction series, the good news is that you are welcome to do so, but you cannot find these transactions under “ASMN”!

Each asset master contains the necessary information to calculate the depreciation:

•  Capitalization date/acquisition period

•  Depreciation areas relevant for the asset

•  Depreciation key

•  Useful life/expired useful life

•  Change over year, if any

•  Scrap value, if any

•  Start date of (ordinary depreciation)

27.   WHAT KINDS OF DATA ARE MAINTAINED IN AN ASSET MASTER?

The master data in an asset master relate to the following:

•  General data (description, capitalization date, inventory date)

•  Time-dependent assignments (for example, cost center)

•  Allocations (evaluation groups, investment support measures)

•  Information on the origin of the asset

•  Specifications for net worth tax

•  Insurance data

•  Leasing information (especially the relevant data for the opening entry and, if necessary, determination of present value)

28.   WHAT IS THE MAINTENANCE LEVEL?

The maintenance level in FI-AA defines the level (asset class, main asset number, sub-number) at which a field in an asset master record is to be maintained. The maintenance level definition is part of the screen layout rule. If, for example, you define the maintenance level as the “main asset number” for a field, then the field will be filled with a default value from the asset class. However, you will be able to change the field when maintaining master data at the asset main number level.

The three maintenance levels are:

•  Asset class

•  Asset main number

•  Asset sub-number

29.   WHEN DO YOU USE ASSET SUB-NUMBERS?

A complex fixed asset can be represented in the system using several master records—that is, sub-numbers. Assets may be divided using sub-numbers if:

•  Managing the values for subsequent acquisitions in following years (i.e., buildings) separately

•  Managing the values for individual parts of assets separately

•  Dividing the asset according to various technical aspects

30.   HOW DO YOU CREATE AN ASSET MASTER?

The creation of an asset master depends on whether you are (a) creating an entirely new asset or (b) adding to an existing asset in the system.

If you are creating an entirely new asset, you can create it by:

•  Entering the appropriate asset class in the initial screen of asset master creation transaction

•  Referencing to an existing asset already in the system

If you are adding to an existing asset, you need to locate the asset main number and add the new one as a sub-number. The system will use the same asset class of the main asset to the newly created subasset.

31.   CAN YOU CREATE MULTIPLE ASSETS IN A SINGLE TRANSACTION?

SAP enables you to create multiple (but similar) assets in one transaction (Figure 5.11). You can use the standard transaction for creating an asset, but you must enter the number of assets you need to create in the “number of similar assets” field. Ensure that all these assets belong to the same asset class and the same company code.

After creating the assets, you will be able to change the individual descriptions/inventory numbers when you are about to save the master records. When you save the master records, the system assigns a range of asset numbers. The only drawback of using this method of creating assets in bulk is that you will not be able to create long text for any of these assets.

Transaction Code
AS01

FIGURE 5.11  Create Asset: Initial Screen

32.   WHAT TIME-DEPENDENT DATA ARE IN THE ASSET MASTER?

All the cost accounting assignment–related data like cost center, internal orders, investment projects, and so on need to be maintained as time-dependent data in asset masters (Figure 5.12). Additionally, the information relating to asset shutdown and shift operation also needs to be maintained as time dependent. SAP maintains all the time-dependent data for the entire life span of the assets.

FIGURE 5.12  Time-Dependent Cost Center Data

33.   HOW DO YOU MAKE CHANGES TO AN ASSET MASTER?

SAP handles the changes to an asset master in several ways, based on what kind of information is changed:

•  General master data/time-dependent allocations that are NOT relevant to the balance sheet: the normal or general information relating to an asset master can be changed simply by changing the information in the relevant fields. This is true regarding the time-dependent allocations that are not relevant to the balance sheet (say, “plant”).

•  Time-dependent allocations that are relevant to the balance sheet:

there are two ways of doing this:

- Changing the assignment using the master data transaction, however, you can only use this method if the business area and cost center master data fields are not managed as time dependent (set the business area and cost to time-independent in customizing). When you use this method, the system displays the new business area or cost center/profit center in all subsequent reports (even if the report is for a time period prior to the change) because it cannot create a history for the earlier assignment to a cost center/profit center.

- Change the assignment of business area or cost center/profit center by posting an asset transfer to a new master record, rather than making the change in the asset master data. Use this method if the business area and cost center master data fields are managed as time dependent. When you use this method, the system displays the business area or cost center that is valid for the given time period in all reports.

•  Change in asset class: this is possible only by posting a transfer to a new asset master record. Copy the asset master record that you want to change by creating a new master record using the “reference” method and making the necessary changes in the new master record. Either create the new master record with a new asset class or enter a new business area in the time-dependent data for the new asset.

34.   WHY IT IS NECESSARY TO BLOCK AN ASSET MASTER RECORD?

If you decide you do not want to post any more acquisitions to an existing asset, then it is necessary to set the block indicator (also known as the acquisition lock) in the asset master record (Figure 5.13). The default is none, and you can select the radio button “locked to acquis” to block further acquisitions. This is usually the case with AuC, where after the capitalization you no longer want any further additions to the asset. The block indicator prevents only further postings but not transfers, retirements, or depreciations. Even after blocking, the asset can continue to be depreciated the same way as other assets.

FIGURE 5.13  Block Indicator (Acquisition Lock) in Asset Master

Transaction Code
AS05
AS23 (Group Asset)

35.   WHAT IS DEACTIVATION OF AN ASSET?

The system automatically assigns a deactivation date to an asset (as a result of the retirement posting) when you scrap or sell it. Such deactivated assets can be removed from the database and transferred to an archive file. However, because the asset history sheet includes transactions from the previous year, the deactivated assets from the previous year cannot be reorganized or archived (minimum residence time = 1 year).

If you reverse the retirement posting, the system removes the deactivation date. You can also cancel the deactivation date manually in the master record if at a later point in time you want to post subsequent acquisitions to the asset.

36.   HOW DO YOU DELETE AN ASSET?

It is possible to delete an asset (master record) to which no postings have been made, directly online, without archiving. It is also possible to manually delete old assets (legacy assets from your previous system) during the asset data transfer process:

•  Delete all the transferred values for the old asset using the old asset change transaction.

•  Set the deactivation date for the old asset using the old asset change transaction (in the first master data screen).

•  Delete the old asset using the delete transaction.

Transaction Code
AS06
AS26 (Group Asset)

37.   WHAT IS AN ASSET TRANSACTION TYPE IN FI-AA?

Transaction types in FI-AA identify the nature of the asset transaction (acquisition, transfer, or retirement) to specify what is updated among the depreciation area, value field, and asset accounts (in B/S) (Figure 5.14).

FIGURE 5.14  Transaction Types

The following are some of the common transaction types used:

•  100Asset acquisition—purchase

•  110Asset acquisition—in-house production

•  200Asset retirement—without revenue

•  210Asset retirement—with revenue

The transaction type is extensively used in most of the asset reports, including the asset history sheet, to display the various asset transactions differentiated by the transaction types. SAP comes with several transaction types that will take care of almost all of your requirements. However, should there be a specific case, you may also create your own transaction type.

Every transaction type is grouped into a transaction type group (for example, 40 -‾ post-capitalization) that characterizes the various transaction types (for example, transaction types 400 and 490) in that group (Figure 5.15). The system makes it possible to limit the transaction type groups be associated with certain asset classes.

FIGURE 5.15  Transaction Type Group

38.   WHAT IS AN ASSET ACQUISITION?

Asset acquisition can be through any one of the following three routes:

1.  External acquisition through purchase

External acquisition of assets will be primarily from vendors who are either your business partners or third parties. It can also be from your affiliated companies (use Transaction Code: ABZP). The external asset acquisition can be through different ways:

i.  The asset can be posted in MM module.

ii.  The asset can be created in FI-AA with automatic clearing of the offsetting entry (Transaction Code: ABZON). This can be achieved in the following ways:

•  The posting is made initially in FI-AP, and the clearing account is cleared when the posting is made to the asset (FI-AA).

•  Post the asset with the automatic offsetting entry (FI-AA), and then clear the clearing account through a credit posting by an incoming invoice (FI-AP).

When not integrated with FI-AP, you may acquire the asset in FI-AA with an automatic offsetting entry without referencing to a purchase requisition (PR). This kind of acquisition is necessary when:

•  You have not yet received the invoice or

•  When the invoice has already been posted in FI-AP

When integrated with FI-AP, acquire the asset in FI-AA using an incoming invoice but without a reference to a purchase order (PO).

2.  In-house production/acquisition

In-house asset acquisition is primarily the capitalization of goods/services your company produces. The costs associated with the complete or partial production of the goods/services from within the company need to be capitalized into separate asset(s). Usually, the capitalization is done as follows:

•  Create an order/project (in “Investment Management”) to capture the production costs associated with the goods/services produced in-house

•  Settle the order/project to an AuC (Asst under Construction)

•  Distribute/settle the AuC so it is made into new asset(s)

You will be using the Transaction Type 110 for asset acquisition from in-house production.

3.  Subsequent acquisition
When the asset/vendor accounts are posted, the system updates the corresponding G/L accounts (FI-AP and FI-AA) through relevant account determinations. SAP uses various kinds of transaction types to distinguish the different transactions. During acquisition, the system makes the following entries in the asset master data:

•  Date of initial acquisition/period and year of acquisition

•  Capitalization date of the asset

•  Start date for ordinary depreciation (start date is determined from the asset value date/period/year of acquisition)

•  Vendor is automatically entered in the origin

39.   WHAT DATA ARE AUTOMATICALLY SET IN THE ASSET MASTER DURING INITIAL ACQUISITION?

The following information is automatically set in the asset master during initial acquisition:

•  Acquisition period

•  Date of capitalization

•  Depreciation start date (per depreciation area)

•  Posting date of original acquisition

40.   CAN YOU POST ASSET ACQUISITION IN TWO STEPS (OR TWO DEPARTMENTS)?

Yes, it is possible to post assets in two steps or in two departments.

When the asset acquisition is posted in two steps or two different departments, you normally post to a clearing account. Use a general ledger account with open item management to guarantee that this account can be cleared. Either the FI department includes this clearing account in their periodic run (of automatic clearing program) or the clearing account has to be cleared in an additional step.

41.   WHAT ARE THE IMPLICATIONS OF VALUED/NONVALUED TRANSACTIONS IN FI-AA?

For non-valued transactions, the goods receipt (GR) takes place before the invoice receipt (IR) and the values are not yet posted to FI-AA. The line items are created, and the values are updated instead at the time of the invoice receipt. However, the system uses the date of the goods receipt as the capitalization date. At the time of invoice receipt, the asset is capitalized, line items are created, and the value fields are updated.

On the other hand, for the valued transaction, the GR takes place before the invoice receipt, and the values are posted directly to asset accounting. The asset is capitalized, line items are created, and the value fields in the asset are updated. When the invoice is received later, there may be differences between the invoice amount and the amount posted at the time of goods receipt. In this case, the corresponding adjustment postings are made to the asset.

42.   WHAT ARE ASSETS UNDER CONSTRUCTION (AUC) IN SAP?

The goods and/or services produced in-house can be capitalized into asset(s). But there are two distinct phases during this process:

•  Construction phase (AuC)

•  Utilization phase (useful or economic life phase)

It then becomes necessary to show the assets under these two phases in two different balance sheet items. The construction phase is the one in which you start producing or assembling the asset and is not yet ready for putting into economic utilization. SAP categorizes these kinds of assets into a special asset class called Assets under Construction (AuC). The AuC is to be managed through a separate asset class with a separate asset G/L account. SAP allows posting down payments to AuC. It is also possible to enter credit memos for AuC even after its complete capitalization, provided you are managing this asset class allowing negative APC (Acquisition and Production Costs). The IM (Investment Management) module helps to manage internal orders/projects for AuC. It is necessary tto use the depreciation key “0000” to ensure that you are not calculating any depreciation for AuC. But you can continue to have special tax depreciation and investment support even on these assets.

43.   HOW DO YOU CAPITALIZE AUC IN SAP?

An AuC can be managed in two ways as far as the asset master is concerned:

•  As a normal asset

•  As an asset with a line item management

Later, the AuC is capitalized and transferred to regular asset(s) by distribution/settlement. While doing so, the system, with the help of different transaction types, segregates the transactions relating to the current year with those of the previous years. The capitalization can be:

•  Lump sum capitalization

•  With line item settlement (when capitalized using line item settlement, it is not necessary to settle (a) all the line items and (b) 100% in a particular line item)

In the case of integration with SAP-IM (Investment Management), capital investments can be managed as AuC by:

•  Collecting the production costs associated with an order/project

•  Settling the collected costs to an AuC

•  Capitalizing the AuC into new assets by distribution/settlement

Transaction Code
AIAB (Capitalize AuC by Distribution)
AIBU (Capitalize AuC by Settlement)

44.   WHAT IS LOW VALUE ASSETS (LVA)?

SAP uses the term Low Value Assets (LVA) to denote assets that will be depreciated in the year of purchase or in the period of acquisition. This categorization usually follows the statutory requirements of the country of the company code where you define a monetary limit and consider all those assets falling below the value—say, ä1,000—as LVA. You have the flexibility of managing these assets either on an individual (individual check) or collective (quantity check) basis.

SAP uses a special depreciation key called LVA, and the expected useful life of such an asset is considered to be one period (month).

45.   WHAT IS AN ASSET TRANSFER IN SAP?

There are two types of asset transfers:

1.   Intercompany asset transfer

2.   Intracompany asset transfer

An intercompany asset transfer is between the company codes, resulting in the creation of the new asset in the target company code (the receiving one). The transaction posts the values as per the posting method selected during the transfer. In doing so, the system:

•  Retires the asset in the source/sending company code by an asset retirement

•  Posts acquisition in the new/target company code by an asset acquisition and creates the new asset in the target company code

•  Posts intercompany profit/loss arising out of the transfer

•  Updates FI-G/L automatically

An intercompany asset transfer is usually necessitated when (a) there is a need for physically changing the location from one company to the other or (b) there is an organization restructuring resulting in the new asset being attached to a new company code. You may use the standard transfer variants supplied by SAP. The selection of a suitable transfer variant will be based on (1) the legal relationship among the company codes and (2) the methods chosen for transferring the asset values.

Intercompany asset transfer can be handled:

•  Individually, using the normal transaction for a single asset

•  For a number of assets using the mass transfer

If you need to transfer assets cross-system, you need to use ALE functionality.

Transaction Code
ABT1N

An intracompany asset transfer is the transfer of an asset within the same company code. This would have been necessitated by:

•  Change in the asset class or business area

•  Settlement of an AuC to a new asset

•  Transfer of stock materials into an asset (by posting a GI to an order through MM or settlement of a production order to an asset)

•  Splitting an existing asset into one or more new assets

Transaction Code
ABUMN

46.   WHAT IS A TRANSFER VARIANT?

A transfer variant is dependent on whether the company codes involved are legally dependent or independent (Figure 5.16).

FIGURE 5.16  Transfer Variant

Transfer variants specify (1) the transfer method (one of the four methods) for the capitalization of the transferred assets in the target company code and (2) the type of transaction (acquisition or transfer) used for the transaction. You can specify in each transfer variant which master data fields should be copied from the transferred asset to the target asset if a new asset has to be created in the target company code (Figure 5.17).

FIGURE 5.17  Specifications in a Transfer Variant

47.   WHAT IS ASSET RETIREMENT IN FI-AA?

Asset retirement is an integral part of asset management. The asset retirement results in removal of an asset or a part of an asset from an asset portfolio. The retirement can be through a sale or scrapping.

During asset sales transactions, the system removes the APC and also the corresponding accumulated depreciation. Then the profit or loss arising out of the sale is recorded in the system. Even in the case of partial retirement or partial sales, the system records the proportionate gain/loss arising out of the transaction. Any tax posting arising out of the transaction is automatically created by the system.

SAP recognizes the types of asset retirement shown in Figure 5.18.

FIGURE 5.18  Asset Retirement

48.   WHAT IS SCRAPPING IN FI-AA?

Scrapping (also known as asset retirement without revenue) is the removal of an asset from the asset portfolio without any revenue (Figure 5.19). During scrapping, the system does not create revenue and gain/loss postings but creates a loss from an asset retirement without revenue posting in the amount of the net book value being retired.

Transaction Code
ABAVN

FIGURE 5.19  Asset Scrapping

49.   HOW DOES SAP HANDLE THE PARTIAL RETIREMENT OF AN ASSET?

The asset retirement can be (a) complete retirement (relating to an entire fixed asset) or (b) partial retirement (relating to a part of a fixed asset). In either case, the system automatically determines (based on the asset retirement date you enter) the amounts to be charged off for each depreciation area.

The complete retirement of a fixed asset is only possible if all transactions to the asset were posted with a value date before the asset value date of asset retirement. You must clear or reverse down payments and investment support measures that are in the same posting year as the retirement before you post the complete retirement.

The partial retirement of a fixed asset can be initiated by entering any one of the following:

•  APC amount being retired: when you enter the APC amount that is being retired, the system determines the percentage to be retired from the asset using the first depreciation area in which posting is to take place and uses the same percentage for other areas.

•  A percentage rate

•  A quantity: you can enter a quantity if you have not specified the APC amount or percentage rate. The system interprets the quantity as a ratio to the total quantity of the asset and thereby determines the asset retirement percentage rate.

The asset value date of the retirement is recorded in the asset master record. You cannot post any transactions with a value date before the value date of the last retirement. If you nevertheless need to post such a transaction, you must first reverse all retirements that lie after the value date of the belated posting. After posting the belated transaction, you can then repost the retirements.

50.   WHY IS IT IMPORTANT TO SELECT THE RIGHT TRANSACTION TYPE FOR RETIREMENT?

It is imperative that you select the correct transaction type for both partial and complete retirement. For the complete retirement of a fixed asset acquired in previous years, always select a transaction type intended for prior-year acquisitions. A partial retirement can always relate either to prior-year acquisitions or to current-year acquisitions. Prior-year asset acquisitions and current-year acquisitions are shown separately in the document.

51.   WHAT IS AN ASSET SALE WITH CUSTOMER?

In the case of an asset sale with customer, the system enables you to post the entry to FI-A/R, the revenue posting and the asset retirement in one step. You post the revenue first, and then you post the asset retirement. An indicator in the posting transaction specifies that the system posts the asset retirement after the revenue posting. The prerequisite for this is that the sales revenue account in FI, to which the revenue should be posted, has a field status variant in its master data in which the asset retirement field (category “Asset Accounting”) is defined as a required or optional entry field.

•  Asset sale with revenue

a.   With customer (involving integration with FI-A/R)

•  Debit customer, credit assets

Transaction Code
F-02

52.   WHAT ARE PROPORTIONAL VALUE ADJUSTMENTS IN ASSET RETIREMENT?

The system automatically determines the reference period for the retirement, based on the value date and period control. It automatically determines any depreciation (value adjustments) that is applicable to the part of the asset being retired, up to the reference period (retirement). It then automatically retires this depreciation at the time of the retirement transaction. This procedure ensures that the percentage of the book value that is retired is identical to the percentage of the APC that is retired.

The system automatically posts the proportional value adjustments retired during an asset retirement. The system uses transaction type 290 for proportional values with retirements. For transfers, it uses transaction types 390/395 (transfer retirement/acquisition). These transaction types are entered in the customizing definition of the retirement or transfer transaction types (value adjustments function). These special transaction types for the proportional value adjustments are particularly important for group consolidations so the individual transaction can be identified as retirement of transfer.

53.   IS THERE A SPECIAL REQUIREMENT FOR RETIRING LVA?

There are certain special considerations for the retirement of low value assets (LVA) due to the large number of assets that are being retired, calling for a simplified business transaction. It is not necessary to actually post the retirement of LVA for the assets transactions to be displayed correctly in the asset history sheet. It is possible to simulate the retirements of low value assets during a time period you specify. Enter the LVA asset classes and the simulation time period in the initial screen of the “There are special considerations for the retirement of low value assets (LVAs).” It is usually necessary to simplify the business transactions involved due to the large number of assets that are being retired. It is not necessary to actually post the retirement of low value assets for the assets transactions to be displayed correctly in the asset history sheet. It is possible to simulate the retirements of low value assets during a time period you specify. Enter the LVA asset classes and the simulation time period in the initial screen of the asset history sheet.

54.   CAN YOU RETIRE SEVERAL ASSET SUB-NUMBERS SIMULTANEOUSLY?

It is possible to post complete retirements of several sub-numbers of a fixed asset in one step (generic entry using an asterisk (*) in the sub-number field). However, instead of using this generic entry with an asterisk, you can use complete retirement of several sub-numbers of an asset. In the transaction “SAP Easy Access Screen ‾ Accounting ‾ Financial Accounting ‾ Fixed Assets ‾ Posting ‾ Acquisition ‾ External Acquisition ‾ Acquis. w/ Autom. Offsetting Entry, maintain the asset number, choose , and choose . All sub-numbers for the asset are displayed in the “List of assets.” You can remove from the list any sub-numbers you do not want to retire.

55.   WHAT IS MASS RETIREMENT OF ASSETS?

When you plan to sell a large portion of your company’s asset portfolio (say, a rolling mill), it is necessary to post the retirement of all the individual assets that make up the whole. Because the number of assets involved can be extremely high, the FI-AA component makes it possible to carry out the retirement using mass posting. To carry out a mass retirement, you need the “normal” authorization for asset transactions, as well as authorization for the authorization object “A_PERI_BUK” (authorization for periodic processing) with activity 40. This authorization is contained in the standard profile “A_ALL.” The selection of the assets involved and the basic procedure for mass retirement is carried out using the same functions as a mass change to asset master data. Create/use a work list; make the entries like a posting date, transaction type, and revenue/type of revenue distribution needed for posting the mass retirement; and then follow the rest of the procedure like in a mass change.

56.   WHAT ARE WORK LISTS?

Work lists are used for mass retirements, mass changes, and work on incomplete assets. There are three steps in using work lists:

•  Select the objects (assets) to be changed.

•  Assign the task to be performed on the objects.

•  Release the work list and process the workflow.

57.   WHAT ARE DEPRECIATION KEYS?

Depreciation is calculated using the depreciation key and the internal calculation key in the system (Figure 5.20).

Depreciation keys are defined at the chart of depreciation level and are uniform across all company codes, which are attached to a particular chart of depreciation. The depreciation key contains all the control amounts defined for the calculation of planned depreciation. The system contains a number of predefined depreciation keys (like LINA, DWG, DG10, etc.) with the controls already defined for calculation method and type. A depreciation key can contain multiple internal calculation keys.

FIGURE 5.20  Depreciation Keys

58.   WHAT IN AN INTERNAL CALCULATION KEY?

The internal calculation key makes up a part of the depreciation key, and it defines a method, base value, and rate of percentage for depreciation; changeover rules (for declining depreciation); and treatment of depreciation after useful life and period control for transactions (Figure 5.21).

Each internal calculation key contains:

•  Depreciation type (ordinary or unplanned)

•  Depreciation method (straight-line or declining balance)

•  Base value

•  Rate of percentage for depreciation calculation

•  Period control for transactions (acquisition, retirement, etc.)

•  Changeover rules (in case of declining/double declining methods of calculation)

•  Treatment of depreciation after useful life period

FIGURE 5.21  Internal Calculation Key

59.   WHAT IS THE SIGNIFICANCE OF THE DEPRECIATION KEY 0000?

Depreciation key 0000 is an SAP-delivered key that ensures that depreciation and interest are not calculated and posted. This key can be used for Assets under Construction (AuC).

60.   WHAT IS PERIODIC PROCESSING IN FI-AA?

Periodic processing are the tasks that must be performed at periodic intervals (Figure 5.22). Because only the values from one depreciation area can be automatically posted online in Financial Accounting, the changes to asset values (transactions) from other areas with automatic postings have to be posted periodically to the appropriate reconciliation accounts.

Figure 5.22 shows the tasks under periodic processing in FI-AA.

FIGURE 5.22  Periodic Processing

You may use the Schedule Manager (Transaction Code SCMA) to schedule and monitor the various tasks that need to be processed periodically.

61.   HOW DOES THE SYSTEM POST IMPUTED INTEREST TO CO?

If you calculate imputed interest on the capital tied up in assets, then the system posts this interest simultaneously during the periodic depreciation posting run. It posts to the accounts that are entered in the relevant account determination for each depreciation area. Furthermore, an additional account assignment can be made to the cost center or the internal order entered in each asset master record (same for depreciation).

62.   WHAT IS A DEPRECIATION RUN IN SAP?

The depreciation run, an important periodic processing, takes care of calculating depreciation for the assets and posting the corresponding transactions in both FI-AA and FI-G/L. The depreciation calculation is usually done in sessions, and the posting session posts the different depreciation types, interest/revaluation, and writing-off/allocating special reserves. The depreciation run should be started with a test run before making it the production run, which will update the system. The system provides the facility to restart a run session should there be problems in the earlier run. The depreciation run needs to be completed per period. During every depreciation run, the system will create summarized posting documents per business area and per account determination. No individual posting documents are created.

63.   WHAT ARE THE STEPS IN A DEPRECIATION RUN?

The following are the sequence of steps in a typical depreciation run:

1.  Maintain the parameters for the depreciation run on the initial screen of the Transaction AFAB (company code, fiscal year, and posting period).

2.  Select a reason for the posting run (repeat run, planned posting run, restart run, or unplanned run).

3.  Select the appropriate checkboxes in the “further option” block if you need a list of assets, direct FI posting, test run, and so on. Please note that it is a good idea to select the test run initially, verify the outcome of the depreciation run, and then remove this checkbox and perform the productive run.

4.  Execute the test run (if the assets are less than 10,000, you may then do the processing in the foreground; otherwise, execute the run in the background).

5.  Check the results displayed.

6.  Once you are convinced that the test run has gone as expected, go back to the previous screen, uncheck the test run checkbox, and execute (in the background).

7.  Complete the “background print parameters” if prompted by the system. You may also decide to schedule the job immediately or later. The system uses the depreciation-posting program “RABUCH00” for updating the asset’s values and generating a batch input session for updating FI-G/L. The posting session posts values in various depreciation areas, interest, and revaluation, in addition to updating special reserves allocations and writing off, if any. If there are more than 100,000 assets for depreciation calculation and posting, you need to use a special program “RAPOST00.”

8.  Process the “batch input session” created by the system in step 7. You may use the Transaction Code SM35. Again, you have the option of processing the session in the foreground or in the background.

9.  The system posts the depreciation in FI-G/L.

64.   HOW DOES THE SYSTEM CALCULATE THE DEPRECIATION?

The system calculates the depreciation as follows:

1.  The system takes the depreciation terms from the asset master record and calculates the annual depreciation for the asset, taking into account the useful life and the depreciation key. The start date for depreciation is assumed to be the first date of acquisition of the asset.

2.  The system may also calculate other values like interest, revaluation, and so on.

3.  The depreciation and other values like those in #2 are calculated for each of the depreciation areas.

65.   HOW THE SYSTEM DETERMINE THE DEPRECIATION START DATE?

Normally, the system determines the depreciation start date from the asset value date of the first acquisition posting.

66.   WHAT IS A REPEAT RUN IN THE DEPRECIATION PROCESS?

A repeat run is normally used at the end of the fiscal year to carry out posting adjustments or corrections that may arise due to changes in depreciation terms or manual depreciation calculations. However, you can also use this to repeat, but only within the same posting period. The repeat run also provides the flexibility to restrict the calculations to specific assets.

67.   WHAT IS RESTART A DEPRECIATION RUN?

Restart depreciation run is used only when there has been a problem with the previous run resulting in termination of that run. To make sure that all the steps in a depreciation run are completed without errors, the system logs the status at every stage of the processing and provides error logs to locate the problem. This option of restart is not available during the test run mode.

68.   WHAT IS DEPRECIATION SIMULATION?

Depreciation simulation refers to “what if” valuation of assets. This is achieved by changing and experimenting with the parameters required depreciating the assets. The simulation helps you to foresee the depreciation should there be changes in various depreciation terms. You may simulate to see the valuation for the future fiscal years. Sort versions and options for totals report are also available in simulation. The depreciation simulation can be applied to a single asset or your entire asset portfolio.

69.   CAN YOU SELECT “DIRECT FI POSTING” FOR A DEPRECIATION RUN?

If the checkbox to enable “direct FI posting” is checked off, then the system will not create the batch input session for depreciation posting. Instead, the FI-G/L is posted directly. Be careful when checking off the “direct FI posting” box because there will not be an opportunity to correct mistakes, if any, in accounts and account assignments like business area, cost objects, and so on, when you execute the depreciation run. Also, there will be no possibility to check and correct postings. Note that if this option is selected during a depreciation run, and if the run is terminated for any reason and must be restarted, this has to be kept checked during that time as well.

The standard system comes with the document type “AF” (number range defined as external numbering) configured to be used in batch input. Hence, with this default configuration, you will get an error when you try the depreciation posting run by selecting the option “direct FI posting.” You can, however, overcome this by not restricting the same FI-AA customization (use Transaction Code OBA7, and remove the check mark from the “Btch input only” checkbox).

70.   DOES THE SYSTEM POST INDIVIDUAL DOCUMENTS WHEN YOU RUN RABUCH00?

No. The depreciation posting program RABUCH00 updates the assets values and generates a batch-input session for the update of the G/L. The posting session also posts the different depreciation types, interest, and revaluation, in addition to the writing-off and allocation of special reserves. The system does not create individual documents but only summarized posting documents (per business area per account determination).

71.   WHAT DOCUMENT NUMBER RANGE DO YOU USE FOR AUTOMATIC DEPRECIATION POSTINGS?

For each company code, a document type must be defined for posting depreciation. The depreciation program should only use a document type that is limited to being used for batch input. In this way, unintentional use of the document type can be prevented. It is also essential that the document type be assigned a number range with an external number assignment. The depreciation program can then assign the document numbers itself. If the numbers are assigned in this way, the depreciation posting program can keep a check on posting to FI. If errors occur, this numbering also makes it possible to make corrections.

72.   WHAT IS THE DIFFERENCE BETWEEN SMOOTHING AND CATCH-UP?

•  SAP uses two methods to distribute the forecasted depreciation to the various posting periods: smoothing and catch-up (Figure 5.23).

The smoothing method distributes depreciation evenly to the periods from the current depreciation period to the end of the fiscal year (regardless of the value date of the transaction). With the catch-up method, the depreciation on the transaction (from the start of capitalization up to the current period) is posted as a lump sum. The depreciation posting program posts this amount in the posting period in which the value date of the transaction appears.

FIGURE 5.23  Smoothing versus Catch-Up

73.   WHAT IS THE TRANSFER OF LEGACY ASSET DATA TO SAP?

One of the challenges in the implementation of FI-AA is the transfer of legacy asset data from your existing systems to SAP FI-AA. Though SAP provides multiple options and appropriate tools to carry out this task, you need a carefully planned strategy. You may resort to transferring the old asset values through any one of the following ways:

•  Batch data inputs (large number of old assets)

•  Directly updating the SAP tables (very large number of old assets)

•  Manual entry (few old assets)

Normally, you will not be resorting to the manual process because it is time consuming and laborious. However, you may do this if you have a very limited number of assets. Otherwise, you may use either of the other two options, though batch data input with error handling would be the preferred way of doing it. You need to reconcile the data transferred if you resort to any of the two automatic ways of transferring the data. You may also use BAPIs (Business Application Programming Interface) to link and process the asset information in SAP FI-AA from non-SAP systems.

The transfer can be at the end of the last closed fiscal year or during the current fiscal year following the last closed fiscal year. You will be able to transfer both master data and the accumulated values of the last closed fiscal year. If required, you can also transfer the asset transactions, including depreciation, during the current fiscal year. It is important to note that the G/L account balances of the old assets need to be transferred separately.

74.   WHAT IS AUTOMATIC TRANSFER OF OLD ASSETS?

SAP provides you with the necessary interfaces for converting your legacy asset data into prescribed formats for uploading into the SAP system (Figure 5.24). The data transfer workbench allows you to control the entire data transfer process.

1.  These interface programs convert the data to be compatible with the SAP data dictionary tables like BALTD for master data and BALTB for transactions. If you have more than 10 depreciation areas, then you need to change the transfer structures for both BALTD and BALTB.

2.  The converted data are stored in sequential files.

3.  Use the data transfer program RAALTD01 (for batch input) or RAALTD11 (direct table update) for transferring the data to SAP.

•  Do a test run. This will help to correct any errors.

•  Do a production run, with a few asset records, to update the relevant tables in FI-AA.

•  Reset the values in the asset company code.

•  Continue with the production run for all the assets.

4.  All the asset records without errors will be updated immediately through background processing in the relevant tables like ANLH, ANLA, ANLB, ANLC, and so on.

5.  The records with errors will be stored in a separate batch input session that can be processed separately.

FIGURE 5.24  Legacy Asset Transfer to SAP FI-AA

75.   WHAT ARE THE THREE METHODS OF OLD ASSET DATA TRANSFER BASED ON THE NUMBER OF ASSETS?

Table 5.2 shows the three methods of data transfer in FI-AA.

TABLE 5.2  Methods of Transferring Old Asset Data

Number of Old Asset Accounts

Method of Asset Transfer

Small

Create old asset manually (dialog transaction)

Large

Batch-input procedure (RAALTD01)

Very Large

Direct data import (RAALTD11)

76.   WITH ANY OF THE OLD ASSET TRANSFER METHODS, WILL G/L IN FI BE UPDATED?

No. Balance reconciliation with the relevant G/L accounts must take place separately. G/L personnel can input these via FI, or AA personnel can input them via the transfer balance screen in AA. With up-to-date accounts in the already productive FI, there is no need to update them.

77.   WHAT IS THE ASSET TRANSFER DATE?

The asset transfer date refers to the cutoff date for the transfer of old assets data from your existing system. Once established, you will not be able to create any old asset in SAP before this reference date. Any transaction happening after the transfer date but before the actual date of asset transfer needs to be created separately in SAP after you complete the old asset transfer.

The two possibilities are:

•  At the end of the last closed fiscal year

•  In the fiscal year following the last closed fiscal year

78.   WHAT DATA ARE TRANSFERRED IN THE YEAR-END TRANSFER AND THE SUB-ANNUAL TRANSFER?

Year-end transfer and transfer during fiscal year:

•  Master data

•  Cumulative values as of the end of the last closed fiscal year

Sub-annual transfer (if the transfer date is after the closed fiscal year)

•  Master data

•  Cumulative values as of the end of the last closed fiscal year

•  Depreciation and asset transactions posted in the current year (transfer parameters)

79.   WHAT ARE THE TWO WAYS TO TRANSFER DEPRECIATION POSTED IN THE CURRENT YEAR?

You can either of the following two methods:

•  Transferring the depreciation posted in the current fiscal year up to the point of transfer: It is necessary to specify the last posted depreciation period in the legacy system for each depreciation area for every asset company code.

•  Posting the total depreciation for the current fiscal year up until the transfer date after the old data transfer: This is done in AA by performing a posting run for unplanned depreciation.

80.   WHAT TRANSFERS/POSTINGS ARE ALLOWED IN THE DIFFERENT SAP ENVIRONMENTS?

Table 5.3 shows the types posting allowed in different environments: test, transfer, and production.

TABLE 5.3  Different Environments in FI-AA

Environment

Old Data Transfer

Postings

Test

P

P

Transfer

P

V

Production

V

Only current

81.   WHAT IS MASS CHANGE? HOW DO YOU DO THIS?

Mass change enables you to make changes (like mass retirements, changes to incomplete assets, etc.) in FI-AA to a large number of asset master records all at the same time. The mass change functionality is achieved through work lists that are FI-AA standard tasks predefined in the system. These tasks are assigned with work flow objects that can be changed according to your specific requirements. The work lists are created in several ways from asset master records, asset value displays, asset information systems, and so on.

To effect a mass change, you need to:

1.  Create substitution rule(s) in which you will state all the fields that must be changed. This rule will consist of an identifying condition (for example, if the cost center = 1345) and a rule to substitute new values (for example, replace the field cost center with the value “1000”).

2.  Generate a list of such assets that must be changed.

3.  Create a work list to carry out the changes.

4.  Select the appropriate substitution rule (defined earlier in step 1)

5.  Process the work list. You may also release it to someone else in the organization so he/she can complete this task.

6.  Run a report to verify the changes.

82.   WHAT IS THE YEAR CLOSING IN FI-AA?

The year end is closed when you draw the final balance sheet. But to reach this stage, you need to ensure that the depreciation is posted properly. You can achieve this by checking the depreciation list and also the asset history sheets. After this is done, draw the test balance sheet and the profit and loss statement and check for the correctness of the depreciation. Correct the discrepancies, if any, by adjustment postings. You need to rerun the depreciation posting program if you change any of the depreciation values.

Now when you run the year-end closing program, the system ensures that the fiscal year had been completed for all the assets, depreciation had been fully posted, and there were no errors logged for any of the assets. If there were errors, you need to correct the errors before rerunning the year-end program. When you reach a stage where there are no errors, the system will update the last closed fiscal year for each of the depreciation areas for each of the assets. The system will also block any further postings in FI-AA for the closed fiscal year. If you need to reopen the closed fiscal year for any adjustments postings or otherwise, make sure you rerun the year-end program so the system blocks further postings.

83.   WHAT IS AN ASSET HISTORY SHEET?

SAP comes delivered with country-specific asset history sheets that will meet the legal reporting requirements of a country (Figure 5.25). The asset history sheet is one of the important reports that can be used either as the year-end report or the intermediate report whenever you need it. Asset history sheets help you to freely define the report layout, headers, and most of the history sheet items.

FIGURE 5.25  Configuring the Asset History Sheet

You may create various versions of asset history sheets (Figure 5.26).

FIGURE 5.26  Asset History Sheet Versions

For each of the versions, you will be able to define various columns according to your requirements (Figure 5.27).

FIGURE 5.27  Asset History Sheet Version: Field Positions

You can look at the details of a particular column by double-clicking on it (Figure 5.28).

FIGURE 5.28  Details of Line 4/Column 10

84.   CAN YOU CHANGE THE REPORTS IN A REPORT TREE IN FI-AA?

Yes. The standard reports provided by SAP can be copied and modified. Branches can be added or removed from a report tree (Figure 5.29).

FIGURE 5.29  Asset Report Tree

85.   WHAT IS THE SORT VERSION?

The sort version defines the formation of groups and totals in an asset report. All fields of the asset master record can be used as group and/or sort criteria for defining a sort version. It consists of a maximum of 5 sort levels determined via fields.

86.   WHAT IS ASSET EXPLORER?

Asset explorer helps you to display the asset values, depreciation details, and so forth from a single screen (Transaction Code AW01N) (Figure 5.30).

Designed for easy navigation and ease of use, the interface is made up of:

•  Asset values window

The top left area/window is the asset values window, which is in a treelike structure expanding to various depreciation areas like 01, 03, 10, and so on. By selecting any one of these depreciation areas, you will be able to view the value of an asset in the “asset value details window.”

•  Objects related to the asset window

This is also on the left-hand side of the display page, just below the “asset values window.” With a drill-down treelike structure, you will be able to navigate between cost centers and GL accounts relating to the asset.

FIGURE 5.30  Asset Explorer

•  Asset value detail window (with tab pages)

This is the main window on the right, usually occupying most of the page area. Here, you will see the information like company code, asset number selected, fiscal year, and more. This window is made of two completely resizeable components: the top area displaying the asset values and the bottom showing the asset transactions.

Using asset explorer, you can:

•  Move from one asset number to another

•  Display asset values (planned/posted) for any number of depreciation areas

•  Jump to the asset master or cost center master or GL account master

•  Call up various asset reports

•  Look at the various transactions relating to an asset

•  Look up all the values for different fiscal years

•  Distinguish between real and derived depreciation areas with two differentiating symbols

•  Display the depreciation calculation function, and if necessary, the recalculation of depreciation

87.   WHAT IS THE PRODUCTION SETUP IN FI-AA?

The production setup is a collection of logical steps in FI-AA to ensure that all the required configurations and activities are in place for making the asset accounting company code productive. This includes:

•  Consistency check

You can use this analyze errors, if any, in FI-AA configurations in the areas of charts of depreciation, assignment of company code to the chart of depreciation, definition of depreciation areas, asset classes, G/L account assignments, and so on.

•  Reset company code

Because you will be having test data, before the company code becomes productive, resetting the company is necessary to delete all these data. Note that this is possible only when the company code is in “test” status. All the master records and values will be removed only from FI-AA. You need to remove all the FI and CO values separately because resetting the asset account company code does not do this. Resetting will not remove any configuration settings of FI-AA.

•  Reset posted depreciation

This step must be performed when there were errors during a previous depreciation run. This is also possible only when the asset company code is in “test” status.

•  Set/reset reconciliation accounts

Define G/L accounts for FI-AA reconciliation, if not done already. You may also reset already defined reconciliation accounts in the case of incorrect account assignments earlier.

•  Transfer asset balances

Transfer the asset balances to the G/L accounts that have been defined as the asset reconciliation accounts.

•  Activate asset accounting company code

This is the last step in the production setup. All the previous statuses of the company code (test status/transfer status) become invalid now. No transfer of old asset data is allowed once the asset company code becomes productive.

88.   HOW DOES FI-AA INTEGRATE WITH CO IN SAP?

The postings to depreciation can be made through a cost object such as a cost center or an internal order. Also, an asset can be assigned to any of the CO objects like a cost center, an internal order/maintenance order, or an activity type.

The internal orders act as two-way links to the FI-AA:

•  They help to collect and pass on the capital expenditure to assets.

•  They collect the depreciation/interest from FI-AA to Controlling objects. (Note that when there is a situation where the asset master record contains an internal order and a cost center, the depreciation is always posted to the internal order and not to the cost center.)

CHAPTER

6

LEASE ACCOUNTING (FI-LA)

1.     WHAT IS SAP LEASE ACCOUNTING (FI-LA)?

The lease accounting in SAP enables you to carry out and display the accounting-relevant aspects of the leasing deal. SAP FI-LA covers all the postings needed in asset accounting, the execution of contract-related accrual postings in G/L accounting, and one-time postings that are made for a lease. Based on the “lease” contract object, all postings in asset accounting and G/L accounting are made automatically.

SAP FI-LA is also known as FI-LAE (Lease Accounting Engine).

Lease accounting is controlled by the lease accounting engine. This is tightly integrated with the CRM system and accounting. In accounting, this includes the lease accounting engine, the accrual engine, one-time postings, and asset accounting.

2.     WHAT ARE THE KEY COMPONENTS OF LEASE ACCOUNTING?

The SAP lease accounting is made up of the following key components:

•  CRM leasing

The front end for all lease processing begins with the CRM system. CRM utilizes principally quotations and contracts, along with IPC and FIMA, to price leases.

- CRM billing: Contracts generate billing requirement items (BRIs) that are selected via the billing due list.

- CRM TTE: Transaction tax engine is used for calculating sales and lease taxes on transactions. You can also integrate with third-party solutions like the Vertex O Series.

•  FI-CA (of FI-AR)

Contracts accounts payable and receivable are the standard choice of the leasing application for handling AR and cash application.

•  Syndications

This is a very new module that was created by an external company, TXS, and handles the process of securing outside financing companies to fund the lease deals.

•  SAP Banking/CML

The Commercial Loans Management (CML) module integrates with syndications to turn the funding stream into notes payables for remitting lease payments back to the banks.

•  Lease Accounting Engine (FI-LA or FI-LAE)

This is a core module within Financial Accounting and provides all of the posting support for leases.

3.     WHAT IS THE LEASE ACCOUNTING ENGINE (FI-LAE)?

The Lease Accounting Engine (LAE) is responsible for the incoming administration of leases in accounting.

In customizing, you need to define how the system processes the values for the lease transferred from SAP-CRM in accounting in the SAP system. As soon as a new lease is created in the CRM system (NEWL process) or a change process (for example, BLEX process) is carried out for a lease in the CRM system, SAP-CRM automatically transfers the contract data to the LAE in the SAP system. Using the value identifiers defined in customizing, the LAE automatically determines the values from the CRM contract that are to be forwarded to accounting. The LAE then uses these values to classify the lease. In other words, the contract is checked to determine the type of lease involved (capital lease or operating lease).

Leases are classified on the basis of verification rules defined in customizing. Depending on the result of the classification, the lease accounting engine automatically carries out postings in the asset accounting, accrual engine, and one-time postings applications.

4.     WHAT ARE THE SUBCOMPONENTS OF THE LEASE ACCOUNTING ENGINE (FI-LAE)?

The FI-LAE is the core of the lease accounting in SAP.

- Classification: Using FI substitutions, you can take information from the leased asset and determine its classification—for example, operating/capital (direct finance, sales type) with or without bargain purchase option (BPO).

- Fixed assets: You can directly integrate with the fixed assets module to create and capitalize assets. With parallel accounting you can create the book and tax elements of the assets. With subsequent changes to leases, such as terminations or extensions, you can handle updates to the assets, calculation of net book values, and so on.

- Accrual engine: FI-LAE shares the power of the ACE FI accrual engine to post accruals, such as unearned income.

- One-time postings: For those accounting entries that occur only once, there are also ways to let the FI-LAE generate one-time postings, such as inventory relief, miscellaneous costs, and so on.

5.     WHAT IS THE VALUE ID IN LEASE ACCOUNTING?

Value IDs are the actual controlling element in lease accounting, and they are similar to typical programming variables and act as buckets for key information that is used to feed other critical processing in the lease accounting engine (LAE) like asset creation and capitalization, accruals, and onetime postings (Figure 6.1). Values can be established within a value ID either directly from various source transactions or can be derived with different formulas and processing methods.

The value IDs provide information about:

•  The origin of a value: for example, a value can come from a contract item, a material master record, customer master record, or condition types

•  Its business function: for example, a financing amount or residual value

FIGURE 6.1  Value IDs (Image ©SAP)

The value IDs are used:

•  As a component of creating, calculating, or deriving other value ids. The building block for everything in the LAE, even deriving value IDs, takes value IDs. Simply put, they act like variables throughout.

•  For passing values to lease classification routines. Utilize the same FI substitution engine to calculate and determine how leases are classified. Necessary values—for example, the PV of the rents—are passed for calculations.

•  For creating fixed asset master records. The lease accounting engine can automatically create fixed assets in Financial Accounting. All the attributes of the fixed asset are established through value IDs.

•  Fixed asset postings - Values for capitalizations, retirements, are passed through the Lease accounting engine for further processing including determining the fixed assets transaction type to define the posting.

•  For calculating and processing accruals through the accrual engine. The lease accounting engine heavily utilizes FI’s accrual engine (ACE) to calculate and process accruals. In addition to defined accrual methods (enabled through delivered and customer-programmed function modules), you can pass values to the ACE to both define the accrual and its calculations, but it can also be the basis for account determination to derive the GL accounts that will be posted.

•  For one-time posting: Value IDs not only provide the amounts to be posted, but they also can assist in determining which GL accounts are posted.

6.     HOW DO YOU MANAGE THE LEASED ASSETS IN FI-AA?

In the FI-AA system, you can manage the leased assets in two ways:

•  As statistical assets (without values)

•  Assets capitalized according to the capital lease method

Currently, the capitalization using the capital lease method is possible only if the book depreciation area is included. If you want to capitalize a leased asset only in the cost accounting depreciation area, then you have to do it manually. You have to use special transaction types that post only to the depreciation areas you want.

7.     WHAT IS A LEASING TYPE?

The leasing type is an indicator that controls how the leased asset is handled (either as an operating lease or a capital lease) for bookkeeping purposes (Figure 6.2). Specify the leasing type in the asset class or in the asset master record, and classify the leased assets with the leasing type.

The leasing type also contains the essential parameters for posting the acquisition of an asset that is to be capitalized using the capital lease procedure (such as transaction type). The system determines the accounts to be posted and the amount to be capitalized with the help of (a) active depreciation areas in the respective asset class and (b) leasing conditions in the asset master record. This way, you can capitalize leased assets according to the capital lease method using the present value of future payments.

SAP provides the “leasing type 1” as an example.

FIGURE 6.2  Leasing Types

Transaction Code
OAC1

8.     WHAT IS A CLASSIFICATION?

The classification of financing is a step performed during the processing of leases. A classification in the lease accounting engine (LAE) is performed for all processes except for from terminating processes. The system determines which class the financing belongs to and how a financing transaction is to be mapped in accounting:

•  The CRM system uses the CRM interface to transfer the contract data to the system containing the LAE.

- The contracts are classified on the basis of various parameters, such as the accounting principle, useful life of the asset, and contract term.

•  The LAE first determines which validation rule or check sequence is to be used to determine the classification.

- Depending on the customizing settings, it evaluates either individual validation rules or a check sequence of several rules. The system processes the check steps of a check sequence one after the other until it determines a classification. The result is linked with the validation rule or check sequence as per the principle of substitution (access key).

- Depending on the result of the classification, the LAE triggers the asset posting and one-time postings in the general ledger and the accrual postings.

9.     WHAT DOES THE LEASE ACCOUNTING ENGINE DO IN CLASSIFICATION?

The LAE does the following in the classification:

•  New lease (NEWL)

For operating leases, the LAE capitalizes the asset in the lessor’s asset management system. If the result of the classification process is an operating lease, the system automatically creates an asset master record in FI-AA. This asset master record is assigned to an asset class in customizing for FI-AA. In turn, the asset class is assigned to one or more accounts in the general ledger.

For capital leases, asset acquisition postings are not generated, and only the accrual postings are triggered and posted in the G/L.

•  Base lease extension (BLEX) or restructuring (REST)

The original lease continues with a follow-on contract or follow-on contract item. In SAP CRM, the old contract is ended and a new contract or contract item is created. The new contract or contract item is classified. The old asset is decapitalized.

For operating leases, the old asset is decapitalized in asset management and a new asset is created with the appropriate values. In addition, any accrual postings that have not been released yet are cleared and then posted again.

For capital leases, only the accruals are posted.

•  Contract termination at the end of the contract term (TERM) or earlier (ETER)
The classification is not carried out in processes that terminate a contract. The existing assets and accruals are cleared. In addition, depending on the entries in customizing, one-time postings are made in the general ledger for each accounting principle.

10.   WHAT ARE SOME EXAMPLES FOR ONE-TIME POSTINGS IN FI-LAE?

As explained before, one-time postings allow you to allocate and post a variety of charges and adjustments on a one-time basis. This function also offers considerable flexibility when choosing accounts.

Some examples include:

•  CHARGE: Charges levied for termination of contracts (for contracts that are terminated prematurely and those that are terminated normally at the end of the contract term)

•  CORROREV: Correction of the OREV schedule if the contract is terminated prematurely in the middle of the period

•  IDC, Initial Direct Cost: Posted once for incidental acquisition costs relating to operating leases

CHAPTER

7

TRAVEL MANAGEMENT (FI-TV)

S AP Travel Management (FI-TV), is an integrated online solution offering a “360-degree” travel management that supports all the processes involved in handling business trips. With its comprehensive functionality encompassing settlement, taxation, and payment processes, it enables you to:

•  Request trips

•  Plan trips

•  Book trips

•  Create travel expense reports

•  Transfer expense data to other functional areas

1.     WHAT ARE THE IMPLEMENTATION CONSIDERATIONS FOR FI-TV?

You need to analyze the travel processes in the company and ascertain:

•  What is the approval workflow for business trips?

•  Which trip rules have to be considered for which employee groups?

•  Will it be necessary to first define trip rules?

•  Are there any agreements with external travel service providers that need to be taken into consideration?

•  How is the reimbursement process implemented?

•  Which organizational units are involved?

Based on the answers to these questions, you then need to determine which business tasks you can conduct using SAP Travel Management to increase efficiency and to determine which subcomponents (like travel requests, travel planning, and travel expenses) you will need to install/activate them.

2.     HOW DO YOU COMBINE THE SUBCOMPONENTS OF FI-TV?

Of the three subcomponents (travel requests, travel planning, and travel expenses), you can use travel expenses independent of the other two. Touted as the anchor, the travel expense forms the backbone of SAP Travel Management, and you can combine this subcomponent with the others as shown in Table 7.1.

TABLE 7.1  SAP Travel Management: Subcomponents

3.     HOW DO TRAVEL REQUESTS SUPPORT THE BUSINESS PROCESSES?

The subcomponent travel requests streamlines the approval processes in SAP travel management to reduce process costs to a minimum:

•  Sends data such as trip destination, purpose, estimated cost, and preliminary distribution of costs to the approving manager or his/her portal inbox automatically.

•  Pays advances that the traveller requested in this self-service scenario by cash, check, or bank order automatically once the request has been approved.

•  Uses workflow conditions for automating approval—for example, a maximum limit for estimated costs.

•  With SAP Duet, this allows users to requests travel within the outlook calendar.

- Duet workflow routes travel requests, travel plans, and expense reports, including associated travel budget information, to the approving manager’s outlook inbox.

- Approval notifications are returned to the requesters outlook inbox. In addition, Duet makes the travel cost information available to the SAP ERP application for expense reporting.

4.     WHAT IS TRAVEL PLANNING?

The travel planning in FI-TV enables business travelers through a selfservice scenario to book flights, hotels, cars, and country-specific rail options and to look up related information (Figure 7.1).

FIGURE 7.1  Travel Planning in SAP Travel Management

•  Performs online booking by connections to central reservation systems such as Amadeus, Galileo, and Sabre.

•  With SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), allows direct connections to hotel reservation systems, low-cost carrier consolidators, and Deutsche Bahn (German rail).

•  Supports communication with travel agencies fully and makes it more efficient.

•  Cuts agency fees substantially for online bookings and lets the agency concentrate on ticketing and strategic quality assurance.

•  A 100% data synchronization of bookings and, if requested, profiles is supported, too.

5.     HOW DO TRAVEL EXPENSES IN FI-TV HELP YOU IN TRAVEL MANAGEMENT?

The subcomponent travel expenses supports the entire business trip life cycle, from online buying to expense reimbursement and integration into SAP ERP Financials and SAP ERP HCM:

•  Supports receipts and per diems reimbursement, cost assignments, multiple payment modes, and so on via travel and expense management.

•  Allows sophisticated expense policy rules to be set up to meet national tax, fiscal, and legal requirements.

•  Offers a ready-to-run version for 18 countries with preconfigured settings based on legal requirements, thereby accelerating implementation.

•  Provides flexible configuration parameters for easy adoption of further company-specific or international statutory needs.

•  Features credit card clearing interfaces to the leading card providers for personal cards, corporate cards, and lodged cards.

•  Allows setting up control procedures to comply with Sarbanes Oxley and IRS requirements.

It also provides an offline solution that enables travelers to record their working hours and travel expenses offline based on time management (CATS) and travel management applications via Mobile Time & Travel (MTT).

•  Synchronizes data with the SAP systems using the SAP Mobile Infrastructure.

•  Integrates customers’ mobile employees with their main SAP systems—anytime, anywhere—to increase employee efficiency, improve data quality, and streamline business processes.

•  Enables travelers on the road to access the itinerary data transferred from the travel planning solution and create expense reports from them.

6.     HOW DOES FI-TV ENABLES GLOBAL TRAVEL POLICY COMPLIANCE?

With travel planning, you can control online booking by corporate travel policy parameters, helping travel managers to bundle travel volumes to preferred providers and negotiated fares. The system provides a better compliance with travel policy, which in turn facilitates a better negotiation position for central travel service procurement and has an immediate effect on direct purchasing costs.

With travel expenses, it allows the management to implement effective travel policy strategies and easily control travel budgets for the global enterprise or institution. It also helps to handle trips to locations all over the world and in many countries throughout the world. It permits the international standard version to be configured to meet country-specific requirements.

7.     WHAT IS TRAVEL AND EXPENSE ANALYTICS IN SAP TRAVEL MANAGEMENT?

The travel and expense analytics keeps all booking and expense data in one place so users can benefit from easy-to-use reporting tools and full data ownership. It also provides exact reporting for total travel cost control and analytical exception monitoring, besides rendering volumes with travel service providers transparent, making it easier for users to negotiate and procure travel services.

8.     WHAT IS THE OVERALL PROCESS IN SAP TRAVEL MANAGEMENT?

The process flow encompasses three subcomponents that are shown in Table 7.2.

TABLE 7.2  Process Flow in SAP Travel Management

FI-TV Subcomponent

Overall Step #

Travel Process Flow

Travel Requests

1

You use the SAP system to submit a travel request to your manager. The travel request supplies your manager (superior) with details like the date, destination, and purpose of the trip; the transportation and accommodations required; the requested advance; and the estimated costs for the trip.

2

Your manager can approve the request, send it back for corrections, or reject it.

3

If you have requested an advance to be approved, you have the following options for payment when the advance has been approved:
•  Bank transfer to your bank account (via DME)
•  Cash payment by cash office
•  Check
•  Forwarding of the amounts for payment to Financial Accounting

Travel Planning

4

After your travel request has been approved, you then determine the available travel services like flight, hotel, and car rental (if you are in Germany, this also covers train travel) in a travel plan and book them online in the SAP system.
•  The reservation made in an external reservation system is transferred to the SAP system.
•  During booking, the system checks to make sure they comply with the company’s travel policies as defined in “Customizing for Travel Management.”
•  The system applies any existing company-specific rates and rebate agreements.

5

When you have recorded the travel plan, the booking code (PNR) is entered in the processing queue of the travel agency.
•  The travel agency checks the correctness and consistency of the booking.

6

If changes are made to the booking outside the SAP system, they are transferred to the SAP system in a synchronization process.

7

Your travel plan is also transferred to the appropriate manager for approval.
•  As soon as the manager has approved your travel plan, the travel agency issues the ticket and the trip documents and sends them to you.

Travel Expenses

8

After you complete the trip, you are required to submit your travel expense report with all the necessary data and supporting documents.
•  The system applies all statutory and company-specific specifications stored in customizing and checks the consistency of the entries against these specifications.

9

The expenses department checks your travel expense report and the original documents and receipts.
•  Now the travel expense report is sent to the manager for approval, who can then release it for settlement.

10

As soon as the trip is approved, it is settled in the SAP system:
•  On the basis of the trip provisions set for the individual travellers, the system determines the travel expense results, especially the amount for reimbursement.
•  To determine the reimbursement amount, it is possible to choose between per diem/flat rate reimbursement and reimbursement according to individual receipts for meals, accommodations, and travel costs. For all other categories, reimbursement on the basis of individual receipts must be used.

11

The travel expense results are prepared to suit the method of payment chosen and are made available to the corresponding components (Financial Accounting, Payroll Accounting, Controlling Funds Management) with the appropriate additional information.

12

The payment of reimbursement amounts can be:
•  By check
•  Through payroll accounting
•  Through Financial Accounting
•  By bank transfer to your (the employee’s) bank account (via DME)
The travel expense results are always transferred for posting to Financial Accounting. The amounts are transferred from Financial Accounting to Controlling.

13

You receive a travel expense statement with the relevant trip data and the accounting results.

9.     WHAT ARE THE ROLES IN SAP FI-TV?

From Release 4.6, roles (single or composite) are available in SAP Travel Management covering the most important tasks involved in processing the trip data. Assigning roles to users enables them to work in the SAP system purely on the basis of tasks and functions.

The roles in FI-TV support both the decentralized and central organization of the trip process, as well as a mixture of the two, with the focus on decentralization:

•  For the decentralized organization, the travelers are responsible for entering their own travel requests, travel plans, and travel expenses into the system.

•  For a mixed or central organization, these tasks are carried out by a travel assistant on behalf of several travelers.

•  The role of the travel administrator allows the settlement of travel expenses to be organized centrally, where the settlements are entered and checked centrally.

The standard SAP comes delivered with the following roles for SAP Travel Management shown in Figure 7.2.

FIGURE 7.2  Roles in SAP FI-TV

Transaction Code
PFCG

10.   WHAT IS THE TECHNICAL SETUP OF THE FI-TV APPLICATION?

FI-TV can be set up in the following ways from a technical point of view (Figure 7.3):

•  In combination with SAP Payroll Accounting (HR) and SAP Accounting (AC)

•  In combination with HR and separate from AC

•  In combination with AC and separate from HR

•  Separate from HR and AC

FIGURE 7.3  SAP FI-TV: Technical Setup

Depending on the configuration, Support Packages (SP) and HR Support Packages (HR SP) have to be imported into the respective systems.

11.   WHAT ARE THE ADVANTAGES AND DISADVANTAGES OF THE VARIOUS TECHNICAL SETUPS OF FI-TV?

The advantages and disadvantages associated with each combination of technical setups are shown in Table 7.3.

TABLE 7.3  FI-TV Technical Setup Options: Advantages and Disadvantages

12.   HOW DO YOU SELECT THE SYSTEM INFRASTRUCTURE FOR FI-TV?

You may use the guidelines outlined in Table 7.4 to find the appropriate system infrastructure for the technical setup you need.

TABLE 7.4  FI-TV Technical Setup: Infrastructural Options

*Required only if the person-related vendor master records are to be created or maintained automatically.

13.   WHAT IS THE SAP TRAVEL MANAGER?

The SAP Travel Manager is directed at occasional users who want to process their own trips or to employees who have a few travelers assigned to them (Figure 7.4). The Travel Manager covers all the process steps in Travel Management in a single transaction with a uniform interface design. Because the Travel Manager supports the entire Travel Management process, the data are fully integrated in Payroll (HR), Financial Accounting (FI), Cost Accounting (CO), and Funds Management (FM). You can obtain reporting data in the Business Information Warehouse (BW) and the reports in SAP Travel Manager. The reporting data cover both pretrip and posttrip reports.

Depending on your customizing settings, you can use the Travel Manager to:

•  Create travel requests

•  Create and book travel services (with and without a template)

•  Create travel expense statements (with and without a template)

•  Display an overview of all trips

In each section of the Travel Manager (travel request, travel planning, and travel expenses), you can work through the screen from top to bottom as you are used to doing with printed forms. You carry out these actions in the processing area. You do not have to switch between tab pages or screens. All the data are available at all times in the overview.

Transaction Code
TRIP

FIGURE 7.4  SAP Travel Manager: Initial Screen

Note that you will not be able go into the transaction unless you input a valid personnel number when you start the transaction.

14.   WHAT IS A TRAVEL REQUEST?

A travel request is a part of the Travel Manager supporting system-aided handling of the entire process of a business trip (from the initial request, planning, and booking until settlement). It is an information unit containing all the data that a traveller needs to submit to his or her manager for approval, advance payment, or booking, or that the manager needs to know before approving a trip. No paper documents are required because the request is done electronically.

The travel request can include:

•  Trip advance required

•  Trip date and time

•  Trip destination

•  Trip itinerary (additional destination)

•  Trip notes and comments

•  Trip reason

•  Trip’s estimated cost

You can keep track of the approval status of a travel request and look at the trip details any time by accessing the request from the overview area of the Travel Manager. The travel request is linked to the use of travel expenses.

15.   WHAT PERSONAL SETTINGS CAN YOU MAKE IN THE TRAVEL MANAGER?

You can make the following personal settings (Figure 7.5):

•  Trip display

Which trips (all trips/trips in the last 12 months/all trips of the current year) should be displayed in the list of all trips?

•  Initial screen

What should the initial screen look like?

- Show overview area: If the overview area is displayed on the initial level and for the travel expenses entry, a list of all trips is displayed on the left. For the processing levels request a trip and plan a trip, the overview of the trip facts entered is displayed.

- Display screens

- Display all subsequent activity

- Basis HTML (for display problems): Deactivated in the standard system for system performance, this setting should always be chosen if there are display problems.

•  Storage of entries

How many entries are to be stored in the personal input help (F4 help)? You can determine (for text fields, country and region fields, and assignment objects) how many of the values you use are to be noted by the system and displayed when you call up the personal input help.

FIGURE 7.5  Personal Settings in Travel Manager

16.   WHAT IS AN INFOCENTER?

The infocenter is available in the Travel Manager, the Planning Manager and the Travel Expense Manager (Figure 7.6). The data are taken from customizing, or the specifications are taken from Infotype 0001 (organizational assignment).

FIGURE 7.6  Infocenter

Wherever you are, you can call the infocenter by choosing (or Extras -> Infocenter), and the system will bring in:

•  Exchange rates

•  The per diems/flat rates for the individual countries

•  Your contact person in the personnel department

•  Your master cost center

17.   WHAT IS DATA INTEGRATION IN THE TRAVEL MANAGER?

It is easy to explain the data integration when we look at the status flow across the three subcomponents: travel request, travel plan, and travel expenses.

Travel Request

When a new travel request is created in the Travel Manager (Transaction Code TRIP), the system also creates a similar travel request in the Travel Expense Manager (Transaction Code PR05), transferring the basic data, advance, and the cost assignment details to the travel request of the Travel Expense Manager to enable the payment/settlement of advances, if any. While doing this, the system ensures that the status of the travel request in both the Travel Manager and the Travel Expense Manager has the same val ue. If you approve the travel request of the Travel Manager, the travel request in the Travel Expense Manager is also approved. This also works the other way around: When the travel request status is approved in the Travel Expense Manager, the status of the same travel request remains approved in the Travel Manager as well. This applies until a trip gets the status “Trip Completed” or “Trip Approved” from the travel request in the Travel Expense Manager.

Travel Plan

A travel plan needs to be created to book the required travel item (flight, hotel, rental car, train) for the travel request raised in the Travel Manager (Transaction Code TRIP). Though a travel plan can have one of three statuses—open, approved, or rejected—these statuses do not normally affect the status of the trip. The status of a travel plan is independent of that of the travel request.

•  Any changes in the basic data, itinerary, or travel comments are not transferred back to the travel request.

•  If the advance or the cost assignment in the travel plan is changed, then the travel request must be approved because this affects costs. Now there will be two approvals: approval of the travel plan and approval of the travel request. However, it is possible to simplify this if you approve a travel request when you approve the travel plan in the Travel Manager.

Travel Expenses

Once the trip has taken place, data are added to the travel request for the trip in the Travel Expense Manager (the status can be “Trip Completed” or “Trip Approved”). The itinerary data, trip comments, and ticket or booking data from the travel plan are added to the existing trip data. If there is no travel plan, the data (such as itinerary and trip comments) are transferred from any existing travel request.

18.   WHAT TWO STATUSES FOR A TRAVEL REQUEST ARE IN THE TRAVEL MANAGER?

Forming a part of the process control of travel management, the travel request status (in the Travel Manager) is used to determine whether or not different individual business procedures are permitted.

In the Travel Manager, a travel request can have either of the following two statuses:

•  Request entered

•  Request approved

Do not confuse the travel request status from the Travel Manager with the approval status value “Request Entered” from Travel Expenses.

19.   WHAT IS A TRAVEL PLAN?

The travel plan object constitutes the basis for all actions in travel planning: to start price and availability queries and to book travel services. The general trip data (such as the personnel number, destination, reason for the trip, and trip activity) are stored in the travel plan. Each travel plan is stored in the system with a trip number that identifies it uniquely so booked travel services have a unique assignment. The assignment of the travel services is also used for the object-specific transfer of the data to Travel Expenses. The travel plan thus has the same number as the trip to be settled.

You may create a travel plan from the Travel Manager or the Planning Manager.

20.   WHAT IS THE PLANNING MANAGER?

The Planning Manager is an entry transaction for creating and editing travel plans (Figure 7.7). With it you can:

•  Check availability of flights, hotel rooms, car rentals, and trains

•  Find out the best prices for flights for the whole trip

•  Book flights, hotel rooms, and rental cars online

•  Cancel and rebook reserved services

•  Update data automatically in SAP Travel Manager whenever changes are made by the travel provider

FIGURE 7.7  Planning Manager

Transaction Code
TP01

When a travel plan is created, the system automatically creates the corresponding travel expense report. As soon as you book a travel service online in the reservation system and save the travel plan, a corresponding receipt for the travel service is created in Travel Expenses.

21.   HOW ARE TRAVEL EXPENSES INTEGRATED WITH THE OTHER APPLICATION AREAS IN SAP?

The travel expense transfer amounts can be reimbursed to the employee via Financial Accounting (FI), Payroll (HR), or via data medium exchange. In the Travel Expenses process, Travel Management accesses master data in SAP Personnel Administration (HR). To support the approval process, travel expenses are connected to the SAP Business Workflow component. Using ESS (Employee Self Service), the travellers can both request and plan their trips and enter the relevant data in an online travel expense report after the trip has been completed.

Using travel expenses, you can:

•  Allocate travel expenses to SAP Controlling (CO)

•  Allocate travel expenses to SAP Funds Management (FM)

•  Calculate taxation in SAP Payroll (HR)

•  Post-travel expenses to SAP Financial Accounting (FI)

22.   WHAT ARE THE ELEMENTS OF A TRIP?

An employee trip is a business trip taken by an employee, involving a change of location, including the outbound trip and the return trip, for reasons of a temporary external activity. A business trip can be initiated by Personnel Development (HR) or Shift Planning (HR). You can forward the travel expense results produced by Travel Expenses for proper posting to Financial Accounting (FI) and to Payroll (HR) for tax calculation. You can reimburse the trip transfer amount to the employee via Financial Accounting (FI), Payroll (HR), or data medium exchange. You can forward the trip costs assignment specifications for internal cost accounting to Controlling (CO) or for cash budget management to Funds Management (FM).

A trip consists of:

•  Trip data, which contain the facts about a trip (such as miles travelled and accommodation expenses) that are relevant for the settlement of travel expenses or that document the trip

•  Travel expense assignments

•  Travel expense results and trip transfer amount created by SAP Travel Expenses on the basis of the trip data

•  Trip status indicating the state of the trip to control the permissibility of certain business transactions

23.   DO YOU NEED AN EMPLOYEE’S HR MASTER RECORD FOR ENTERING TRIPS?

As the travel planning accesses a minimal HR master data record, using SAP Human Resources (HR) is not a prerequisite for using SAP Travel Management. Remember that the person-related master data are stored in infotypes that enable structured processing of this data. The special infotypes in SAP Travel Planning are based on the same logic as the infotypes in SAP Human Resources. They are, however, independent of HR infotypes and have no influence on existing infotypes in Human Resources.

Travellers abide automatically by the “enterprise-specific trip rules” stored in the system. However, for planning and booking travel services, they can also enter personal preferences that are taken into consideration by the travel service provider where possible. These personal preferences are only taken into consideration if they comply with company travel policy.

24.   WHAT IS A PERSONNEL MINI-MASTER?

To store person-related master data, you can create a personnel mini-master record directly in SAP Travel Planning. You do not need to use the human resources component. You can simply create all the infotypes necessary for SAP Travel Planning via the personnel action travel planning setting. When you enter infotypes for the first time, you are guided through these actions step by step. Any HR master data you have already created can be changed or supplemented at any time.

25.   WHAT ARE THE MANDATORY AND OPTIONAL INFOTYPES?

The following infotypes are mandatory (Table 7.5) for any employee for whom a trip is to be booked using travel planning:

•  Organizational assignment (0001)

•  Personal data (0002)

•  Travel privileges (0017)

•  Addresses (0006)

TABLE 7.5  Infotypes: Mandatory and Optional

Infotypes

Mandatory

Optional

0001

0009

0002

0027

0006

0470–0473

0017

0475

•  It is not advisable to make a booking without infotype 0006 because the telephone number field in this infotype is used to create the booking record. This infotype is also used with the infotype bank details (0009) in travel expenses if the settled trips are to be paid as a credit via Financial Accounting (FI).

•  The infotype cost distribution (0027) is only used in travel expenses for distributing the total costs to different cost centers.

•  The travel planning-specific infotypes 0470 to 0475 represent the personal preferences of the individual employees. (The infotype rail preference 0474 has no meaning.) Even though these infotypes are optional, they enable employees’ personal preferences to be taken into consideration for each business trip booking.

- The infotype travel profile 0470 allows a direct assignment of a travel profile to an employee.

- The infotype flight preference 0471 contains information specific to a flight, such as meals, seat position, and preferred airport.

- The infotype hotel preference 0472 contains information about the preferred room and hotel category.

- The infotype car rental preference 0473 contains information such as the preferred make of car and air conditioning.

- The infotype customer program 0475 can be created many times because it relates to all the provider categories. Here you can store information about frequent fliers or special car rental or hotel customer programs.

•  The additional infotype communication 0105, subtype 0001, is used to assign system users to the active SAP system directly (SAP Business Workflow, SAP Office, and ESS). Subtype 011 is used for credit cards.

26.   WHAT IS THE APPROVAL PROCESS IN TRAVEL PLANNING?

The approval (requires a special authorization for the person who is to approve the travel plan) of a travel plan can be done in two ways:

•  Manual approval (through the entry transactions of travel planning).

The traveller can see in the respective entry transactions by the approval status in the overview of his trips which travel plans have been approved or rejected. The superior calls the appropriate travel plan in the entry transaction and carries out the “Approve” function. The process flow is shown in Table 7.6.

TABLE 7.6  Approvals in Travel Planning

Planning Manager

Travel plans can be
•  Approved
•  Rejected

1.  Call the planning manager.

2.  In the overview table, select a travel plan.

3.  Choose travel plan -‾ approve.

4.  On the pop-up that appears, decide whether you want to approve or reject the travel plan.

Travel Manager

Travel plans can be
•  Approved

1.  Call the travel manager.

2.  Position the cursor in the overview area on the left-hand side, or can be called up via “List of all trips” on a travel plan.

3.  Choose change.

4.  Choose travel plan -> approve.

•  By SAP Business Workflow (SAP Travel Manager supports the approval process with a reference approval procedure that can be adapted to suit any company’s requirements at any time)

- The travel planning data are entered in the system by the traveller or travel agent.

- The superior approves the travel plan: determined by the system automatically based on the maintained structural organization.

- The superior can approve the travel plan and return it to the traveller for correction or can reject it.

- When the superior has approved the travel plan, the traveller is informed of this via e-mail. The booking record is put in a processing queue of the connected travel agency.

- If a correction is necessary, the superior appends a message to this effect to the workflow. The employee receives a work item with this attachment. When the work item is executed, the transaction to change the travel plan is started.

- If the travel plan is rejected, the superior enters a message that the traveller receives as an e-mail. The booking is then cancelled.

The approval status of a travel plan is displayed in the respective overview screens of the Planning Manager and the Travel Manager. The various statuses for the approval process are shown in Table 7.7.

TABLE 7.7  Approval Process Statuses

Status

Meaning

Open

The superior responsible has not yet processed the trip.

Approved

The superior has approved the trip.

Rejected

The superior has rejected the trip.

27.   WHAT IS A TRIP TRANSFER DOCUMENT?

A trip transfer document contains the summarized and formatted settlement results for one or more trips for transfer to accounting. From the data in a trip transfer document, accounting creates posting documents for G/L accounting, subledger accounting, Controlling, and so on.

The system assigns a unique key to each trip transfer document. This key is transferred as a reference to the header data of the corresponding posting documents of accounting. With this key, you can find the corresponding trip transfer document and the trips referred to in the posting document from the accounting posting document at any time. Every trip transfer document belongs to exactly one posting run.

The physical structure of a trip transfer document depends on the conditions you specify for the summarization of posting lines and documents when you create a posting run:

•  You can decide separately for the expense posting and the off-setting entry whether the system should summarize the data in the posting line per trip, per employee, or per account assignment object.

•  You can decide whether the system creates a trip transfer document per trip, per employee, per account assignment object, or per company code.

Every trip transfer document consists of at least two posting lines. In one posting line, all of the settlement results are collected that have the same G/L account, the same input tax code, and the same account assignment objects.

28.   WHAT IS A POSTING RUN?

A posting run is a container for trip transfer documents. It has a unique number and a status (like “posting with zeros, ” “no documents selected, ” “all documents checked, “ etc.).

In a posting run, the results of travel expense settlements are collected as trip transfer documents for transfer to accounting. The posting run status keeps you informed of the transfer process and influences whether or not a trip can be changed. You cannot change the trips contained in a posting run until you have posted the complete posting run.

29.   CAN YOU CANCEL A TRIP THAT HAS BEEN POSTED IN ACCOUNTING?

Yes, it is possible to cancel a trip that has been posted in accounting. To effect cancellation, you have to change the trip status to settlement status “Cancelled.” This can be done using the entry scenarios or the approval program. In the approval program, the trips and requests are given the settlement status “Po.can.” (posting cancelled) and the status “Corr.” (corrected).

The next settlement run also includes trips that have the settlement status “Cancelled.” The settlement program replaces the old payroll period of these trips with the payroll period with which the settlement program was started.

The next time settlement results are transferred to accounting after the settlement run, the system includes the trips that have the settlement status “Cancelled” in the posting run. Cancellation of postings in accounting takes place when the posting run is posted. In the approval program, finally, the trips and requests are given the settlement status “Can.po.” (cancellation posted).

30.   HOW DO YOU POST THE PRIVATE EXPENSES PAID BY THE COMPANY?

You may use the Receipt Wizard to post the private expenses that are not applicable for reimbursement. SAP has provided two new expense types for receipts that have already been paid by the company:

•  PRIV private shares (expenses) that need to be paid back

•  PRBZ private shares (expenses) that were paid by the company

By using these two expense types, you can ensure that:

•  Private expenses that are not applicable for reimbursement are shown as debits for travelers and must therefore be paid back to the company.

•  Private expenses for receipts that have already been paid are shown as credits in the expense account assigned to the paid receipt (this means that the expense is reduced by this amount) or that the expense account is not debited with the private expense in the first place.

•  The travel expense form shows the correct figures for the reimbursement amount, the amount paid by the company, and the total expenses for the trip.

•  Data entry and usage are as easy as possible for the user.

31.   WHAT IS A TRAVEL INFORMATION SYSTEM?

The Travel Information System in SAP Travel Expenses supports the user for monitoring and analyzing the travel expenses incurred. Within the SAP system you can also use travel expense reports from the Manager’s Desktop in HR personnel management. You can also use the data from Travel Expenses if you use the reports from the Business Information Warehouse (BW). However, to use the data from Travel Expenses for reports, you need to have made the appropriate settings in customizing for travel management under Travel Expenses ® Define Structure of Trip Statistics.

Several reports and queries are available for you to use in the Travel Expenses Information System (Table 7.8).

TABLE 7.8  Reports and Queries in the Travel Expenses Information System

Trip statistics

•  General trip data/trip totals
•  Trip receipts
•  Trip receipts without general data
•  Cost assignment for trip
•  Cost assignment for trip without general data
•  General trip data/totals/receipts/cost assignments
•  Who is where? Search for trip destinations
•  Search for receipts using maximum rate

Diverse trip reports

•  Reporting trip costs by periods
•  Statement for income-related expenses
•  Input tax recovery
•  Determination of employees with exceeded trip days

CHAPTER

8

SAP FI TABLES

TABLE 8.1  SAP FI Tables

#

Are you looking for:

Table

1

Account Assignment Templates for GL Account items

KOMU

2

Account Master (Chart of Accounts)

SKA1

3

Accounting Correspondence Requests

BKORM

4

Accounting Data—A/R and A/P Information System

RFRR

5

Accounting Document Header

BKPF

6

Accounting Document Header (docs from External Systems)

EBKP

7

Accounting Document Header

BKPF

8

Accounting Document Segment

BSEG

9

Accounting Secondary Index for Customers

BSID

10

Accounting Secondary Index for Customers—Cleared Items

BSAD

11

Accounting Secondary Index for GL Accounts

BSIS

12

Accounting Secondary Index for GL Accounts—Cleared Items)

BSAS

13

Accounting Secondary Index for Vendors

BSIK

14

Accounting Secondary Index for Vendors—Cleared Items

BSAK

15

Accounts Blocked by Dunning Selection

MAHN

16

Asset Accounting: Basic Functions

FI-A

17

Asset Class: Depreciation Area

ANKB

18

Asset Classes-Description

ANKT

19

Asset Classes: Field Cont Dependent on Chart

ANKP

20

Asset Classes: General Data

ANKA

21

Asset Classes: Insurance Types

ANKV

22

Asset Down Payment Settlement

ANEV

23

Asset Line Items

ANEP

24

Asset Master Record Segment

ANLA

25

Asset Master Record Segment

ANLX

26

Asset Master Record User Fields

ANLU

27

Asset Periodic Values

ANLP

28

Asset Texts

ANLT

29

Asset Type Text

ANAT

30

Asset Types

ANAR

31

Asset Value Fields

ANLC

32

Bank Master Record

BNKA

33

Business Partner Master (General Data)

BP000

34

Cash Management Line Items in Payment Requests

FDZA

35

Create GL Account with Reference

TSAK

36

Credit Management: FI Status Data

KNKK

37

Customer/Vendor Linking

KLPA

38

Customer Master—General Data

KNA1

39

Customer Master—Partner Functions

KNVP

40

Customer Master—Sales Data

KNVV

41

Customer Master—Sales Request Form

KNVD

42

Customer Master (Company Code)

KNB1

43

Customer Master Bank Details

KNBK

44

Customer Master Credit Management: Central Data

KNKA

45

Customer Master Credit Management: Control Area Data

KNKK

46

Customer Master Dunning Data

KNB5

47

Customer Master Special GL Transactions Figures

KNC3

48

Customer Master Transaction Figures

KNC1

49

Customer Payment History

KNB4

50

Depreciation Terms

ANLB

51

Document Header Asset Posting

ANEK

52

Document Header for Document Parking

VBKP

53

Document Header Supplement for Recurring Entry

BKDF

54

Document Type Texts

T003T

55

Dunning Data (Account Entries)

MHNK

56

Electronic Bank Statement Line Items

FEBEP

57

Financial Accounting “Basis”

FBAS

58

GL Account Master (Chart of Accounts—Description)

SKAT

59

GL Account Master (Chart of Accounts—Key Word list)

SKAS

60

GL Account Master (Chart of Accounts)

SKA1

61

GL Account Master (Company Code)

SKB1

62

General Ledger Accounting: Basic

FI-G

63

General Ledger Accounting: Basic

FI-G

64

Global Settings for Payment Program for Payment Requests

F111

65

Index for Vendor Validation of Double Documents

BSIP

66

Insurable Values (Year Dependent)

ANLW

67

Inter Company Posting Procedure

BVOR

68

Main Asset Number

ANLH

69

Management Records for the Dunning Program

MAHNV

70

Name of Transaction Type

AT10T

71

One-Time Account Data Document Segment

BSEC

72

Payment Medium File

PAYR

73

Payment Requests

PAYR

74

Pre-numbered Check

PCEC

75

Pricing Communication Header

KOMK

76

Run Date of a Program

FRUN

77

Secondary Index, Documents for Material

BSIM

78

Settings for GL Posting Reports

FIGL

79

Substitutions

GB92

80

Tax Code Names

T007S

81

TemSe—Administration Data

REGUT

82

Time Dependent Asset Allocations

ANLZ

83

Transaction Activity Category—Description

AT02T

84

Transaction Code for Menu TIMN

AT02A

85

Transaction Type

AT10

86

Validation/Substitution User

GB03

87

Validation

GB93

88

Vendor Master (Company Code Section)

LFB1

89

Vendor Master (General Section)

LFA1

90

Vendor Master Bank Details

LFBK

91

Vendor Master—Dunning Data

LFB5

92

Vendor Master Dunning Data

LFB5

93

Vendor Master Record: Purchasing Data

LFM2

94

Vendor Master Record: Purchasing Organization Data

LFM1

95

Vendor Master Transaction Figures

LFC1

CHAPTER

9

SAP FI TRANSACTION CODES

Following are some of the important Transaction Codes (T-Codes) in Financial Accounting. The notable feature of these lists is the way these Transaction Codes have been arranged here. The codes are not listed in alphabetical list because such a list may not serve your purpose when you do not know the Transaction Code but only have a description in your mind. The Transaction Codes are arranged based on their function or task so they will be easier to find. Look for key words in the second column, “Description,” (what are you looking for?), and then look at the corresponding Transaction Code under the “T-Code” column.

All the Transaction Codes are stored in the system in Tables TSTC and TSTCT.

FIGURE 9.1  Fields in Table TSTCT

It is not practical to list all the Transaction Codes, and it is not really necessary either. You will become accustomed to looking for Transaction Codes by going through Transaction Code SE93. If you do not see the Transaction Code you need, use Transaction Code SE93 to find it.

Transaction Code
SE93

There are two ways to use Transaction Code SE93 to find a code:

1.  When you know the application area—for example, you want to list all the Transaction Codes starting with “IQ.” In this case, enter “IQ*” in the initial screen (Figure 9.2).

FIGURE 9.2  Initial Screen in SE93

a.  Search using F4 (Figure 9.3). The system presents all the T-Codes starting with “IQ.”

FIGURE 9.3  Search using F4 in SE93

2.  If you have no idea what Transaction Code you need, go to the “Selection” screen after you enter Transaction Code SE93. Place the cursor in the “Application Component” field on the pop-up (Figure 9.4).

FIGURE 9.4  Search in an Application Component

a.  Press F4. The system pops up the “Select Application Component” screen, as shown in Figure 9.5.

FIGURE 9.5  Select an Application Component

b.  Drill down to the desired node. For example, if you need to list all the Transaction Codes under “Equipment,” then you will be drilling down as shown in Figure 9.6.

FIGURE 9.6  Drill Down to the Desired Node of an Application Component

c.  Select the node PM, and then drill down to PM-EQM, and then to PM-EQM-EQ. Now, double-click on the line. You are now taken back to the pop-up shown under step 2, with the “Application Component” filled in (Figure 9.7).

FIGURE 9.7  Application Component Selected for T-Code List 318

d.  Press F8, and the system brings up all the Transaction Codes relating to this application subcomponent (Figure 9.8).

FIGURE 9.8  T-Codes Listed for the Selected Application Component

e.  Continue to other application areas/sub-components to find all the Transaction Codes you need.

Just as a shortcut, we compiled the most important Transaction Codes (432 in all) you will most likely need in FI under two areas:

1.  Customizing Transaction Codes (112)

2.  Other Transaction Codes (320)

CUSTOMIZING SAP FI TRANSACTION CODES

TABLE 9.1  Customizing SAP FI Transaction Codes

#

Description

T-Code

1

Activate Functional Area Substitution

OBBZ

2

Activate Validations

OB28

3

Allocate a Company Code to Sample Account Rule Type

OB67

4

Assign Chart of Depreciation to Company Code

OAOB

5

Assign Country to Tax Calculation Procedure

OBBG

6

Assign Employee Groups to Credit Representative Groups

OB51

7

Assign GL Accounts to Reason Codes

OBXL

8

Assign Posting Keys to Document Types

OBU1

9

Assign Reference Interest Rates to Interest Indicators

OB81

10

Assign Tax Codes for Nontaxable Transactions

OBCL

11

Assign Treasury Transaction Types to House Banks

OT55

12

Assign Users to Tolerance Groups

OB57

13

Automatic Account Assignment for Interest Calculation

OBV1

14

Automatic Account Assignment, Cross-Company Code

OBYA

15

Automatic Account Assignment, MM

OBYC

16

Automatic Postings Documentation

OBL1

17

Bank Chain Determination

FIBB

18

Cash Management Implementation Tool

FDFD

19

Configuration: Maintain Display Format

FAKP

20

Configuration: Show Display Format

FAKA

21

Configure Days in Arrears Calculation

OB39

22

Configure the Central TR-CM System

FF$X

23

Copy Chart of Accounts

OBY7

24

Copy Chart of Depreciation

EC08

25

Copy Company Code

EC01

26

Copy GL Accounts from Chart of Accounts to the Company Code

OBY2

27

Copy Vendor Master Records Creation Program

FK15

28

Copy Vendor Master Records Upload Program

FK16

29

Define Treasury Groupings

OT17

30

Define Additional Local Currencies

OB22

31

Define Asset Classes

OAOA

32

Define Base Method

OAYO

33

Define Cash Discount Accounts

OBXI

34

Define Cash Management Account Names

OT16

35

Define Check Lots

FCHI

36

Define Company Code (Create/Check/Delete)

OX02

37

Define Company Code Global Parameters

OBY6

38

Define Countries

OY01

39

Define Credit Control Areas

OB45

40

Define Credit Representative Groups

OB02

41

Define Credit Risk Categories

OB01

42

Define Currency Translation Ratios

GCRF

43

Define Customer Account Groups

OBD2

44

Define Customer Tolerance Groups

OBA3

45

Define Data Transfer Rules for Sample Accounts

FSK2

46

Define Depreciation Key

AFAMA

47

Define Document Types

OBA7

48

Define Financial Statement Versions

OB58

49

Define GL Account Groups

OBD4

50

Define GL Number Ranges

FBN1

51

Define House Banks

FI12

52

Define Line Item Layouts

O7Z3

53

Define Lockbox Accounts

OB10

54

Define Number Range for Payment Request

F8BM

55

Define Number Ranges for Depreciation Postings

FBN1

56

Define Number Ranges for Master Classes

AS08

57

Define Number Ranges of Vendor Account Groups

OBAS

58

Define Number Ranges for Vendor Account Groups

XKN1

59

Define Posting Keys

OB41

60

Define Posting Period Variant

OBBO

61

Define Posting Rules for Electronic Bank Statement

OT57

62

Define Reason Codes

OBBE

63

Define Reference Interest Rates

OBAC

64

Define Screen Layouts for Asset Depreciation Areas

AO21

65

Define Sort Variants

O757

66

Define Source Symbols for Treasury

OYOS

67

Define Special Fields

OBVU

68

Define Specify Intervals And Posting Rules

OAYR

69

Define Tax Accounts

OB40

70

Define Tax Codes for Nontaxable Transactions

OBCL

71

Define Tax codes for Sales/Purchases

FTXP

72

Define Tax Jurisdiction Codes

OBCP

73

Define Tolerance Groups

OBA4

74

Define Vendor Account Groups

OBD3

75

Define Void Reason Codes for Checks

FCHV

76

Define Sample Account Rules

OB15

77

Depreciation Keys

OAYO

78

Determine Depreciation Areas in Asset Classes

OAYZ

79

Define Planning Groups for Treasury

OT13

80

Display Accounting Configuration

FBKA

81

Document Change Rules

OB32

82

Fast Entry Screens

O7E6

83

FI Configuration Menu (Instead of IMG)

ORFB

84

Field Status Variants

OBC4

85

Integration with GL

AO90

86

Interest Indicator (Arrears Interest) for Int. Calculation Program

OB82

87

Internal Number Range for Payment Orders

FBN2

88

Loans Customizing

FDCU

89

Maintain Accounting Configuration

FBKF

90

Maintain Accounting Configuration

FBKP

91

Maintain Bank Chains for Account Carryover

FIBTU

92

Maintain Bank Chains for House Banks

FIBHU

93

Maintain Bank Chains for Partner

FBIPU

94

Maintain Bank Chains for Partner

FIBPU

95

Maintain Business Area

OX03

96

Maintain Client Dependent User Exits

GCX2

97

Maintain Currency Translation Type

FDIC

98

Maintain Currency Translation Type

FGIC

99

Maintain Currency Translation Type

FKIC

100

Maintain Dunning Procedure

FBMP

101

Maintain Fiscal Year Variant

OB29

102

Maintain Functional Areas

OKBD

103

Maintain Key Figures

FDIK

104

Maintain Payment Program Configuration

FBZP

105

Maintain Substitutions

GGB1

106

Maintain Text Determination Configuration

FBTP

107

Maintain Validations

GGB0

108

Real Estate Implementation Guide

FEUI

109

Retained Earnings Variant

OB53

110

Scenarios for Bank Chain Determination

FIBC

111

Structure for Tax Jurisdiction Codes

OBCO

112

Transport Chart of Accounts

OBY9

OTHER SAP FI TRANSACTION CODES

TABLE 9.2  Other SAP FI Transaction Codes

#

Details

T-Code

1

Account Balances, A/P

F.42

2

Account Balances, A/R

F.23

3

Account List, A/P

F.40

4

Account List, A/R

F.20

5

Accounting Editing Options

FB00

6

Acquisition from Purchase with Vendor

F-90

7

Advance Tax Return

F.12

8

Archive Bank Master Data

F041

9

Archive Customer

F043

10

Archive Transaction Figures

F046

11

Archiving Bank Data Storage

F66A

12

Archiving Banks

F61A

13

Archiving Check Data

FCHA

14

Archiving GL Accounts

F53A

15

Archiving Payment Request

F8BO

16

Archiving Vendors

F044

17

Asset Acquisition to Clearing Account

F-91

18

Asset Depreciation Run

AFAB

19

Asset Explorer

AW01

20

Asset Master Creation

AS01

21

Asset Retirement from Sale With Customer

F-92

22

Asset Scrapping

ABAVN

23

Asset Transfer

ABUMN

24

Asset, Create Subasset

AS11

25

Automatic Clearing: ABAP/4 Report

F.13

26

Balance Interest Calculation, A/P

F.44

27

Balance Interest Calculation, A/R

F.26

28

Balance Sheet: ABAP/4 Report

F.01

29

Balance Sheet Adjustment: ABAP/4 Reporting

F101

30

Balance Sheet/P&L with Inflation

FJA3

31

Bill of Exchange List

F.25

32

Bill of Exchange Payment

F-36

33

Bill of Exchange Payment Request Dunning

F.70

34

Bill of Exchange Payment: Header Data

F-40

35

Bill of Exchange Presentation: International

FBWE

36

Block Customer (Accounting)

FD05

37

Block Vendor (Accounting)

FK05

38

Cash Concentration

FF73

39

Cash Journal

FBCJ

40

Cash Management and Forecast—Initial Screen

FF72

41

Cash Management Position/Liquidity Forecast

FF70

42

Cash Management Summary Records

FF-3

43

Cash Position

FF71

44

Change Bank

FI02

45

Change Check/Payment Allocation

FCHT

46

Change Check Information/Cash Check

FCH6

47

Change Credit Limits

FD24

48

Change Current Number Range Number

FI07

49

Change Customer (Accounting Data)

FD02

50

Change Customer Credit Management

FD32

51

Change Customer Line Items

FBL6

52

Change Document

FB02

53

Change GL Account Line Items

FBL4

54

Change Intercompany Document

FBU2

55

Change Last Adjustment Dates

FJA2

56

Change Line Items—Customer/Vendor/Asset/GL

FB09

57

Change Parked Document (Header)

FBV4

58

Change Parked Document

FBV2

59

Change Payment Advice

FBE2

60

Change Pricing Report

F/LB

61

Change Recurring Entry

FBD2

62

Change Report Settings for Transaction Figures

FDI2

63

Change Report: Settings

FGI2

64

Change Report: Settings

FKI2

65

Change Sample Document

FBM2

66

Change Vendor (Accounting Data)

FK02

67

Change Vendor Line Items

FBL2

68

Check Extract—Creation

FCHX

69

Check if Documents Can Be Archived

FB99

70

Check Register

FCHN

71

Check Retrieval

FCHB

72

Check Tracing Initial Menu

FCHK

73

Clear Customer Down Payment

F-39

74

Clear Customer: Header Data

F-32

75

Clear GL Account: Header Data

F-03

76

Clear Vendor Down Payment

F-54

77

Clear Vendor: Header Data

F-44

78

Confirm Customer Individually (Accounting)

FD08

79

Confirm Customer List (Accounting)

FD09

80

Confirm Vendor Individually (Accounting)

FK08

81

Confirm Vendor List (Accounting)

FK09

82

Correspondence: Delete Requests

F.63

83

Correspondence: Maintain Requests

F.64

84

Correspondence: Print Interest Documents

F.62

85

Correspondence: Print Letters (Customer)

F.65

86

Correspondence: Print Letters (Vendor)

F.66

87

Correspondence: Print Requests

F.61

88

Create Bank

FI01

89

Create Check Information

FCH5

90

Create Customer (Accounting)

FD01

91

Create Payment Advice

FBE1

92

Create Payment Runs Automatically

F8BU

93

Create Planning Memo Record

FF63

94

Create Reference for Check

FCHU

95

Create Vendor (Accounting Area Data)

FK01

96

Credit Management - Mass Change

F.34

97

Credit Management - Mass Change

FD37

98

Credit Management - Master Data List

FDK43

99

Credit Management - Missing Data

F.32

100

Credit Management - Overview

F.31

101

Credit Master Sheet

F.35

102

Customer Account Analysis

FD11

103

Customer Account Balance

FD10

104

Customer Balance Confirmation:ABAP/4 Report

F.17

105

Customer Balance Display

FD10N

106

Customer Balance: Display with Worklist

FD10NA

107

Customer Changes (Accounting)

FD04

108

Customer Down Payment Request

F-37

109

Customer Interest on Arrears: Post (w/ Open Items)

F.2B

110

Customer Interest on Arrears: Post (w/o Open Items)

F.2A

111

Customer Interest on Arrears: Post (w/o postings)

F.2C

112

Customer Line Items

FBL5N

113

Customer Noted Item

F-49

114

Customer/Vendor Statistics

F.1A

115

Customers Drilldown Reports: Background Processing

FDIB

116

Customers: FI-SD Master Data Comparison

F.2D

117

Customers: Report Selection

F.99

118

Customers: Reset Credit Limit

F.28

119

Data Extract for FI Transfer

FC11

120

Delete A/R Summary

FCV2

121

Delete Cashing/Extract Data

FCHG

122

Delete Manual Checks

FCHF

123

Delete Payment Advice

FBE6

124

Delete Payment Run Check Information

FCHD

125

Delete Recurring Document

F.56

126

Delete Voided Checks

FCHE

127

Display Account Determination Configuration

FBBA

128

Display Bank Chains for House Banks

FIBHS

129

Display Bank Chains for Partners

FIBPS

130

Display Bank Changes

FI04

131

Display Bank

FI03

132

Display Check Information

FCH1

133

Display Customer (Accounting Data)

FD03

134

Display Customer Credit Management

FD33

135

Display Customer Line Items

FBL5

136

Display Document

FB03

137

Display Document/Payment Usage

FB03Z

138

Display Dunning Procedure

FBMA

139

Display Electronic Bank Statement

FF.6

140

Display FI Amount Groups

F8+2

141

Display FI Main Role Definition

F8+0

142

Display GL Account Line Items

FBL3

143

Display House Banks/Bank Accounts

FI13

144

Display Intercompany Document

FBU3

145

Display of Payment Requests

F8BS

146

Display Parked Document

FBV3

147

Display Payment Advice

FBE3

148

Display Payment Document Checks

FCH2

149

Display Payment Program Configuration

FBZA

150

Display Payment Requests

F8BT

151

Display Payment Run

FBZ8

152

Display Pricing Report

F/LC

153

Display Recurring Entry Changes

FBD4

154

Display Recurring Entry

FBD3

155

Display Sample Document Changes

FBM4

156

Display Sample Document

FBM3

157

Display Text Determination Configuration

FBTA

158

Display Vendor (Accounting Data)

FK03

159

Display Vendor Line Items

FBL1

160

Display/Edit Payment Proposal

FBZ0

161

Document Archiving

F045

162

Document Changes of Parked Documents

FBV5

163

Document Changes

FB04

164

Down Payment Request

F-47

165

Download Documents

FBF4

166

Dunning Run, A/R

F150

167

Enter Accrual/Deferral Document

FBS1

168

Enter Bill of Exchange Payment Request

FBW1

169

Enter Customer Credit Memo

F-27

170

Enter Customer Invoice

F-22

171

Enter GL Account Posting

F-02

172

Enter Incoming Credit Memos

FB65

173

Enter Incoming Invoices

FB60

174

Enter Noted Item

FB31

175

Enter Outgoing Credit Memos

FB75

176

Enter Outgoing Invoices

FB70

177

Enter Payment Request

FBP1

178

Enter Recurring Entry

FBD1

179

Enter Sample Document

F-01

180

Enter Statistical Posting: Header Data

F-38

181

Enter Transfer Posting: Header Data

F-21

182

Enter Vendor Credit Memo

F-41

183

Enter Vendor Invoice

F-43

184

Evaluate Info System, A/P

F.46

185

Evaluate Info System, A/R

F.30

186

Exchange Rates Table Maintenance

F-62

187

F111 Customizing

F8BZ

188

Failed Customer Payments

FBZG

189

FI Account Assignment Model Management

FKMT

190

FI Display Structure

FINA

191

FI Easy Access - Banks

FBME

192

FI Easy Access - Customers

FDMN

193

FI Easy Access - Vendors

FKMN

194

FI Information System

F000

195

FI Initial Consolidation Menu

FCMN

196

FI Valuation Run

F107

197

Financial Statements Comparison

FC10

198

Financial Transactions

FBF2

199

Foreign Currency Valuation: Open Items

F.05

200

Generate MultiCash Format

FEBC

201

Generate Payment Request from Advices

FF.D

202

GL Account Assignment Manual

F.53

203

GL Account Balance Interest Calculation

F.52

204

GL Account Balances

F.08

205

GL Account Cashed Checks

FF.3

206

GL Account Interest Scale

FF_1

207

GL Account Line Items

FBL3N

208

GL Account List

F.09

209

GL Account Posting: Single Screen Transaction

FB50

210

GL Accounts Archiving

F042

211

GL Advance Report on Tax on Sales/Purchase with Jurisdiction

F.5I

212

GL Balance Carried Forward

F.07

213

GL Balance Sheet Adjustment Log

F.5F

214

GL Chart of Accounts

F.10

215

GL Compact Journal

F.02

216

GL Create Foreign Trade Report

F.04

217

GL Delete Sample Documents

F.57

218

GL Drilldown Reports: Background Processing

FGIB

219

GL General Ledger from Document File

F.11

220

GL GR/IR Clearing

F.19

221

GL Open Items

F.51

222

GL Post Balance Sheet Adjustment

F.5E

223

GL Profitability Segment Adjustment

F.50

224

GL Report Selection

F.97

225

GL Structured Account Balances

F.54

226

GL Update Balance Sheet Adjustment

F.5D

227

Import Electronic Bank Statement

FF.5

228

Import Electronic Check Deposit List

FFB4

229

Import Forms from Client 000

FDIR

230

Import Lockbox File

FLB2

231

Import Reports from Client 000

FDIQ

232

Incoming Payments Fast Entry

F-26

233

Interest for Days Overdue, A/R

F.24

234

Invoice/Credit Fast Entry

FB10

235

Maintain Bill of Exchange Liability

F.93

236

Manual Bank Statement

FF67

237

Manual Check Deposit Transaction

FF68

238

Mark Bank for Deletion

FI06

239

Mark Customer for Deletion (Accounting)

FD06

240

Mark Vendor for Deletion (Accounting)

FK06

241

Mass Reversal of Documents

F.80

242

Online Cashed Checks

FCHR

243

Open Item Balance Audit Trail: from Document File

F.58

244

Open Item Sorted List, A/R

F.22

245

Open Items, A/P

F.41

246

Open Items, A/R

F.21

247

Outstanding Bills of Exchange

FF-2

248

Parameters for Automatic Payment

F110

249

Parameters for Payment of Request

F111

250

Park Customer Credit Memo

F-67

251

Park Customer Invoice

F-64

252

Park Document

FBV1

253

Park Vendor Credit Memo

F-66

254

Park Vendor Invoice

F-63

255

Payment Advice Comparison

FF.7

256

Payment Advice Journal

FF-8

257

Payment Card Evaluations

FCCR

258

Payment Cards: Settlement

FCC1

259

Payment Request

F-59

260

Payment with Printout

F-18

261

Periodic Account Statements, A/R

F.27

262

Post Bill of Exchange Usage

F-33

263

Post Collection

F-34

264

Post Customer Down Payment

F-29

265

Post Document

FB01

266

Post Electronic Bank Statement

FEBP

267

Post Electronic Check Deposit List

FFB5

268

Post Foreign Currency Valuation

F-05

269

Post Forfaiting

F-35

270

Post Held Document

FB11

271

Post Incoming Payments

F-06

272

Post Lockbox Data

FLBP

273

Post Outgoing Payments

F-07

274

Post Parked Document

FBV0

275

Post Payment Orders

FF.9

276

Post Tax Payable

FB41

277

Post Vendor Down Payment

F-48

278

Post with Clearing

F-04

279

Post with Reference Document

FBR1

280

Posting Period Table Maintenance

F-60

281

Preliminary Posting

F-65

282

Print Check For Payment Document

FBZ5

283

Print Payment Orders

FF.8

284

Realize Recurring Entry

FBD5

285

Recurring Entries: ABAP/4 Report

F.14

286

Reject Parked Document

FBV6

287

Release for Payments

FB13

288

Renumber Checks

FCH4

289

Report Painter

FGRP

290

Report Painter: Change Form -Customer

FDI5

291

Report Painter: Change Form -GL

FGI5

292

Report Painter: Change Form -Vendor

FKI5

293

Report Writer Menu

FGRW

294

Reprint Check

FCH7

295

Request from Correspondence

FB12

296

Reset Cleared Items

FBRA

297

Reset Cleared Items: Payment Requests

F8BW

298

Returned Bills of Exchange Payable

FBWD

299

Reversal of Bank-to-Bank Transfers

F8BV

300

Reverse Bill Liability

F-20

301

Reverse Check Payment

FCH8

302

Reverse Check/Bill of Exchange

F-25

303

Reverse Cross-Company Code Document

FBU8

304

Reverse Document

FB08

305

Reverse Posting for Accrued/Deferred Documents

F.81

306

Reverse Statistical Posting

F-19

307

SAP Office: Short Message—Create and Send

F00

308

Special Purpose Ledger Menu

FGM0

309

Summary, A/R

FCV1

310

Vendor Account Balance

FK10

311

Vendor Balance Confirmation: ABAP/4 Report

F.18

312

Vendor Balance Display

FK10N

313

Vendor Cashed Checks

FF.4

314

Vendor Check/Bill of Exchange

FBW6

315

Vendor Down Payment Request

FBA6

316

Vendor Interest on Arrears: Post (w/ Open Items)

F.4B

317

Vendor Interest on Arrears: Post (w/o Open Items)

F.4A

318

Vendor Interest on Arrears: Post (w/o Postings)

F.4C

319

Vendor Line Items

FBL1N

320

Vendor Noted Item

F-57

TABLES

TABLE 1.1  Calendar Year Fiscal Year

TABLE 1.2  Non-Calendar Year Fiscal Year

TABLE 1.3  Options for Account Currency Setup

TABLE 1.4  Options for Account Currency Setup

TABLE 1.5  Document Types for Entry View

TABLE 1.6  Business Transactions for Which the System Can Generate Line Items

TABLE 1.7  Parking and Holding Documents

TABLE 1.8  Mass Changes to Line Items

TABLE 1.9  Negative Postings (True Reversal)

TABLE 2.1-1  Classic and New G/L: Table Mapping

TABLE 3.1  Account Determination in Sales and Distribution

TABLE 3.2  Sending Company Code

TABLE 3.3  Payment Method Selection by Payment Program

TABLE 3.4  Settings for Bank Optimization by Bank Group: Optimization Possible

TABLE 3.5  Settings for Bank Optimization by Bank Group: Optimization Not Possible

TABLE 3.6  Settings for Bank Optimization by Postal Code

TABLE 3.7  “Value Date” Settings for Payment Program

TABLE 3.8  “Available Amounts” Settings for Payment Program

TABLE 3.9  Check Cashing Time: the Possibilities for Value Date

TABLE 3.10  Customer/Vendor Evaluations

TABLE 3.11  Interest Calculation Options for Customer/Vendor Accounts

TABLE 4.1  External Transaction Codes in Bank Accounting

TABLE 5.1  Chart of Depreciation and Chart of Accounts: Differences

TABLE 5.2  Methods of Transferring Old Asset Data

TABLE 5.3  Different Environments in FI-AA

TABLE 7.1  SAP Travel Management: Subcomponents

TABLE 7.2  Process Flow in SAP Travel Management

TABLE 7.3  FI-TV Technical Setup Options: Advantages and Disadvantages

TABLE 7.4  FI-TV Technical Setup: Infrastructural Options

TABLE 7.5  Infotypes: Mandatory and Optional

TABLE 7.6  Approvals in Travel Planning

TABLE 7.7  Approval Process Statuses

TABLE 7.8  Reports and Queries in the Travel Expenses Information System

TABLE 8.1  SAP FI Tables

TABLE 9.1  Customizing SAP FI Transaction Codes

TABLE 9.2  Other SAP FI Transaction Codes

FIGURES

FIGURE 0.1  FI Organizational Structure

FIGURE 1.1  FI Organizational Units

FIGURE 1.2  Company and Company Code

FIGURE 1.3  Define a Company

FIGURE 1.4  Options to Define a Company Code

FIGURE 1.5  Define a Company Code (with the “Copy” Function)

FIGURE 1.6  Define a Company Code (with the “Edit Company Code Data” Function)

FIGURE 1.7  Accounting Organization Parameters under Global Parameters

FIGURE 1.8  Processing Parameters under Global Parameters

FIGURE 1.9  Business Area

FIGURE 1.10  Enable Business Area Financial Statements

FIGURE 1.11  Enable Business Area Financial Statements

FIGURE 1.12  Credit Control Area: the Possibilities

FIGURE 1.13  Credit Control Area

FIGURE 1.14  Functional Area

FIGURE 1.15  Activate COS Accounting for Preparation

FIGURE 1.16  COS Activated

FIGURE 1.17  Functional Management (FM) Area

FIGURE 1.18  Profit Center

FIGURE 1.19  Fiscal Year Variant (Calendar Year)

FIGURE 1.20  Shortened Fiscal Year Variant

FIGURE 1.21  Fiscal Year Variant (Non-Calendar Year)

FIGURE 1.22  Assign Fiscal Year Variant to a Company Code

FIGURE 1.23  Posting Periods

FIGURE 1.24  Posting Control through an Authorization Group

FIGURE 1.25  Special Periods

FIGURE 1.26  Year Shift/Displacement in Fiscal Year Variant

FIGURE 1.27  Denoting a G/L Account as a Profit and Loss Statement Account (Individual Processing)

FIGURE 1.28  Denoting G/L Accounts as Profit and Loss Accounts (Collective Processing)

FIGURE 1.29  Retained Earnings Account Configuration

FIGURE 1.30  Currency Settings in IMG

FIGURE 1.31  Local Currency

FIGURE 1.32  Parallel Currencies (2nd and 3rd Local Currency)

FIGURE 1.33  Account Currency Field in a G/L Account

FIGURE 1.34  Exchange Rate Types

FIGURE 1.35  Exchange Rate Spread

FIGURE 1.36  Exchange Rate Table

FIGURE 1.37  Condition Type (Tax Processing)

FIGURE 1.38  Tax Procedures

FIGURE 1.39  Tax Procedure TAXUS

FIGURE 1.40  Account/Process Key for Tax Processing

FIGURE 1.41  Access Sequence with Fields Overview

FIGURE 1.42  Tax Code “S1”

FIGURE 1.43  Control Screen in Transaction Code “WTMG”

FIGURE 1.44  Document Header

FIGURE 1.45  Defining Document Types with New G/L

FIGURE 1.46  Account Type and Document Type

FIGURE 1.47  Document Number Ranges

FIGURE 1.48  Document Number Ranges

FIGURE 1.49  Accounting Editing Options

FIGURE 1.50  Account Assignment Model

FIGURE 1.51  Recurring Entry Document

FIGURE 1.52  Control Totals

FIGURE 1.53  SAP Schedule Manager

FIGURE 2.1A  Chart of Accounts

FIGURE 2.1B  Mapping Country and Operating Charts of Accounts

FIGURE 2.2  G/L Account Groups

FIGURE 2.3  Field Status

FIGURE 2.4  Field Status Variant/Field Status Group

FIGURE 2.5  Assign Field Status Variant to Company Codes

FIGURE 2.6  “Balances in Local Currency” Indicator in G/L Account

FIGURE 2.7  “Line Item Display” Indicator in Account Master

FIGURE 2.8  Financial Statement Version

FIGURE 2.9  Items in a Financial Statement Version

FIGURE 2.1-1  New G/L Functionality in IMG

FIGURE 2.1-2  Ledgers in New G/L

FIGURE 2.1-3  Entry View

FIGURE 2.1-4  G/L View

FIGURE 2.1-5  Activate New G/L Accounting in IMG

FIGURE 2.1-6  New G/L Accounting Menu in IMG

FIGURE 2.1-7  Deactivating Update of Classic G/L—IMG

FIGURE 2.1-8  Deactivating Update of Classic G/L

FIGURE 2.1-9  Assigning a Data Source to a G/L

FIGURE 2.1-10  Standard and Customer Fields in New G/L Setup

FIGURE 2.1-11  Document Splitting Methods

FIGURE 2.1-12  Document Splitting: Levels of Details

FIGURE 2.1-13  Document Splitting Characteristics for G/L

FIGURE 2.1-14  Document Splitting: Deactivate for Select Company Codes

FIGURE 2.1-15  Reconciliation Posting Using Transaction Code KALC

FIGURE 2.1-16  Variant for CO-to-FI Real-Time Integration

FIGURE 2.1-17  Retrospective Transfer of CO Documents to FI

FIGURE 2.1-18  Transfer Payables/Receivables Elimination

FIGURE 2.1-19  Eliminating PCA Allocations through New G/L Allocations

FIGURE 2.1-20  Closing Cockpit

FIGURE 2.1-21  Defining Organizational Hierarchy

FIGURE 2.1-22  Folders and Tasks

FIGURE 2.1-23  Type of Task

FIGURE 2.1-24  Dependencies

FIGURE 3.1  Vendor Master Record—Various Data

FIGURE 3.2  Vendor Master Record—Purchasing Data

FIGURE 3.3  FI Tolerance Group (Employee Tolerance)

FIGURE 3.4  Customer/Vendor Tolerances

FIGURE 3.5  Sales Cycle

FIGURE 3.6  Automatic Account Determination in SD

FIGURE 3.7  Client–Credit Control Area–Company Code–Customer

FIGURE 3.8  Dunning Key

FIGURE 3.9  Dunning Procedure List

FIGURE 3.10  Dunning Procedure Overview

FIGURE 3.11  Dunning Level

FIGURE 3.12  Procurement Cycle

FIGURE 3.13  Movement Types

FIGURE 3.14  “Customizing: Maintain Payment Program” Screen

FIGURE 3.15  Sending Company Code Specifications

FIGURE 3.16  Paying Company Code Specifications

FIGURE 3.17  Payment Methods in Country

FIGURE 3.18  Specifications for Payment Method in Country

FIGURE 3.19  Payment Methods in Company Code

FIGURE 3.20  Payment Method in Company Code Specifications

FIGURE 3.21  Specifications for Bank Determination

FIGURE 3.22  Ranking Order in Bank Selection

FIGURE 3.23  Bank Accounts for Payment Method/House Bank Combination

FIGURE 3.24  Available Amounts per Account per House Bank

FIGURE 3.25  Value Date Settings in Paying Company Code

FIGURE 3.26  Maintain Expenses/Charges

FIGURE 3.27  Special G/L Indicators

FIGURE 4.1  Automatic Creation of Bank Directory (Country-Specific)

FIGURE 4.2  House Banks in Bank Directory

FIGURE 4.3  House Bank ID (DB), Country Key, and Bank Key

FIGURE 4.4  Bank Accounts of a House Bank (DB)

FIGURE 4.5  Bank Account Number and G/L Account Number of a House Bank (DB)

FIGURE 4.6  Steps to Distribute Bank Master Data

FIGURE 4.7  BAI Record Format

FIGURE 4.8  BAI2 Record Format

FIGURE 4.9  Posting Functions

FIGURE 4.10  Posting Data for Lockbox

FIGURE 4.11  IBAN in Bank Master Data

FIGURE 4.12  Country-Specific Checks for Bank Master Data

FIGURE 4.13  Repetitive Code in Bank Accounting

FIGURE 4.14  Scenario for Bank Chain

FIGURE 4.15  Create Transaction Types

FIGURE 4.16  Assign Bank Accounts to Transaction Types

FIGURE 4.17  Create Keys for Posting Rules

FIGURE 4.18  Define Posting Rules

FIGURE 4.19  Assign External Transaction Types to Posting Rules

FIGURE 4.20  Create Account Symbols

FIGURE 4.21  Assign Accounts to Account Symbols

FIGURE 5.1  FI-AA Integration with Other Modules

FIGURE 5.2  Lean Implementation in FI-AA

FIGURE 5.3  Sample Charts of Depreciation

FIGURE 5.4  Depreciation Area

FIGURE 5.5  How a Depreciation Area Posts to G/L

FIGURE 5.6  Real and Derived Depreciation Areas

FIGURE 5.7  Book Depreciation (01): Typical Settings

FIGURE 5.8  Asset Class

FIGURE 5.9  Generate Asset Class from G/L Accounts (1 to 1)

FIGURE 5.10  Index Series

FIGURE 5.11  Create Asset: Initial Screen

FIGURE 5.12  Time-Dependent Cost Center Data

FIGURE 5.13  Block Indicator (Acquisition Lock) in Asset Master

FIGURE 5.14  Transaction Types

FIGURE 5.15  Transaction Type Group

FIGURE 5.16  Transfer Variant

FIGURE 5.17  Specifications in a Transfer Variant

FIGURE 5.18  Asset Retirement

FIGURE 5.19  Asset Scrapping

FIGURE 5.20  Depreciation Keys

FIGURE 5.21  Internal Calculation Key

FIGURE 5.22  Periodic Processing

FIGURE 5.23  Smoothing versus Catch-Up

FIGURE 5.24  Legacy Asset Transfer to SAP FI-AA

FIGURE 5.25  Configuring the Asset History Sheet

FIGURE 5.26  Asset History Sheet Versions

FIGURE 5.27  Asset History Sheet Version: Field Positions

FIGURE 5.28  Details of Line 4/Column 10

FIGURE 5.29  Asset Report Tree

FIGURE 5.30  Asset Explorer

FIGURE 6.1  Value IDs (Image ©SAP)

FIGURE 6.2  Leasing Types

FIGURE 7.1  Travel Planning in SAP Travel Management

FIGURE 7.2  Roles in SAP FI-TV

FIGURE 7.3  SAP FI-TV: Technical Setup

FIGURE 7.4  SAP Travel Manager: Initial Screen

FIGURE 7.5  Personal Settings in Travel Manager

FIGURE 7.6  Infocenter

FIGURE 7.7  Planning Manager

FIGURE 9.1  Fields in Table TSTCT

FIGURE 9.2  Initial Screen in SE93

FIGURE 9.3  Search using F4 in SE93

FIGURE 9.4  Search in an Application Component

FIGURE 9.5  Select an Application Component

FIGURE 9.6  Drill Down to the Desired Node of an Application Component

FIGURE 9.7  Application Component Selected for T-Code List

FIGURE 9.8  T-Codes Listed for the Selected Application Component