Configuring SAP Accounts Receivable &
Accounts Payable
SAP S/4HANA Finance
Narayanan Veeriah
Configuring SAP Accounts Receivable &
Accounts Payable
SAP S/4HANA Finance
© Narayanan Veeriah
1st Edition, 2020
All rights reserved. Neither this publication nor any part of it may be copied or reproduced in any form / manner or by any means
or translated into another language, without the prior and explicit consent of the author (Narayanan Veeriah).
The author / publisher makes no warranties or representations with respect to the content hereof and specifically disclaims any
implied warranties of merchantability or fitness for any purpose. The author / publisher is not responsible for any errors that
may appear in this publication.
All the screenshots reproduced in this book are subject to copyright © SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany.
SAP, the SAP logo, ABAP, Ariba, Concur, SAP ArchiveLink, SAP Ariba, SAP Business By Design, SAP Business Explorer, SAP Business
Objects, SAP Business Objects Explorer, SAP Business Objects Web Intelligence, SAP Activate, SAP Business One, SAP Business
Workflow, SAP Crystal Reports, SAP Fieldglass, HANA, HANA 2.0, SAP HANA, SAP S/4HANA, SAP S/4HANA Finance, SAP GoingLive,
SAP Hybris, SAP R/1, SAP R/2, SAP R/3, SAP ECC, SAP ERP, SAP SQL Anywhere, SAP SD, SAP MM, SAP PP, SAP PM, SAP PS, SAP
SEM, SAP SuccessFactors, SAP Query are registered or unregistered trademarks of SAP SE, Walldorf, Germany.
All other products mentioned in this book are the registered or unregistered trademarks of their respective companies.
Acknowledgements
I acknowledge the understanding and adjustments made by my family, especially my wife, for
all the encouragement and letting me concentrate working on this book, as with previous
other books. I thank Narayanan Krishnan, who helps in checking out the content for its
correctness.
Preface
7
Preface
This book (Configuring SAP Accounts Receivable & Accounts Payable – SAP S/4HANA Finance),
as with my other books on SAP, follows a case-study approach to make your learning easy.
Every effort has been taken to guide you, step-by-step, in configuring your SAP system in
implementing SAP Accounts Receivable and Accounts Payable, in SAP S/4HANA (1909), to
meet your exact business needs. Each configuration activity has been discussed with
appropriate screen shots (from an SAP system) and illustrations to help you ‘see’ what is being
discussed in that activity / step. You will see a lot of additional information, provided across
the Chapters and the Sections, to help you understand better a topic or a setting or a concept.
The entire content of the book, vide various Chapters, has been presented as in SAP IMG
(Implementation Guide) for easy comprehension. You will come across with appropriate
menu paths and Transactions, to help you to navigate the various configuration activities.
As mentioned already, this book follows a case-study approach with a story-board technique,
that provides you with the required business background for a given configuration activity.
The Case Study Chapter discusses the Project Dolphin, setting up the tone for further
discussions in the remaining Chapters.
The Chapter 1 introduces you to SAP Accounts Receivable and Accounts Payable.
The Chapter 2 deals with the customer accounts. It provides an overview of master data, the
preparations that you need to make to create the master data and how to change / delete
them. It also provides you with the details of configuration that you need to complete for
displaying line item and account balances.
The Chapter 3 discusses vendor accounts, and is similar to Chapter 2. Here, you will also come
across on how to define a threshold to flag when an overdue payment to a vendor should
actually be termed as ‘critically overdue’.
The Chapter 4 deals with incoming invoices / credit memos. As a part of the discussions, you
will make/check various document settings including document types, posting keys,
validations / substitution in accounting documents, field status variant, screen variants for
document entry, text IDs, line layout for document & line items, document change rules etc.
You will also understand the various settings for document parking: workflow variants,
release approval groups / paths / procedure, resetting release approvals and so on. You will
also learn about maintaining terms of payment and cash discount base for incoming invoices.
In Chapter 5, you will understand the configuration relating to payment release. You will learn
to define payment block reasons for payment release.
8
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
The Chapter 6 is devoted for incoming payments. You will learn about configuring outgoing
payments global settings, manual and automatic outgoing payments. You will also learn about
defining various accounts for cash discount taken / lost, overpayments / underpayments,
exchange rate differences, rounding differences etc. You will, then, learn about tolerances
including vendor tolerances, reason codes and cross-company code manual payments. In
configuring automatic payments, you will understand the concept of house banks, how to
define them, setting up the company code(s) for payment transactions, payment methods,
bank determination, value date rules, payment grouping etc.
The Chapter 7 is on outgoing invoices / credit memos. The settings are similar to the ones that
you will come across in in Chapter 4. Besides that, here, you will learn to define cash discount
base for outgoing invoices, tax accounts and posting key for outgoing invoices.
The Chapter 8 will deal with incoming payments. You will notice that the settings discussed
for outgoing payments (Chapter 6) will also apply for incoming payments. Additionally, you
will learn about SEPA mandates and how to configure that in the system.
The Chapter 9 is on payments with payment cards. You will learn about payment cards, and
the central settings that you need to make on the FI side.
The Chapter 10 deals dunning in detail. You will understand the basic settings including the
dunning areas, dunning keys, dunning block reasons and dunning forms. You will learn about
dunning procedures, dunning groups and interest rates. You will also learn how to set up the
dunning forms. You will understand the dunning process flow, and comprehend how the
system selects the items to be dunned, how to create /edit / execute a dunning proposal.
The configuration relating to open item clearing is discussed in Chapter 11. Here, you will
learn about processing of open items, preparing the system for automatic clearing and how
to handle the clearing differences.
The Chapters 12 & 13 deal with down payment received and down payment made,
respectively. You will learn about setting up of reconciliation / alternate reconciliation
accounts, tax accounts and tax clearing accounts towards the required configuration.
In Chapter 14, you will learn about adjustment posting / reversal. You will learn about
negative posting and also the reasons for reversal.
The Chapter 15 is devoted for interest calculation. You will learn the fields, in customer /
vendor master, that are relevant for interest calculation. You will understand the interest
calculation process: the prerequisites, item selection for interest calculation and the actual
process of item interest calculation. You will learn to configure the settings for interest
calculation global settings, item interest calculation, interest posting and interest printouts.
Preface
9
In Chapter 16, you will learn about the various closing processes relating to FI-A/R and FI-A/P.
You will understand how to configure the system for carrying out the closing operations like
count, valuate and reclassify.
You will learn the details of standard evaluations, as a part of accounts receivable / payable
information system in Chapter 17.
In the last Chapter (Chapter 18), you will learn about the important Fiori Apps for Finance,
that are available for your accounts payable accountants / managers, accounts receivable
accountants / managers, and credit controllers.
In all, you can use this book as a desktop-reference for configuring SAP Accounts Receivable
and Accounts Payable. As the Chapters have been progressively elaborated, with the help of
a case-study, you will that informative and easy to comprehend. The screenshots, in each of
the Chapters, will help you understand the settings better and will enable for a better
learning.
Contents at a Glance
Case Study 23
Accounts Receivable and Accounts Payable 45
Customer Accounts 49
Vendor Accounts 81
Incoming Invoices/Credit Memos 99
Release for Payments 155
Outgoing Payments 157
Outgoing Invoices/Credit Memos 225
Incoming Payments 229
Payments with Payment Cards 237
Dunning 243
Open Item Clearing 273
Down Payment Received 281
Down Payment Made 285
Adjustment Posting/Reversal 289
Interest Calculation 295
Closing 325
Information System 377
Apps for FI-A/R & FI-A/P 383
About the Author
Index
List of Figures
List of Tables
Latest Books by the Author
Other Books by the Author
Table of Contents
Case Study
23
1
45
Accounts Receivable and Accounts Payable
1.1
2
Conclusion
Customer Accounts
2.1
Master Data
2.1.1 Preparations for Creating Customer Master Data
2.1.1.1
2.1.1.2
2.1.1.3
2.1.1.4
2.1.1.5
2.1.1.6
2.1.1.7
2.1.1.8
2.1.1.9
2.1.1.10
Define Account Groups with Screen Layout (Customers)
Define Screen Layout per Company Code (Customers)
Define Screen Layout per Activity (Customers)
Change Message Control for Customer Master Data
Define Accounting Clerks
Define Industries
Create Number Ranges for Customer Accounts
Assign Number Ranges to Customer Account Groups
Define Accounts Receivable Pledging Indicator
Define Sensitive Fields for Dual Control (Customers)
2.1.2 Preparations for Changing Customer Master Data
2.1.2.1
2.1.2.2
Define Field Groups for Customer Master Records
Group Fields for Customer Master Records
2.1.3 Delete Customer Master Data
2.2
Line Items
2.2.1 Display Line Items
2.2.2 Open Item Processing
2.2.3 Correspondence
2.2.3.1
2.3
Define Period Types for Customers
Balances
2.3.1 Maintain Worklist for Displaying Balances
2.3.2 Maintain Users and Accounts for Internet Services
2.1
Conclusion
48
49
49
52
53
57
58
59
59
60
62
63
63
66
70
70
71
73
75
75
75
75
76
77
77
79
80
14
3
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Vendor Accounts
3.1
Master Data
3.1.1 Preparations for Creating Vendor Master Data
3.1.1.1
3.1.1.2
3.1.1.3
3.1.1.4
3.1.1.5
3.1.1.6
Define Account Groups with Screen Layout (Vendors)
Define Screen Layout per Company Code (Vendors)
Define Screen Layout per Activity (Vendors)
Create Number Ranges for Vendor Accounts
Assign Number Ranges to Vendor Account Groups
Define Sensitive Fields for Dual Control (Vendors)
3.1.2 Preparations for Changing Vendor Master Data
3.1.2.1
3.1.2.2
Define Field Groups for Vendor Master Records
Group Fields for Vendor Master Records
3.1.3 Delete Vendor Master Data
3.2
Line Items
3.2.1 Display Line Items
3.2.2 Open Item Processing
3.2.3 Correspondence
3.2.3.1
4
Define Period Types for Vendors
81
81
84
84
85
86
87
88
89
91
91
92
94
94
94
95
95
95
3.3
Define Thresholds for Vendor Account Groups
96
3.4
Conclusion
97
Incoming Invoices/Credit Memos
4.1
Make and Check Document Settings
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.1.7
4.1.8
4.1.9
4.1.10
Define Document Types
Define Posting Keys
Validation in Accounting Documents
Define Default Values
Define Field Status Variants
Assign Company Code Field Status Variants
Define Subscreens for Coding Blocks
Screen Variants for Document Entry
Substitution in Accounting Documents
Text IDs for Documents and Line Items
4.1.10.1
4.1.10.2
4.1.10.3
Define Text IDs for Documents
Define Text Identifications for Line Items
Define Texts for Line Items
4.1.11 Define Line Layout for Document Posting Overview
4.1.12 Define Line Layout for Document Change/Display
99
99
100
104
111
116
118
122
123
125
126
127
129
129
130
133
133
Contents
15
4.1.13 Select Standard Line Layout for Document Change/Display
4.1.14 Document Change Rules, Document Header
4.1.15 Maintain Fast Entry Screens for G/L Account Items
4.2
Make and Check Settings for Document Parking
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.2.10
5
6
Define Entry Screens for Parking Documents
Create Workflow Variant for Parking Documents
Assign Company Code to a Workflow Variant for Parking Documents
Define Release Approval Groups for Parking Documents
Define Release Approval Paths for Parking Documents
Assign Release Approval Paths for Parking Documents
Assign Release Approval Procedure for Parking Documents
Define Users with Release Authorization for Parking Documents
Reset Release Approval (Customers)
Reset Release Approval (Vendors)
134
135
136
137
138
138
139
140
141
141
142
143
145
146
4.3
Maintain Terms of Payment
146
4.4
Define Terms of Payment for Installment Payments
151
4.5
Define Cash Discount Base for Incoming Invoices
152
4.6
Conclusion
153
Release for Payment
155
5.1
Define Payment Block Reason for Payment Release
155
5.2
Conclusion
156
Outgoing Payments
6.1
Outgoing Payments Global Settings
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.1.7
6.1.8
6.1.9
6.1.10
Make and Check Document Settings
Define Accounts for Cash Discount Taken
Define Accounts for Lost Cash Discount
Define Accounts for Overpayments/Underpayments
Define Accounts for Exchange Rate Differences
Define Account for Rounding Differences
Define Accounts for Payment Differences with Altern. Currency
Define Accounts for Bank Charges (Vendors)
Define Posting Keys for Clearing
Enable Translation Posting
157
157
157
158
158
159
160
161
162
163
163
165
16
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.1.11 Payment Block Reasons
6.1.11.1
6.1.11.2
6.2
Define Payment Block Reasons
Define Default Values for Payment Block
Manual Outgoing Payments
6.2.1 Tolerances (Vendors)
6.2.1.1
6.2.1.2
6.2.1.3
Define Tolerance Groups for Employees
Define Tolerance Groups for G/L Accounts
Define Tolerances (Vendors)
6.2.2 Define Reason Codes (Manual Outgoing Payments)
6.2.3 Cross-Company Code Manual Payments
6.2.3.1
6.2.3.2
Cross-Company Code Transactions
Prepare Cross-Company Code Manual Payments
6.2.4 Configure Manual Payments
6.3
Automatic Outgoing Payments
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
6.3.8
6.3.9
6.3.10
6.3.11
6.3.12
6.3.13
6.3.14
6.4
7
Define House Banks
Set Up All Company Codes for Payment Transactions
Set Up Paying Company Codes for Payment Transactions
Set Up Payment Methods per Country for Payment Transactions
Set Up Payment Methods per Company Code for Payment Transactions
Set a Payment Medium Format per Company Code
Set Up Bank Determination for Payment Transactions
Define Value Date Rules
Assign Payment Method to Bank Transaction
Define Payment Groupings
Prepare Automatic Postings for Payment Program
Prepare Automatic Posting for Payment Requests
Select Search Fields for Payments
Select Search Fields for Line Item Display
Conclusion
Outgoing Invoices/Credit Memos
165
165
166
166
167
167
174
176
180
182
182
184
186
187
189
194
197
200
204
210
211
217
218
218
219
220
220
221
222
225
7.1
Define Cash Discount Base for Outgoing Invoices
225
7.2
Define Tax Accounts for Outgoing Invoices
226
7.3
Define Posting Key for Outgoing Invoices/Credit Memos
227
7.4
Conclusion
227
Contents
8
Incoming Payments
8.1
Incoming Payment Global Settings
8.1.1 Define Accounts for Cash Discount Granted
229
229
229
8.2
Manual Incoming Payments
230
8.3
Automatic Incoming Payments
230
8.4
Management of SEPA Mandates
230
8.4.1
8.4.2
8.4.3
8.4.4
8.4.5
8.5
9
17
General Settings
Define Available Function Modules for Generating Mandate IDs
Select Function Module for Generating Mandate IDs
Define Number Range Intervals
Assign Number Range Intervals
Conclusion
Payments with Payment Cards
231
232
232
233
233
234
237
9.1
Make Central Settings for Payment Cards
237
9.2
Assign G/L Account to Cash Clearing Account
239
9.3
Conclusion
240
10 Dunning
243
10.1 Basic Settings for Dunning
10.1.1
10.1.2
10.1.3
10.1.4
Define Dunning Areas
Define Dunning Keys
Define Dunning Block Reasons
Define Dunning Forms
10.2 Dunning Procedure
10.2.1 Define Dunning Procedures
10.2.2 Define Dunning Groups
10.2.3 Define Interest Rates
10.2.3.1
Define Interest Calculation Types
10.3 Printout
10.3.1 Define Dunning Forms (with SAPScript)
10.3.2 Define Dunning Forms (with SAP Smart Forms)
10.3.3 Assign Dunning Forms
245
245
247
248
249
251
251
260
260
261
262
263
263
263
18
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
10.3.4 Define Sender Details for Dunning Forms
265
10.4 Generate List for Dunning Program Configuration
266
10.5 Dunning Process Flow
267
10.6 Conclusion
270
11 Open Item Clearing
273
11.1 Make Settings for Processing Open Items
276
11.2 Prepare Automatic Clearing
276
11.3 Clearing Differences
278
11.3.1 Define Accounts for Clearing Differences
11.4 Conclusion
12 Down Payment Received
278
279
281
12.1 Define Reconciliation Accounts for Customer Down Payments
281
12.2 Define Tax Accounts for Down Payments Received
282
12.3 Define Account for Tax Clearing
283
12.4 Conclusion
284
13 Down Payment Made
285
13.1 Define Alternative Reconciliation Account for Down Payments
285
13.2 Define Account for Tax Clearing
286
13.3 Conclusion
287
14 Adjustment Posting / Reversal
289
14.1 Permit Negative Posting
289
14.2 Define Reasons for Reversal
291
14.3 Conclusion
293
Contents
15 Interest Calculation
19
295
15.1 Fields Relevant for Item Interest Calculation
295
15.2 Item Interest Calculation Process
297
15.2.1 Prerequisites
15.2.2 Executing Item Interest Calculation Program
15.2.3 The Interest Calculation Process
15.2.3.1
15.2.3.2
15.2.3.3
15.2.3.4
15.2.3.5
15.2.3.6
Item Selection
Interest Calculation
Interest Posting
Printout
Others
Old and New Interest Calculation Programs
15.3 Interest Calculation Global Settings
15.3.1
15.3.2
15.3.3
15.3.4
Define Interest Calculation Types
Define Number Ranges for Interest Forms
Prepare Item Interest Calculation
Prepare Account Balance Interest Calculation
15.4 Interest Calculation
15.4.1
15.4.2
15.4.3
15.4.4
Define Reference Interest Rates
Define Time-Dependent Terms
Enter Interest Values
Define Fixed Amounts for Interest Calculation
15.5 Interest Posting
15.5.1
15.5.2
15.5.3
15.5.4
A/R: Calculation of Interest on Arrears
Interest on Arrears Calculation (Vendors)
A/R: Balance Interest Calculation
A/P: Balance Interest Calculation
15.6 Printout
15.6.1 Assign Forms for Interest Indicators
15.6.2 Define Sender Details for Interest Forms
15.7 Conclusion
297
298
299
299
301
302
302
302
303
304
304
304
305
309
313
313
313
315
315
317
317
320
320
321
322
322
322
323
20
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16 Closing
325
16.1 Count
325
16.1.1 Generate Default Customizing
16.1.2 General Settings
16.1.2.1
16.1.2.2
16.1.2.3
16.1.2.4
16.1.2.5
16.1.2.6
Communication Support
Define Reconciliation Process Attributes
Create Additional Fields
Activate Processes
Activate Transaction Data Tables
Maintain Field Catalogs
16.1.3 Data Selection and Storage
16.1.3.1
16.1.3.2
16.1.3.3
16.1.3.4
Define Reconciliation Process Detail Attributes
Define Ledger
Define Enhancements
Companies to be Reconciled
16.1.4 Data Assignment
16.1.4.1
16.1.4.2
Maintain Number Range for Group Reference Numbers
Define Rules for Document Assignments
16.1.5 Data Reconciliation
16.1.5.1
16.1.5.2
16.1.5.3
16.1.5.4
16.1.5.5
Set Up Reconciliation Display
Define Sets
Set Up Object Groups and Subgroups
Define Possible Status for Documents
Define Enhancements
16.1.6 Balance Confirmation Correspondence
16.1.6.1
16.1.6.2
Define Reply Addresses for Balance Confirmation
Specify Selection Criteria for Balance Confirmation
16.2 Valuate
16.2.1 Foreign Currency Valuation
16.2.1.1
16.2.1.2
16.2.1.3
16.2.1.4
16.2.1.5
16.2.1.6
16.2.1.7
16.2.1.8
Define Valuation Methods
Valuation Areas
Check Assignment of Accounting Principle to Ledger Group
Assign Valuation Areas and Accounting Principles
Activate Delta Logic
Prepare Automatic Postings for Foreign Currency Valuation
Activate Additional Fields for Foreign Currency Valuation
Define Account Determination for Currency Translation
16.2.2 Reserve for Bad Debt / Writing Off of Bad Debt
16.2.2.1
16.2.2.2
Individual Value Adjustment
Flat-Rate Valuation Adjustment
16.2.3 Valuations
326
330
330
334
334
335
336
338
339
339
341
341
342
343
343
344
345
345
346
347
349
350
351
351
351
353
353
355
356
357
358
358
359
361
362
362
362
363
364
Contents
16.2.3.1
16.2.3.2
16.2.3.3
16.2.3.4
16.2.3.5
Define Value Adjustment Key
Define Interest Calculation Types
Define Accounts
Determine Base Value
Determine Values for Line Item Display
16.3 Reclassify
21
364
365
366
367
368
368
16.3.1 Define Adjustment Accounts for GR/IR Clearing
368
16.3.2 Define Accounts for Subsequent Adjustment
369
16.3.3 Define Sort Method and Adjustment Accts for Regrouping Receivables / Payables
371
16.3.4 Define Adjustment Accounts for Receivables/Payables by Maturity
372
16.4 Conclusion
17 Information System
17.1 Standard Evaluations
17.1.1 Copy Standard Evaluations
17.1.2 Select Standard Evaluations
17.1.3 Enhance Standard Evaluations
17.2 Conclusion
18 Apps for FI-A/R & A/P
374
377
377
377
378
381
382
383
18.1 Apps for Accounts Payable Accountants
383
18.2 Apps for Accounts Payable Managers
387
18.3 Apps for Accounts Receivable Accountants
389
18.1 Apps for Accounts Receivable Managers
393
18.2 Apps for Credit Controllers
397
18.3 Conclusion
397
Case Study
T
he case study, Project Dolphin, relates to BEST Machinery, also known as BESTM, is the
corporate group having companies operating out of both United States of America
(USA) and India, among other countries. The case study is, however, limited to the
operations in USA and India. BESTM group has three companies namely, BESTM Agro, BESTM
Construction and BESTM Drives. All the three companies are operating out of USA from the
same address as that of the corporate group at Glen Ridge, New Jersey:
✓ BESTM Agro is the flagship company and is made up of four company codes – two in
USA and two in India. This company, through its various legal entities, is in the
business of manufacturing, supplying and servicing tractors for agricultural and other
uses, agricultural implements, lawn & garden mowers, and equipments required by
the forestry industry.
✓ BESTM Construction manufactures and services all kinds of trucks and heavy
machinery used in the construction industry like dump trucks, track & crawler loaders,
excavators, dozers etc. It has two company codes both of which are operating out of
USA.
✓ BESTM Drives is in the business of making and servicing industrial diesel engines
including diesel generators, and drivetrain related equipments like transmissions,
axles, gear drives etc. This company is comprising of two USA-based company codes.
BESTM group had been using a variety of software applications, built and bought over a period
of years, to meet all their business requirements. Because of a plethora of applications, which
were often different between USA and India, the corporate was finding it difficult to integrate
the information that hampered their decision making. Calling for a lot of manual interventions
and time-consuming reconciliations, they were finding it hard to close their books in time.
Also, there were lot of redundancies and duplicity as the applications were not fully
integrated. Hence, the corporate group was thinking of to go in for an ERP that would
overcome all these shortcomings, and they wanted to bring in the latest in ERP so that they
would have an enterprise solution that would not only be state-of-the-art, but also insulate
them from becoming obsolete in the near future. Accordingly, the management had taken
decision to implement the SAP S/4HANA suite of applications, and it was decided to deploy
the application on-premise.
24
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
BESTM decided to partner with a leading IT firm to manage the implementation and the
transition to SAP S/4HANA. The implementation was code named as ‘Project Dolphin’. The
project team had several discussions and workshops with the BESTM management at various
levels, and what you see in the following pages is the outcome of those discussions /
workshops.
The project team will define three companies in SAP, as shown in Table 0.1:
Company
BESTM Agro
BESTM Construction
BESTM Drives
Company ID
B1000
B2000
B3000
Country
USA
USA
USA
Currency
USD
USD
USD
Table 0:1 BESTM - Companies
BESTM Agro company has the following legal entities (company codes) operating out of USA:
1. BESTM Farm Machinery
2. BESTM Garden & Forestry Equipments
BESTM Agro also operates in India through the following company codes:
1. BESTM Farm Machinery
2. BESTM Garden & Forestry Equipments
BESTM Construction company is made up of the following legal units functioning out of USA:
1. BESTM Trucks
2. BESTM Other Construction Equipments
BESTM Drives manages the following legal units:
1. BESTM Drives
2. BESTM Engines
All the company codes, except the ones in India, will have USD as their company code
currency; the ones in India will have INR as the company code currency. All the company codes
will use English as the official language. Each of these company codes will have 4-digit
numerical identifier as indicated in the Table 0.2.
Company Code
BESTM Farm Machinery
BESTM Garden & Forestry Equipments
BESTM Farm Machinery
BESTM Garden & Forestry Equipments
BESTM Trucks
BESTM Other Construction Equipments
Company Code ID
1110
1120
1210
1220
2100
2200
Country
USA
USA
India
India
USA
USA
Currency
USD
USD
INR
INR
USD
USD
Case Study
BESTM Drives
BESTM Engines
3100
3200
USA
USA
25
USD
USD
Table 0:2 BESTM - Company Codes, Country and Currency
There will be a total of four credit control areas: one each for the companies B2000 (BESTM
Construction) and B3000 (BESTM Drives), and two credit control areas for company B1000
(BESTM Agro). These credit control areas will be denoted by a 4-character numeric identifier.
The details of credit control area, currency etc will be as shown in Table 0.3
Company
B1000
B2000
B3000
Company Code
1110
1120
1210
1220
2100
2200
3100
3200
Credit Control CCA
Area (CCA)
Currency
1100
USD
1200
INR
2000
USD
3000
USD
Default Credit
Limit
10,000
700,000
20,000
30,000
Table 0:3 BESTM – Credit Control Areas
Since it has been decided to default some of the credit control data while creating the
customer master records in each of the company codes, a default credit limit has been
mentioned per credit control area as denoted in the table above. BESTM wants the users not
to be allowed to change the default credit control area during document posting.
BESTM group requires several business areas cutting across company codes (Table 0.4) to
report and monitor the operations of different operational areas like agri. tractor business,
agri. equipments, after-sales services, garden equipments etc.
Business Area
Agri Tractor Business
Agri Equipments
After-sales Service
Garden Equipments
Forestry Equipments
Construction Machinery
Drives & Engines
Military Sales
Table 0:4 BESTM – Business Areas
Business Area Identifier
ATRA
AEQP
ASER
GEQP
FEQP
CONM
DREN
MILI
26
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
BESTM group plans to create their own functional areas with easy-to-remember IDs. The
project team shall copy the SAP supplied functional areas into the new ones, like BM20
(Production), BM25 (Consulting/Services), BM30 (Sales & Distribution) and so on. BESTM
wants the project team to configure the system to derive the functional areas automatically.
BESTM requires the following four FM (Financial Management) areas:
• BF11: FM area for USA-based company codes of BESTM Agro
• BF12: FM area for India-based company codes of BESTM Agro
• BF21: FM area for USA-based company codes of BESTM
• BF31: FM area for USA-based company codes of BESTM Drives
BESTM requires the following business segments to be defined for segment reporting. BESTM
wants to have a 10-character alpha-numeric ID segments, with the first three indicating the
company code (say, B11/B12/B13 for company B1000, B21/B22 for company 2000 and so on),
and the last seven characters, a meaningful abbreviation of the segment description.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
B11FMTRACT
B12HARCOMB
B12FMIMPLE
B12FORESTY
B13LANTRAC
B13LANMOWR
B13GRDNUTL
B13GOLFSPR
B21LODRDOZ
B22EXCAVAT
B31DRVTRAN
B32GENERAT
B33INDSENGN
B33MARENGN
Farm Tractors
Harvester Combines
Farm Implements
Forestry Equipments
Lawn Tractors
Lawn Mowers
Garden Utility Vehicles
Golf and Sports Equipments
Loaders and Dozers
Excavators and other Construction Equipments
Drivetrain Components
Generators
Industrial Diesel Engines
Marine Engines
BESTM group has decided to have three controlling areas, BESTM Agro (B1000), BESTM
Construction (B2000) and BESTM Drives (B3000) with USD as CO area currency. They will need
to be denoted as B100, B200 and B300 respectively.
BESTM group has indicated that they need profit centers, defined in such a way, to represent
the actual internal management as in Table 0.5:
Controlling Area
B100
Profit Center Group
Tractors
Profit Center
Farm Tractors
Lawn Tractors
Speciality Tractors
Case Study
Farm Equipments
Garden Equipments
Others
Light Machinery
B200
Heavy Machinery
Others
Drives
B300
Engines
Generators
Others
27
Cultivators & Planters
Harvesters
Seeding / Fertilizing Equipments
Sprayers & Liquid Systems
Lawn Movers
Garden Utility Vehicles
Misc. Farm / Garden Equipments
Forest Machinery
Others (B100)
Compact Machines
Building Equipments
Heavy Equipments
Road Machinery
Mining Equipments
Miscellaneous Construction
Machinery
Others (B200)
Gear Drives
Pump Drives
Transmissions
Industrial Engines
Commercial Marine Engines
Pleasure Marine Engines
Stationary Generators
Portable Generators
Military Solutions
Others (B300)
Table 0:5 BESTM – Profit Centers / Profit Center Groups
Looking at the SAP-supplied transaction types in the system, the Dolphin Project team has
decided not to add any new transaction type for consolidation for BESTM. They have also
decided not to add any new coding fields in the system. This has been finalised after a
thorough study of the SAP defined standard coding fields.
The project team has decided to use a single field status variant (FSV), B100, in all the
company codes of BESTM. They have further recommended that (a) ‘Business Area’ and
‘Functional Area’ fields to be set as ‘required’ for data entry, and (b) ‘Payment Reference’ field
as ‘optional entry’ field.
28
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
The team has recommended to use different ledgers to meet the different statutory
requirements of the company codes: (1) BESTM group of companies will use the SAP supplied
standard ledger 0L as their leading ledger and that will meet the International Accounting
Standards (IAS), (2) US-based company codes will use a non-leading ledger (BU) to meet the
local accounting requirements (US GAAP) and (3) India-based company codes will use another
leading ledger (BI) to meet India’s legal reporting (Ind-AS). BESTM management is of the
opinion that the project team combines the leading ledger (0L) and the non-leading ledger
(BU) into a ledger group called B1 as the accounting principles of IAS (0L) and US GAAP (BU)
are the same as there will almost be identical postings to both of these accounting principles.
BESTM wants to leverage the ‘extension edger’ functionality of SAP S/4HANA. Accordingly,
the project team has proposed to define four extension ledgers: one for general purpose, the
other for simulation, the third for prediction & commitment and the fourth for valuation
purposes accounting for valuation differences. In all the cases, BESTM wants manual postings.
BESTM does not want to create new fiscal year variants (FYVs), but shall use the SAP supplied
ones. Accordingly, FYV ‘K4’ will be used for all the US-based company codes and V3 will be
used by India-based company codes. To simplify opening and closing of posting periods in the
system without much complications, it has been decided to define separate posting period
variant (PPV) per company code.
There will be two new charts of accounts defined in the system, BEUS for US-based company
codes and BEIN for India-based company codes. The respective Financial Statement Version
(FSV) will also be created in the same name as that of the chart of accounts. For all the USbased company codes, both the operative and country chart of accounts will be the same:
BEUS. In the case of India-based company codes, the operative chart of accounts will be BEUS
and the country chart of accounts will be BEIN. A suitable document entry screen variant that
facilitates country-specific processing of withholding tax needs to be used in all the US-based
company codes.
If there is a difference in currency translation due to exchange rate fluctuations during
transaction posting, then, a maximum of 10% has to be allowed as the permitted deviation.
However, this will not be applicable to the tax postings as all the tax items have to be
translated using the exchange rate from the document header. All the US-based company
codes will use a single variant as the workflow variant. It has been decided to allow negative
postings, thereby avoiding inflated trial balance.
BESTM wants to activate Cost of Sales (CoS) accounting, in all the company codes, to
understand the outflow of economic resources engaged in making the company’s revenue. It
has also been decided that suitable configuration to be made to enable drawing up of financial
statements per business area. Further, it has been requested that the system should clear the
foreign currency open items into local currency using the prevailing exchange rate instead of
Case Study
29
using the original exchange rate; any gain/loss arising out of this, needs to be posted to the
designated G/L accounts.
BESTM does not want the system to propose fiscal year during document change or document
display functions, as it expects all the company codes to work with year-independent
document numbers. However, the current date can be defaulted to as the ‘value date’ while
entering the line items in a document.
Since USA makes use of the jurisdiction codes for tax calculation, BESTM wants the tax base
to remain at the jurisdiction code level, for all the US-based company codes. For the company
codes in India, the tax base has to be configured as the net of discount of the invoice amount.
BESTM does not want to define any new document type, and has decided to use the standard
ones. It has also been decided to use the same document type for document reversals. To
restrict the access to the closing operations, BESTM wants to make use of user authorization
through document type CL. To make cross-verification easier, the project team has decided
to make the ‘Reference’ field mandatory for data input for invoice postings and credit memos.
There will be no change in the default document type / posting key for the common
transactions. The posting date = system date, when posting a parked document.
BESTM does not want to define any new posting keys in the system. However, BESTM has
requested to configure the posting keys in such a way that (a) 'Invoice Reference' to be made
mandatory for all payment transactions, (b) 'Payment Reference' is optional for document
reversals and (c) a valid reason to be mandatory for all payment difference postings.
BESTM wants numerical number ranges for all the document types, in all the company codes.
The project team has decided to define a number range 91 (9100000000 to 9199999999) for
document type CL in non-leading ledgers. All the number ranges are to have a validity of 9,999
years, so as to overcome any additional configurations every year.
BESTM management has indicated that it requires two additional tolerance groups, besides
the null tolerance group, to be configured in the system: the tolerance group TGUS will be for
all the US-based company codes, and TGIN for the India-based company codes. It is further
stipulated that these special tolerance groups will have only a handful of employees assigned,
in each company code, to handle special situations and high-value customers / vendors, as
these additional groups will have liberal tolerances in comparison to the null group.
All the employees who are allocated to the tolerance group TGUS will be allowed to post
accounting documents of maximum value USD 999,999,999 per document, with a limit of USD
99,999,999 per open item. However, they can process cash discounts at 5% per line item, with
the system allowing a maximum payment difference of 3%, subject to an absolute maximum
of USD 500. The cash discount adjustment amount will be USD 100.
30
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
As already indicated, the tolerance group TGIN will be for the two India-based company codes
(1210 and 1220). The select employees who are part of this group will be allowed to post
accounting documents of maximum value INR 999,999,999 per document with a limit of INR
99,999,999 per open item. However, they can process cash discounts at 5% per line item, with
the system allowing a maximum payment difference of 3%, subject to an absolute maximum
of INR 5,000. The cash discount adjustment amount will be INR 1,000.
The null tolerance group will be applicable for all the employees, and will be the default
tolerance group for all the company codes of BESTM, both in USA and India:
✓ For all the US-based company codes, this null tolerance group will enable posting of
accounting documents with values not exceeding USD 999,000 per document with a
limit of USD 99,000 per open item. The maximum cash discount allowed is 2% per line
item, and the maximum payment difference is 1%, with an amount cap of USD 50.
The cash discount adjustment limit has to be set at USD 5.
✓ In the case of India-based company codes, the null group enables posting of
accounting documents of value up to INR 1,500,000 per document with the line item
limit of INR 1,000,000. The maximum cash discount allowed will be 2% per line item,
with the maximum allowed payment difference of 1% with an amount cap of INR
1,000. The cash discount adjustment limit will be at INR 100.
BESTM wanted to know if they can go in for the summarization functionality of SAP. However,
the project team, after careful consideration of the current and future data volume for each
of the company codes, has advised the management that this functionality will be useful only
in the case of exceptionally large volume of data, as in the case of – for example – companies
operating in telecommunications, and not for BESTM entities.
BESTM wants to implement the following changes (Table 0.6) to the standard messages:
Message description
Amount is zero - line item will be
ignored
Check whether document has already
been entered under number & & &
Vendor is subject to withholding tax
Terms of payment changed; Check
Changes to be made for
Online processing Batch input processing
Warning (W)
Switch off message (-)
Warning (W)
Error (E)
Note in window (I)
Warning (W)
Switch off message (-)
Warning (W)
Table 0:6 BESTM – Standard Messages and Changes Required for BESTM
BESTM has requested to explore the possibility of using validation rules for preventing posting
of documents, based on certain pre-defined account assignment combinations. For example,
they have indicated that for the cost center 11101101 and G/L account 11001099
combination, the validation rule set in the system should reject the posting. Similar
Case Study
31
combinations are to be built in for various cost center-G/L account combinations, as decided
by the FI Manager of various company codes for BESTM. This is to prevent posting with
incorrect account assignment combinations.
To enable auditing and other purposes, BESTM corporate has decided that the documents /
accounts should not be archived until they cross a minimum life of 1000 days (about 3 years),
as it was felt that SAP’s default of 9,999 days may put pressure on system performance.
However, it was clarified, that even after archiving, the documents / accounts need to be
fetched faster from respective archives, at least, for another year (365 days).
The project management team has recommended to make use of standard correspondence
types supplied by SAP. Accordingly, it has been decided not to create any new correspondence
type except a few like SAP01, SAP06 and SAP08 which will be copied into new correspondence
types namely YB01, YB06 and YB08 for use in cross-company code correspondence, for
company codes 2100 and 2200. Also, the project team has recommended using standard print
programs associated with the correspondence types, in all the company codes of BESTM but
use different variants to meet individual company code’s reporting requirements. To make
use of ‘cross-company code correspondence’ functionality in respect of company codes 2100
and 2200, the company code 2100 needs to be designated as the ‘correspondence company
code’ that will manage the correspondence for company code 2200 as well.
The BESTM management has recommended to make use of the standard settings in SAP for
tax calculation and posting, for both India and USA. As regards USA, the team has planned to
take care of the jurisdiction requirement of taxation, by interfacing with the external tax
system, ‘Vertex’. The project team will properly structure the tax jurisdiction code
identification in the SAP system to make it fully compatible with Vertex. The project team,
accordingly, indicated that the tax on sales and purchases, for all the US-based company
codes, is to be calculated at the line item level. Any decision to tax a particular transaction has
to come from Vertex. As the tax calculation is from this external tax application, no user is
required to enter the tax amount in SAP system. If that is not the case, the system needs to
issue a warning, if the tax amount entered by the user is different from the amount calculated
automatically in Vertex. No new tax code will be defined by the project team. The posting
date will be the baseline date, for tax calculation. The tax amounts should be translated using
the exchange rate of the tax base amounts.
The BESTM management has requested the project team to complete the required
configurations settings for extended withholding tax (EWT) in the system. They have
requested the project team to make use of the standard (a) withholding tax keys, (b) reasons
for exemptions and (c) recipient types in the system for EWT. The project team, per
instructions from BESTM management, has decided to configure the message control to be
valid for all users; no separate configuration will be done for individual users. For online
32
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
transactions, the project team will configure message control in such a way to enable the
system to issue warning messages, yet allowing users to correct errors, if any. For batch input
processing, the project team will make use of standard message control settings of SAP, for
all the message numbers relevant for withholding tax processing.
The Dolphin project team has decided to define the following withholding tax types to support
invoice posting:
•
•
•
•
•
42: 1042 Compensation
FW: 1099 Federal Withholding Tax
IN: 1099 Independent Contractor Status
SW: 1099 State Withholding Tax
EW: Exempted from WT
BESTM has instructed the project team to make it possible to manually enter the withholding
base amount / tax amount, to provide some flexibility in transaction posting. However, these
fields should not be made as ‘required’ in the relevant field status settings, so as not to hold
up a transaction. The management also indicated that the minimum / maximum amount
settings to be done at the tax code level and not at the tax type level.
BESTM management has informed the project team to define the required withholding tax
types for payment postings relating to government payments (1099-G). Accordingly, the
project team has decided to define two withholding tax types for payment posting: GX 1099G reporting excluding WT and GN - 1099G reporting including WT. Besides, BESTM made
it clear to the project team that all the company codes will be using the exchange rate of
payment, when translating the withholding tax from foreign currency to a local currency.
BESTM has indicated to the project team to make use of standard default withholding tax
codes relating to 1099-MISC reporting. If any additional tax codes (to comply with 1099-G,
1099-INT etc) are required, BESTM suggested that the project team creates them in
accordance with the reporting requirements in USA, to cover both the federal and state
provisions.
The Dolphin project team has recommended to BESTM management to have separate G/L
accounts (from 21613000 to 21614000), differentiated by withholding tax types. However,
they also indicated that it may not be required to have these accounts separated according
to the tax codes for all the third-party transactions. It has also been recommended to have a
single account (21603000) for self-withholding tax. No explicit withholding tax certificate
numbering is required for withholding tax reporting in USA as the requirement is fulfilled
through TIN, EIN, and SSN numbers.
Case Study
33
The project team has been instructed by the BESTM management to configure only one
retained earnings account for each of the company codes. Accordingly, the G/L account
33000000 has been designated as the retained earnings account (in the chart of accounts
area) of the operative chart of accounts BEUS.
The project team has suggested to the BESTM management to make use of sample accounts
in creating some of the G/L account master records, to facilitate quicker and easier master
data creation. Accordingly, it has been agreed to use sample accounts, in all the company
codes, to create G/L account master records for bank accounts. The project team will create
the required data transfer rules. Two sample rule types (or sample rule variants) will be
created; one for the US-based company codes, and the other for Indian based company codes.
For the rule type for US-based company codes, following data transfer rules will be applicable:
✓ The FSG ‘YB32’ (bank accounts with obligatory value / due dates) set in the sample
account, will be transferred to the newly created G/L account but the users will not
be able to change the values in the newly created G/L accounts. So also, with the field
‘Valuation Group’. However, the fields ‘Exchange Rate Difference Key’, ‘Account
Currency’, ‘Sort Key’ and ‘House Bank’ will be configured in such a way that the nonblank value in the sample account will be transferred and can be overwritten, after
transfer to the new G/L account master record that is being created.
For the rule type for all the Indian-based company codes, the above data transfer rules will
also apply, except that the reconciliation account (‘Recon. Account for Account Type’) will be
transferred from the sample account which can be changed, if required, after the transfer.
BESTM wants the project team to have thorough validation of all the G/L accounts of the
chart of accounts BEUS, to ensure that (a) the accounts have been properly identified as B/S
or P&L type, (b) the correct functional area has been assigned to them and (c) the account
groups are correct for each of the accounts. Also, the short / long texts need to be properly
modified; for example: instead of ‘Bank1 Main Account’, it should be changed to ‘BoA Main
Account’. Bank 2 should be renamed as ‘Chase’, Bank 3 as ‘Citi’, Bank 4 as ‘PNC’ and so on.
BESTM requires a similar verification be done, in the company code area data as well, to
ensure that the accounts have been correctly identified for open item management, line item
display, balance in local currency etc.
BESTM wants to make use of document splitting functionality for all the company codes, both
in US and India. Accordingly, the project team has suggested the following, which was later
agreed upon with the BESTM management:
✓ The configuration will make use of SAP’s default and standard document splitting
method 0000000012; no new method will be defined. Also, no new item categories,
34
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
document types, business transactions, and business transaction types will be defined
as the project feels that the standard offerings from SAP will be enough to meet all
the document splitting requirements of BESTM company codes. The ‘Business Area’,
‘Profit Center’ and the ‘Segment’ will be used as the document splitting
characteristics, with a zero-balance setting. Additionally, the team will make
appropriate settings for ‘Segment’, as BESTM requires a complete balance sheet, per
segment, for which inaccuracies due to non-assigned postings cannot be tolerated.
The characteristics ‘Order’, ‘Cost Center’ and ‘WBS Element’ need to be used as the
document splitting characteristics for CO. The cash discount that is applied in the
payment of an asset-relevant invoice should be capitalized to the asset.
The BESTM Corporate wants to take care of cross-company code transactions as the company
code 1110 will be the central purchasing organization for all the company codes in US.
Besides, the company code 1120 will make sales of their products through company code
1110 which will act as the merchandiser. A similar scenario was envisaged for India-based
company codes, as well, with regard to the central purchasing by the company code 1210.
The Dolphin Project team has recommended, to the BESTM management, that there is no
need to define any new clearing procedures. They also recommended not to change any of
the default posting keys for these procedures, as tinkering with the standard posting keys may
result in system-wide unforeseen discrepancies.
The project team suggested using a single set of accounts, to take care of automatic posting
of the exchange rate differences realized in clearing open items: for loss it will be 72010000,
and for the gains it will be 72510000. For valuation adjustments, the loss will be posted to
72040000 and the gains to 72540000; B/S adjustments will go to the G/L account 11001099.
The Dolphin Project team has recommended not to go for any additional clearing grouping
criteria. The BESTM management, after some discussion with the project team, requested to
configure four more user-criteria for grouping clearing items for automatic clearing, for more
flexibility: ‘Assignment Number’, ‘Business Area’, ‘Trading Partner’ and ‘Contract Number’ for
customer and vendor, and ‘Segment’ (in the place of ‘Contract Number’) for G/L accounts.
The project team has suggested to configure two separate G/L accounts for posting of clearing
differences: G/L account 52080000 will be configured for debits and 52580000 for credits.
The project team has been advised by the BESTM management to configure three G/L
tolerance groups: a null tolerance group and two special tolerance groups:
a) The null tolerance group will be applicable for all employees, and will be the
default tolerance group for all the company codes of BESTM, both in USA and
India. This will have a tolerance of USD 1 (in absolute terms), with 0.5% as the
Case Study
35
limit for US-based company codes; the absolute limit will be INR 10 and the
percentage limit will be the same at 0.5%, for Indian company codes.
Besides the null tolerance group, there will be two more special tolerance groups defined in
the system: one for US-based company codes, and the other for India-based company codes:
b) BGLU: This will be for the selected employees of US-based company codes
allowing a tolerance of USD 10, in absolute terms, both for debit and credit
transactions; in percentage terms the limit will be 1%.
c) BGLI: This will be for the India-based company codes; the percentage will be the
same at 1%, but the absolute amount in INR will be 100.
In all the three tolerance groups, lower of the absolute amount or percentage will apply.
BESTM has decided to use two different interest indicators, besides the standard. The new
interest indicators will be used for calculating account balance interest on staff loan accounts;
one indicator for US-based company codes and the other for India-based company codes.
BESTM management wants the two new interest indicators with the details as under:
✓ The interest calculation frequency is to be set at six months for the staff loans, for
both India and USA. The Gregorian calendar needs to be used for interest calculations.
The interest settlement should be configured to be on the last day of the month. The
interest needs to be charged on a graduated scale for all the staff loan accounts, for
US-based company codes, at 2% interest up to $10,000; 3% up to $25,000; and 4% in
excess of $25,000; for India, the corresponding figures will be: 8% for loans up to INR
200,000, 9% up to INR 500,000 and 10.5% for above INR 500,000. The interest will
have to be settled when the interest amount calculated is in excess of $10 and INR
100, respectively for US and India-based company codes. The interest needs to be
paid within 10 days of interest posting to the respective accounts. The interest posting
is to be made to the appropriate G/L accounts, one for interest paid (71100000) and
another for interest received (70100000). The system should use the document type
SA for interest posting.
In addition to allowing negative postings in all the company codes of BESTM, the project team
has been asked to configure suitable ‘document reversal reasons’ in the system, to handle the
reversal transactions. It has been clarified to the team that:
•
•
If reversal is happening in the current period, then, the system should allow negative
posting; but, should not allow to change posting date (of the document to be
reversed).
If reversal is to happen in a closed period, then, following conditions should be met:
36
o
o
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Negative postings can be allowed, but without altering the posting date (of
the document to be reversed).
Negative postings cannot be allowed, but the posting date (of the document
to be reversed) can be altered.
BESTM Corporate wants to have single valuation method that will be used worldwide.
However, there needs to be different valuation areas to take care of the different valuation
needs and requirements of each of the accounting principles. Besides, the corporate also
wants to make use of the ‘delta logic’ functionality in foreign currency valuation to ensure
that the system does not execute any reversal postings, for the valuation postings in the
subsequent period. Besides the default account assignment fields for foreign currency
valuation, BESTM wants to include ‘Functional Area’ and ‘Cost Center’ as the additional
account assignments to have more flexibility.
BESTM management has indicated to the project team that they want to set up appropriate
adjustment accounts to post the results of P&L and B/S adjustments, so as to assign line items
to specific account assignment objects like ‘Business Area’, ‘Profit Center’ etc. This is to avoid
posting the adjustment line items to the original accounts.
In closing, for regrouping receivables and payables, BESM wants the configuration team to
stick to the SAP’s standard sort method. The team has been tasked to assign the suitable G/L
accounts as adjustment accounts for this default sort method.
The BESTM management has indicated that they want additional account assignments during
carryforward, in the case of B/S accounts, on ‘Order Number’ and ‘Account Type’, besides the
standard account assignments in the system. In the case of P&L accounts, BESTM does not
want to have any additional account assignments than that of the standard settings.
BESTM management has asked the Dolphin project manager to create a fairly large number
of account groups like sold-to-party (0001), goods recipient (0002), payer (0003), bill to party
(0004), one-time accounts OTA (0099) and consumer (0170). Besides, additional account
groups are to be created, to suitably number the customer accounts that are transferred from
the external system are also be created.
The project team has recommended to the BESTM management, to control the field status
through accounts groups, for both customers and vendors. Accordingly, no new screen layout
settings are to be defined for the company codes (of BESTM) or for transactions. As BESTM
wants its company codes to participate in ‘factoring’, the project team has decided to activate
A/R pledging for each of the company codes, both in USA and India. Also, the field ‘Accts
recble pledging ind.’ is to be set as an ‘optional’ field in the customer account group and the
company code (customers) screen layout.
Case Study
37
BESTM requested the project team create six number ranges from B1 to B5, and B9, for both
customers and vendors, with the specifications that B5 should be used for one-time accounts
(OTA) and B9 for external numbering to accommodate the customer / vendor accounts
transferred from the external systems.
BESTM wants the project team to manage ‘Payment Terms’, ‘Alternate Payer’ and ‘House
Bank’ as the sensitive fields. Accordingly, these fields need to be brought under dual control
to avoid any misuse.
BESTM management has indicated that they want to include additional fields like ‘Alternative
Payer’, ‘House Bank’, ‘Payment Terms’, ‘Reconciliation Account’, ‘Customer Classification’,
‘Payment Block’ and ‘Credit Control Area’ in logging the changes made by users while
changing the customer master records. However, they have indicated that they do not want
to exercise restricting the changes to these fields as such action for some of the fields
(‘Alternative Payer’, ‘House Bank’ and ‘Payment Terms’) are better handled by dual control of
sensitive fields.
The project team has recommended to the BESTM corporate to stick to the line item display
using the ABAP List View (ALV). Also, they have suggested not to define additional fields for
customer / vendor line item display, as that may result in performance issues. Besides, they
are also of the view that no additional settings would be required than the default ones, for
processing open items.
BESTM management has asked the Dolphin project manager to create elaborate account
groups like vendor (0001), goods supplier (0002), alternate payer (0003), invoice presented
by (0004), forwarding agent (0005), special vendor (0010) and one-time vendors (0099)
besides separate account groups to take care of vendor accounts that are transferred from
the external system.
BESTM wants to have a strict control of unauthorized changes to some of the important fields
in vendor master records. Accordingly, they wanted to bring ‘Alternative Payee’, ‘Payment
Block’, Bank Account’, ‘Account with Vendor’ and ‘Tolerance Group’ fields under dual control
by denoting them as ‘sensitive’ fields. Only the supervisor or manager, will have the required
authorization to confirm or reject the changes made to these sensitive fields.
BESTM management wants to include additional fields like ‘Alternative Payee’, ‘House Bank’,
‘Reconciliation Account’, ‘ABC Indicator’, ‘Payment Block’ and ‘Interest Indicator’ in logging
the changes made by users, while changing the vendor master records. However, they have
indicated that they do not want to exercise restricting the changes to these fields as such
action for some of the fields (‘Alternative Payee’, ‘House Bank’ etc) are better handled by dual
control. BESTM wants to go with default settings for parking document entry screens.
38
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
BESTM wants to have separate release approval groups, for customers / vendors, who have
been classified into A, B and C buckets, for parking documents. They want to include fields
like ‘House Bank’, ‘Tolerance Group’, ‘Payment Terms’, ‘Payment Method’, ‘Alternative Payer’
and ‘Payment Block’ to be checked by the system. If any changes are found for these fields,
then, the system should cancel the document release. For vendors, the fields will include
‘Alternate Payee’, ‘Interest Indicator’, ‘House Bank’ and ‘Payment Block’.
BESTM wants to have different set of payment terms for customers and vendors so that if
there is a change that needs to be done for either customer or vendor, then, that can be
carried out without affecting the other. However, there will a single payment term that will
apply for both customers and vendors when the due date is immediate.
•
•
•
•
•
For customers, the three payment terms will cover a credit period of 90 / 60 / 30 days:
1) BC90: 15 Days 3%, 45/2%, 90 Net (there will be a discount of 3% if paid within 15
days, 2% discount for payment within 45 days, and no discount beyond that).
2) BC60: 15 Days 3%, 30/2%, 60 Net.
3) BC30: 15 Days 4%, 30 Net.
Similar payment terms will be configured for vendors, but the key will be changed to
BV90, BV60 etc.
A common payment term B001 will also be configured for immediate payment
without any discount, and this can be used for both customers and vendors.
For instalment payments, BESTM wants the system to be configured with the
payment terms key, BINS. The number of instalments will be three, with the first
instalment at 20%, second at 30% and the third being 50%. All the instalments need
to be paid within a maximum of 30 days, with 4% discount for early birds but within
15days.
BESTM will be using default payment block reasons and will not require anything new.
BESTM wants to:
•
•
•
•
•
•
Have a single G/L account (70040000) to manage all cash discounts received.
Capture the difference between the originally calculated cash discount and the actual
cash discount received, and post that difference, as an expense (discount lost) to a
single G/L account (71040000).
Use G/L account 44000000 for accounting overpayments / underpayments.
Configure G/L accounts 72020000 and 72520000 for currency rounding off during
clearing.
Use G/L accounts 72010000 and 72510000, to handle to handle payment differences
(gain/ loss), when working with alternative currencies for payment.
Use G/L account 71000000 to take care of posting of vendor bank charges.
Case Study
•
39
Enable posting of translation gain/loss for clearing open items in foreign currency, in
all the company codes both US-based and India-based.
BESTM does not want to propose a default blocking key via payment terms, for postings
customer / vendor accounts.
BESTM wants to have two tolerance groups: a strict tolerance group (also known as ‘null
tolerance group’) that will be for most the vendors and a liberal one that will be applied to
specific vendors.
For all the US-based company codes:
•
•
The ‘null tolerance group’ which will be the default, when a vendor is not assigned
with a specific tolerance group. For this tolerance group, the permitted payment
difference will be $50 for gains (1%) and $10 for losses (0.5%), with a maximum
adjustment cash discount being $5. For automatic write-off of payment differences,
the amount and percent values will be $5 and 0.25% respectively, both for revenue
and expense.
For the specific tolerance group, which will be termed as BEU1, the corresponding
permitted payment difference is $500 for gains (2%) and $250 for losses (1%). The
maximum cash discount that can be adjusted, will be $50. The amount and
percentage values for automatic write-off of payment differences (revenue or
expense) will be $25 and 0.5% respectively.
For all the India-based company codes the tolerance amount, tolerance percentage, and the
cash discount amount that can be adjusted, the amount and percentage for automatic writeoff of payment differences will be the same as that of US company codes but the amount will
be in INR. The corresponding tolerance group will be termed as BEI1.
The project team has suggested to create new reason codes to cover situations like cash
discount period exceeded, cash discount rate not kept to, cash discount deducted for net
terms, discount period exceeded & rate incorrect, calculation error on customer side, debit
paid twice, credit memo paid instead of reduction, credit memo reduced twice etc.
BESTM has indicated that the company code 1110 will need to be configured in such a way
the it can carry out manual payments and other clearing procedures on behalf of company
code 1120. Similarly, the cross-company code manual payments need to be enabled for the
pair of company codes as shown in Table 0.7. Accordingly, the project team has decided to
configure the settings to cover the clearing procedures like incoming payment, outgoing
payment, credit memo and transfer posting with clearing.
40
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Paying Company Code
2100
3100
1210
Payments for
2200
3200
1220
Table 0:7 Cross-Company Code Pairing for Manual Payments
BESTM suggested to the project team to configure ‘create manual payment’ application to
cover both the scenarios of ‘direct payment without an invoice’ and ‘payment of vendor open
line items’, with the system posting both the payment and document.
All the company codes in USA will have their primary accounts with Bank of America (BOFA),
Citi Bank (CITIU) and Chase Manhattan (CHASU) and they will accordingly be designated as
the house banks. In India, the company codes will have accounts with State Bank of India
(SBIIN), HDFC bank (HDFCI) and ICICI bank (ICICI). Each bank account, within a house bank,
will be assigned to a G/L account and there can be multiple bank accounts in a single house
bank. BESTM has indicated to the project team to differentiate foreign currency account
numbers by using a separate G/L account, per currency for bill discounting.
BESTM wants to designate the company code 1110 as the paying company code for
themselves, and also for 1120. Similarly, company code 2100 will be the paying company code
for 2200, and 3100 will be the paying company code for 3200. Similar arrangements will be
made for India based company codes as well wherein the company code 1210 will pay for
1220. BESTM Corporate wants to continue with their existing practice of making payments to
their vendors, six days after the invoices are due. BESTM has requested the project team to
configure the payment program to enable payments per ‘Business Area’, but the project team
suggested not to do that, instead suggested grouping of payments in the normal way by
‘Currency’, ‘Payment Method’, ‘House Bank’ etc, so as to have more flexibility; BESTM, after
a long deliberation, has accepted to this idea and does not, now, require payment grouping
per ‘Business Area’. However, BESTM has requested that payment should cover the special
G/L transactions like downpayments (including down payment requests), security deposits,
guarantee etc, for both customers and vendors. Additionally, BESTM wants to ensure that
maximum cash discount is always taken, when paying vendor invoices automatically.
BESTM wants to avoid large numbers of small payments. Accordingly, they need the system
to be configured in such a way, that there will not be any automatic payment processing,
including the debit memos, if the payment amount < $25 for all the US-based company codes
and < INR 500 for company codes 1210 and 1220, for all incoming and outgoing payments. In
all, wherein the payments proposed are less than the minimum, the system will accumulate
them till the limit is crossed, and then pay as in the normal course. In case of bill of exchange
(BoE) payments, BESTM wants the system to be configured to create one BoE per invoice.
Case Study
41
BESTM wants does not want to define any new payment method. Instead, they have indicated
that, they will go ahead using the default payment methods that have been configured in the
standard system, for both USA and India.
As regards payments through automatic payment program, BESTM wants to have the system
configured to reflect the following:
•
•
•
•
All the line items that are due on a particular date, should be grouped and paid in a
single payment. If line items are associated with a payment method explicitly, then,
the system should pay those items; else, if the payment method is not specified
explicitly in the line item, and if the system selects the payment method
automatically, then, several items can be paid together. The ‘extended individual
payment’ should be activated to make it possible to include and offset all available
credit memos for a payment group. For payment methods like bank transfer, the
system should make payments abroad, using the business partners’ banks in their
respective countries. The system should be able to make payments - for all payment
methods - in other currencies, other than the company code currency. BESTM wants
bank optimization using their own house banks and business partners’ banks so as to
optimize international payments.
As regards payments, if the payment method is check, then, all in-country payments
should not be less than $25 (for US-based company codes) and INR 500 for Indian
company codes. If the payment is more than $5,000 (or INR 250,000) then, it has to
be made through bank transfer or direct debit. For direct debit, bank transfer or card
payment, there is no lower limit for payment. In cases of composite payments, BESTM
wants the system to split the payment by grouping the invoices, with the appropriate
credit memos, for payments exceeding $10,000 in the case of US-based company
codes (or INR 500,000 for all the India-based company codes), for all the allowed
payment methods, for both domestic and international payments.
The BESTM Corporate has indicated to the project team that Bank of America will be
the primary bank for all the payment methods, followed by Chase Manhattan and Citi
Bank, in that ranking order. It has been envisaged to provide an amount limit of
$9,999,999,999 for Bank of America for facilitating automatic payment transactions
(outgoing payments). The limit for the other two banks would be $999,999,999, in
each case. In the case of incoming payments, there should not be any limit restriction.
The value date should be 1 day after, for all the payments through electronic format;
however, it would be 3 days after, for all the checks denominated in local currency.
For house banks in India, the limits will be the same but denominated in INR.
The project team has suggested not to go in for any additional search fields for
payments (and line item display) as the standard fields are sufficient to be used as the
42
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
criteria for maintaining proposal run, besides displaying the payment proposal /
payment run.
BESTM wants to configure the system to take care of payment through payment cards as well.
In the process, it has been outlined, that the system needs to be configured to retain the
customer line items in FI department, during transfer of payment card data from SD
department. This decision has been taken, consciously, after several deliberations knowing
fully well that this will call for more database space; BESTM is ok with this, as the configuration
will provide (a) the advantage of displaying the receivables on the debit side and (b) the ability
to the department personnel to deal with any settlement problems of the payment cards.
The Dolphin project team has suggested to configure six dunning block reasons in the system:
disputed (A), promised to pay (B), clarification required from SD side (C), blocked by legal
department (D), other reasons (E) and blocked by invoice verification (R).
The project team has suggested to copy and adapt the SAPScript forms provided by SAP to
meet dunning needs of BESTM group of company codes. Accordingly, there will be five forms
that will be created anew by copying the standard ones: the form F150_BE_DUNN_01
(without interest) will be copied as ZF150_BE_DUNN_01 and will be used both for the singlelevel dunning procedure and also for the first dunning level of the 5-level dunning procedure.
The standard form F150_BE_DUNN_02 (with interest) will be copied to create the other four
levels for the 5-level procedure. Also, separate spool lists will be created by copying the
standard LIST1S spool list, and five new spool lists will be created, prefixed with the company
code name like 1110-1, 1110-2 etc.
The BESTM management has decided to have two dunning procedures, in each of the
countries (USA and India) where the company is operating:
1. A dunning procedure that will be used to remind the VIP business partners, which will
be single level dunning procedure. This will just be a ‘payment reminder’ and there
will not be any charges / interest associated with this dunning.
2. The multi-level dunning procedure will be used for all other business partners. This
will have a maximum of 5 dunning levels, with a dunning interval of 7 days. There
needs to be a cushion of three days for dunning levels 2 and 3, and five days for levels
4 and 5. Also, there will be a grace period of five days at the account level. Further, if
the due date falls on a holiday, the dunning program should take the next working
day as payment due date based on respective country’s public calendar. The dunning
charges, for the multi-level dunning procedure, will be as in the Table 0.8:
Case Study
Amount Range
Up to $5,000
$5,001 – $10,000
$10,001 - $25,000
$25,001 - $50,000
$50,001 - $100,000
Above $100,000
Dunning
Level 1
Dunning
Charges
Dunning
Level 2
Dunning
Charges
0
0
0
0
0
0
$5
$10
$10
$15
$20
$50
Dunning
Level 3
Dunning
Charges
(%)
0.10
0.15
0.20
0.25
0.30
0.35
43
Dunning
Level 4
Dunning
Charges
(%)
0.15
0.20
0.25
0.30
0.35
0.40
Dunning
Level 5
Dunning
Charges
(%)
0.20
0.25
0.30
0.35
0.40
0.50
Table 0:8 Dunning Charges for BESTM for US-based Company Codes
Besides the above charges, there will be an overdue interest charges, to be charged
on the arrears, at the prevailing rates subject to a minimum of $50 for level 2, $100
for level 3, $250 for level 4 and $500 for level 5. Of course, there will be no interest
on arrears for the level 1. The level 5 will be considered as legal dunning level and will
use legal wording on the dunning notice; a separate legal dunning notice format will
be used. BESTM wants the system to consider the interest indicator in the master
record of a business partner, and not through the dunning procedure.
The charges and interest amount will be the same for India-based company codes as
well, except that the amounts will be in INR.
When printing the dunning notice, the program should display the entire account balance,
and should include all the open items, even if the dunning level is at the lowest. BESTM does
not want to include any of the Special G/L items in the dunning list. Each company code will
dun their business partners separately. However, they can group the overdues of a customer
across other company codes.
BESTM has suggested to the project team to configure the item interest calculation in such a
way that (a) the system should calculate the interest as and when it becomes due, but on the
due date for net payment, (b) the value date should be the baseline date for net payment, (c)
there would be a grace period of 5 days for payment without interest, after the receivable
payments become due, (d) the system should calculate interest both on debit and credit
items, using the respective interest rates and (e) there should not be any interest calculated
on items that have been paid before the due date. In case of interest settlement, it has been
directed that there should not be any interest settlement, if the interest amount is less than
$10 for all US-based company codes, and INR 100 for India-based company codes. It was also
suggested that the interest receivables should be created and posted with reference to the
invoice for which interest was calculated.
44
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Note that this is not a complete case study, but relates to the portions that are required
for configuring SAP Accounts Receivable and Accounts Payable. Also, there are portions
relating to FI enterprise structure, FI global settings and company code global parameters,
that are included in this Chapter, to provide the necessary background for the discussion. For
the full case study of Project Dolphin, you may refer to the other book ‘Configuring SAP
Financial
Accounting
–
Vol.
II:
SAP
S/4HANA
Finance’
(https://www.amazon.com/dp/B08CXPWH4B) that is available both as Amazon Paperback
and Kindle editions.
1 Accounts Receivable and
Accounts Payable
F
ully integrated with the SAP General Ledger Accounting (SAP G/L), the accounts
receivable (FI-A/R) and accounts payable (FI-A/P) components of SAP help in dealing
with your customers and vendors, respectively, for managing the amounts that your
business would receive from (customers) and pay to (vendors). Besides SAP G/L, these
modules are also integrated with SAP-SD, SAP-MM and FI-AA. These components help in
managing the master data (of customers and vendors) and the various business transactions
associated with the receivable and payable.
Allowing you to record and manage accounts receivable data of all customers, the ‘Accounts
Receivable’(FI-A/R) component, takes care of all postings to A/R that are triggered in response
to operative transactions in sales and logistics, besides updating the FI-G/L simultaneously. It
updates different G/L accounts such as receivables, down payments, bills of exchange etc.,
depending on the transaction involved. It also clears customer line items with the incoming
payments. With the functionality, you (a) can monitor open items by using, for example, due
date lists and a flexible dunning function, (b) can adjust the correspondence forms, payment
notices, balance confirmations, account statements, interest calculations etc., to suit your
requirements, and (c) can assign incoming payments to receivables due. With its wide range
of tools, you can evaluate balance lists, journals, balance audit trails and other standard
reports.
The key features of FI-A/R are outlined in Table 1.1:
Key Feature
Master data
Monitoring of receivables
Posting business
transactions
Details
You can manage and store your customer data as
business partner data. You can create and change
customer data using the business partner, so that you do
changes, for example, in address data, only once.
Besides displaying overdue receivables and customer
balances, you can process individual customer items.
You can post accounting data for customers in A/R and
the data entered is transferred to G/L which is updated
46
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Clearing of open invoices
Evaluation of
days receivable outstanding
(DSO)
Correspondence
Periodic activities and
closing operations
Analytics
according to the transaction concerned like, receivable,
down payment, bill of exchange (BoE) etc.
You can post incoming payments and clear customer
open items either manually or automatically.
You can use this functionality to identify customers with
the highest or the lowest days receivable outstanding
(DSO).
Besides sending correspondence (such as payment
notices, open item lists, balance confirmation or account
statements) to your customers, you can adjust the forms
for the correspondence according to your business
needs.
You can prepare and carry out periodic activities (such as
automatic payment, interest calculation or dunning) or
activities that arise for closing.
You can carry out evaluations and analyses for your
customers, such as payment history, currency risk or
DSO analysis.
Table 1:1 Key Features of FI-A/R
Integrated with SAP-MM, the ‘Accounts Payable’ (FI-A/P) application component records and
manages accounting data for all your vendors. As in the case of A/R, all postings made in A/P
are also simultaneously recorded in FI-G/L with different G/L accounts recording different
business transactions like payables, down payments, BoE etc. Interacting with SAP Cash
Management application (a subcomponent of SAP Financial Supply Chain Management), A/P
helps in updating the data from invoices for optimized liquidity planning. With its payment
program, you can pay all your payables either through standard payment methods (check,
wire transfer etc) using regular printed forms or through electronic form (by way of DMEdata medium exchange on disk and EDI- electronic data interchange). As in the case of A/R,
you can create dunning notices, if required, for outstanding receivables (for example, to
receive payment for a credit memo). You may use due date forecasts and other standard
reports to monitor the A/P open items. Using the functionality, you can also design balance
confirmations, account statements, and other forms of reports to suit your specific business
requirements in corresponding with you vendors. You can document the transactions in A/P,
using balance lists, journals, balance audit trails, and other internal evaluations.
Accounts Receivable and Accounts Payable
47
The key functionalities of FI-A/P are outlined in Table 1.2:
Key Feature
Master data
Posting business
transactions
Import of supplier invoices
Analysis of payments to
suppliers
Management of cash
discounts
Reviewing of cleared
overdue invoices
Evaluation of
days payable outstanding
(DPO)
Management of payments
Management of payment
blocks
Management of payment
proposals
Management of payment
media
Table 1:2 Key Features of FI-A/P
Details
You can manage and store your vendor data as business
partner data. You can create and change vendor data
using the business partner, so that you do changes (as in
A/R), for example, in address data, only once.
You can post accounting data for vendors in A/P and the
data entered is transferred to G/L which is updated
according to the transaction concerned like, payable,
down payment, bill of exchange etc.
You can import multiple supplier invoices all at once.
Besides viewing the information about payments to
suppliers, you can check the overdue / future
payable amount. If you identify negative trends in
the payable amount, you can notify the responsible
persons to take action.
You can use this feature to forecast the available cash
discounts and to monitor the cash discount utilization in
your responsible area. You can find out where you need
to make better use of cash discounts in order to avoid
cash discount loss in the future.
Use this feature to get details and statistical facts about
cleared overdue invoices.
This is similar to DSO functionality of A/R. You can use
this functionality to identify suppliers with the highest or
the lowest DPO.
Use this feature to create, post, and, if necessary, reverse
payments.
You can use this feature to set and remove payment
blocks on invoices or supplier accounts. You can identify
irregularities or potential fraud in invoices through
integration with SAP Fraud Management for SAP
S/4HANA.
You use this feature to revise and release payment
proposals. The system creates journal entries in FI.
You use this feature to transfer the data required for
electronic payment transactions to banks via a data
medium per successful payment run.
48
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
To be co-deployed with SAP S/4HANA, ‘SAP Fraud Management for SAP S/4HANA’ is not
part of SAP S/4HANA Enterprise Management, but part of the add-on ‘SAP Assurance and
Compliance Software’ for SAP S/4HANA, for which you need a separate license.
In this Chapter, we will discuss:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Customer Accounts
Vendor Accounts
Incoming Invoices/Credit Memos
Release for Payment
Outgoing Payments
Outgoing Invoices/Credit Memos
Incoming Payments
Payments with Payment Cards
Dunning
Open Item Clearing
Down Payment Received
Down Payment Made
Adjustment Posting/Reversal
Interest Calculation
Closing
Information System
Apps for FI-A/R & A/P
This completes our discussion on the overview of a SAP Accounts Receivable and Accounts
Payable.
1.1 Conclusion
In this Chapter, you saw on overview of SAP Accounts Receivable (FI-A/R) and Accounts
Payable (FI-A/P) modules. You understood that, fully integrated with the SAP General Ledger
Accounting (SAP G/L), the FI-A/R and FI-A/P components help in dealing with your customers
and vendors for managing the amounts that your business would receive from (customers)
and pay to (vendors). Besides SAP G/L, you understood that these modules are also integrated
with SAP-SD, SAP-MM and FI-AA.
Let us start with the customer accounts, first, in the next Chapter.
2 Customer Accounts
U
nder customer accounts, we shall discuss the configuration settings relating to master
data, line items and balances. Let us, first, understand the settings and the
preparations that are required, before you can create a customer master data.
2.1 Master Data
As all transactions in SAP are posted to and managed in accounts. You need to create one
master record for each customer account that you require in the system. Both the financial
accounting (FI-A/R) and the sales (SAP SD) departments of your organization use the same
master records. By creating and storing customer master data centrally, you enable their
access throughout the organization, and this avoids (a) the need to enter the same
information more than once and (b) the inconsistencies in master data that may creep in if
not maintained centrally. If the address of one of your customers changes, for example, you
have to enter this change only once; your accounting and sales departments will always have
the updated details.
You should have implemented the SAP Sales and Distribution (SAP SD) application
component in order to enter / process customer master records for processing the sales
related business transactions.
A customer can be a person (individual), an organization or a group. A typical customer master
data is made up of four areas (segments) as shown in Figure 2.1:
•
•
•
•
General Data
Company Code Data (FI area)
Sales and Distribution Data (SD area)
ETM Data
The ‘general data’ such as the information relating to address, control data, payment
transactions, status etc., will be at the Client level and hence is valid across all the company
codes. The ‘company code data’ (account management, payment transactions, insurance,
correspondence etc) is valid only for the specific company code in which the customer has
been created. The ‘sales and distribution data’ is made up of information relating to sales area
(sales organization, distribution channel and division), shipping, orders, billing, customer
texts, billing partner functions, documents, additional data etc., and will be valid across sales
areas. The ‘ETM data’ contains the industry specific equipment and tools data for customers.
50
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.1 Customer Master Data Areas
The ETM (Equipment and Tools Management) data is used, basically, in engineering and
construction industry, and it deals with optimal process flow in enterprise areas of
(construction) companies or equipment rental companies etc., for planning, processing,
settlement and evaluation of resources (materials and equipment). To use ETM, you should
have implemented the SAP application components like Sales and Distribution (SD), Plant
Maintenance (PM), Financial Accounting (FI) and Controlling (CO). It is also advisable to use
the other SAP application components like Asset Accounting (AA) and Project System (PS).
The specifications that you make in a customer master record are used (a) as default values
when you post items to the account (for example, the terms of payment you specify in the
master record are defaulted for document entry), (b) for processing business transactions like
dunning for which the date of the last dunning notice and the address are required for the
automatic dunning process, (c) for working with master records so as to, for example, prevent
unauthorized users (through appropriate authorization groups) from accessing an account,
(d) for communication with the customer using the address details and (e) in the sales
department for order processing, shipping, and billing.
Customer Accounts
51
You can create customer master data, in SAP, in three different ways:
•
•
•
Central maintenance (for all the three areas)
FI maintenance (for FI area alone)
Sales data maintenance (for SD area alone)
The Table 2.1 outlines the menu path and Transaction for creating / changing / displaying
customer master records from different maintenance areas (FI, SD and central). All these
Transactions are now bundled into a single Transaction known as BP. However, if you still
enter any of the earlier Transactions like FD01 / FD02 / FD03 or VD01 / VD02 / VD03 or XD01
/ XD02 / XD03 to create / change / display customer master in FI area, SD area and centrally,
the system redirects you to the new Transaction BP, automatically.
Maintenance
Area
Accounting
(FI)
Area Menu
FDMN
Activity
SAP Easy Access Menu
Create
Customer
(Accounting)
Change
Customer
(Accounting)
Display
Customer
(Accounting)
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Create
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Change
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Display
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Create > Sales and
Distribution
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Change > Sales and
Distribution
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Display > Sales and
Distribution
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Maintain Centrally >
Create
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Create > Complete
Create
Customer
(Sales)
Sales (SD)
Area Menu
VS00
Change
Customer
(Sales)
Display
Customer
(Sales)
Centrally
Create
Customer
(Centrally)
Transaction
BP (earlier
FD01)
BP (earlier
FD02)
BP (earlier
FD03)
BP (earlier
VD01)
BP (earlier
VD02)
BP (earlier
VD03)
BP (earlier
XD01)
52
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Change
Customer
(Centrally)
Display
Customer
(Centrally)
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Maintain Centrally >
Change
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Change >
Complete
SAP Menu > Accounting > Financial
Accounting > Accounts Receivable >
Master Records > Maintain Centrally >
Display
SAP Menu > Logistics > Sales and
Distribution > Master Data > Business
Partner > Customer > Display > Complete
BP (earlier
XD02)
BP (earlier
XD03)
Table 2:1 Customer Master Maintenance
In some companies, the accounting (FI) and sales (SD) departments maintain the general
data together and their own FI and Sales areas separately. In other companies, customer
master records are maintained centrally (for all the areas).
2.1.1 Preparations for Creating Customer Master Data
There are certain pre-requisites - like defining number ranges, creating customer account
groups and maintaining field status - which you need to complete before you create master
data for your customers:
•
Define Number Ranges: As in G/L account master records, you need to have
appropriate number ranges defined for the customer master records for the system
to allocate a suitable number from a number range when creating a master record.
In doing so, you also determine if the numbers are to be assigned internally by the
system or to be supplied by the user who is creating the master record.
Pay attention in doing this exercise by taking into account the current number
of existing customers and the expected increase of new customers in future, and
define the number range intervals accordingly, so that you do not run out of numbers
midcourse.
•
Create Account Groups: You are already aware that an account group is used to
control the creation of master records as it determines which fields have to be filled
compulsorily (mandatory) and which ones can be optionally filled when creating the
master record, besides allocating a number (external or internal) to the master
Customer Accounts
53
record. You normally create the master records using the same account group, if the
accounts require the same master record fields and use the same number range. You
will be creating customer master records, by entering the account group in the initial
screen. In FI, once a customer account is created, its account group cannot be
changed. However, when using partner functions in SD, in some cases, the account
group of a customer can be changed from, say, ‘ship-to address’ to an ‘ordering
address’.
The number of account groups which you need depends on whether you use
these groups for the layout of the screens. For example, you may want two account
groups: one group for ‘standard accounts’ and another for ‘one-time accounts’. The
other consideration should be the number ranges. The number of ‘number ranges’
will give you an initial clue as to the number of account groups. If you have
determined that you require five number ranges, for example, then, you must create
at least five account groups. There should at least be one account group in the system.
•
Maintain Field Status: You are aware that the field status definitions determine the
status of the fields on the screens for the master data. Though by default all the fields
would be ‘suppressed’, the field status can be (a) optional - field visible, enabled for
input but entry not mandatory, (b) required - field visible, enabled for input, entry
mandatory and (c) suppressed - field invisible, hidden from display, no entry is
possible. The field status is normally determined based on the account group.
However, you may also determine the field status depending upon the processing
type (transaction) with which you create the master record, and based on the
company code in which you define the master record. It is also possible to vary the
field status based on a posting key for a transaction. If there is a conflicting situation
to arrive at the final field status, you already know that SAP follows the ‘link rules’ to
overcome the situation.
Let us start with the first activity of defining the account groups.
2.1.1.1 Define Account Groups with Screen Layout (Customers)
Use this step to create the accounts groups that you will require for creating the master
records of your customers. While defining the account groups, specify - per account group the number range interval for the account numbers, the type of number assignment (external
or internal), whether it is a one-time account and the field status. You can also define
‘reference account groups’ for one-time accounts, and use them to control the field status of
the one-time account screen. When creating a one-time customer account, specify an account
group: if not, all fields of the one-time account screen are ready for input during document
entry.
54
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
If you create new account groups, do not forget to maintain the field status; else, all
corresponding fields are shown. Always control the field status via the account groups;
however, in exceptional cases, you may control the field status either via company code (refer
Section 2.1.1.2) or transaction (refer Section 2.1.1.3).
As in the case of G/L account groups, (a) you can delete an account group, from the system,
only if there are no master records referencing that account group; else, you cannot display
or change the master record; (b) if you hide a field at a later stage in which you had already
made an entry, the field contents are still valid; and (c) you can increase the upper limit of the
number interval as long as there is no other overlapping interval.
Do not attempt to allocate the accounts to accounting clerks via the account groups or
group customers together according to countries. Do this via special master record fields.
You can have several customer account groups like sold-to-party (0001), goods recipient
(0002), payer (0003), bill to party (0004), one-time accounts OTA (0099), consumer (0170)
and so on or create fewer number of account groups like domestic customers, export
customers, one-time customers etc.
Project Dolphin
BESTM management has asked the Dolphin project manager to create a fairly large number
of account groups like sold-to-party (0001), goods recipient (0002), payer (0003), bill to party
(0004), one-time accounts OTA (0099) and consumer (0170). Besides, additional account
groups are to be created, to suitably number the customer accounts that are transferred from
the external system.
The project team has recommended to the BESTM management, to control the field status
through accounts groups. Accordingly, no new screen layout settings are to be defined for the
company codes (of BESTM) or for transactions. However, as BESTM wants its company codes
to participate in ‘Factoring’, necessary field status needs to be configured: the field ‘Accts
recble pledging ind.’ is to be set as an ‘optional’ field in the customer account group and the
company code (customers) screen layout.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Account Groups with Screen Layout
(Customers), to create new account groups. You may also use Transaction OBD2:
Customer Accounts
i.
55
On the resulting screen, click on ‘New Entries’ to create a new account group (Figure
2.2), and enter a 4-character identifier for the new ‘Account Group’, say 001B.
Figure 2.2 Customer Account Group - New
ii.
Under ‘General Data’, enter an explanation for the group in the ‘Meaning’ field, select
‘One-Time Account’ check-box if the account group is for creating one-time accounts,
and enter a suitable output determination procedure (DB0001, DB0002 etc), if
required, in ‘Output determ.proc.’ field.
The ‘Output determ.proc.’ field defines the output categories (for example,
order confirmation and electronic mail message) that are allowed in a document, and
the sequence in which the output categories appear in the document.
iii.
iv.
Now, to manage the field status, place the cursor on ‘General data’, or Company code
data’ or ‘Sales data’ under ‘Field status’ block and click on ‘Expand Field Status’. For
example, as we need to ensure that the accounts receivable pledging indicator (‘Accts
recble pledging ind.’) field is configured with ‘optional entry’ field status, for BESTM,
double-click on ‘Company Code Data’ under ‘Field Status’ on the initial screen,
double-click on ‘Payment transactions’ group on the next screen and ensure that the
radio-button for ‘Accts recble pledging ind.’ is selected under ‘Opt. entry’ field status
column (Figure 2.3).
You can, similarly, maintain any other field statuses, as required.
56
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.3 Making AR Pledging Indicator Field as Optional
v.
Once done, ‘Save’ the settings, and create/change other account groups, accordingly.
Now you have created the required account groups (Figure 2.4) with the required
field status, for BESTM.
Figure 2.4 Customer Account Groups for BESTM
Customer Accounts
57
Let us move on to the next step of defining the screen layout per company code, for customer
accounts.
2.1.1.2 Define Screen Layout per Company Code (Customers)
As already stated, you should try to control, as for as possible, the field status via the account
groups. However, in exceptional cases, you may define company-code specific field status, for
example, if the company codes are in different countries or some company codes do not use
automatic payment processing for customers.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Screen Layout per Company Code
(Customers), to define the necessary settings if fields are to have an alternative status
depending on the company code. Once you are into the Transaction, specify the company
code and determine the status of the fields as required. In the process, you can determine,
depending on the company code, which company code-dependent master record fields (a)
are ready for input, (b) require an entry and (c) are hidden. This specification is linked (via ‘link
rules’) to the field status of the account group and a specification for the transaction. By the
linkage, you can see which status the fields have on the entry screen for master data: the
fields take on the status which has the highest priority: ‘hiding’ a field has the highest priority,
followed by ‘display’, ‘required’ and ‘optional’ in that order.
In the standard system, you will see default settings that are valid for all the company codes
as denoted by ‘*’ in the ‘Company Code’ field (Figure 2.5). You may create new settings by
clicking on ‘New Entries’ for specific company codes, or use the default settings as such or
with some modifications. As we need to ensure that the ‘Accts recble pledging ind.’ field is
managed as ‘optional entry’ for all the company codes of BESTM, double-click on the
‘Company Code’ row with ‘*’, double-click on ‘Payment transactions’ on the next screen and
ensure that this field is set to the ‘optional entry’ field status.
Figure 2.5 Defining Screen Layout per Company Code
Since all the company codes of BESTM needs to participate in factoring, you need to make
sure that the field ‘Accts recble pledging ind.’ is set to ‘optional entry’ field status.
Let us, now, see how to configure the field status settings per activity (transaction).
58
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
2.1.1.3 Define Screen Layout per Activity (Customers)
Here, you determine, depending on the transactions (display, create or change) for customer
master data, which master record fields are ready for input, require an entry and are hidden.
As discussed previously, these specifications will be linked with the field status of the account
group and the company code-dependent specification; the ‘link rule’ will determine which
final status the fields have on the entry screen for master data. Again, try to control the field
status via the account groups though you can define the field status for each transaction, in
exceptional cases.
If fields are to have an alternative status depending on the transaction, you can determine
the status of the fields for the required transaction using the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Customer Accounts > Master Data > Preparations for Creating Customer Master Data > Define
Screen Layout per Activity (Customers):
i.
On the resulting screen, you will see the listing of various transactions like create
customer (accounting), change customer (accounting), delete customer (accounting),
create customer (sales), create customer (centrally) and so on (Figure 2.6).
Figure 2.6 Defining Screen Layout per Transaction
ii.
Double-click on the required transaction, and change the field status to suit your
requirements on the next ‘Change View “Customer Activity-Dependent Field
Selection”: Details’ screen. For example, you may want to make ‘Reconciliation
account’ field with the status as ‘required’ from ‘optional’. ‘Save’ when completed
and continue modifying the field status for other transactions, as required.
With this, we are now ready to look at configuring the settings for message control.
Customer Accounts
59
2.1.1.4 Change Message Control for Customer Master Data
Using this configuration step, you can (a) determine whether a message is issued as a note in
the dialog box or in the footer, (b) change warnings into error messages and (c) switch off
warnings and error messages. You can maintain different specifications for online mode and
background processing (batch input sessions). You can, further, make the corresponding
specifications for a client or, if required, also for the individual user. SAP uses the work area
F2 for switching on the duplicate check for customer (or vendor) master records: the system
checks, using ‘matchcode’ fields, whether accounts with the same address already exist when
creating a new account or changing the address. If the same data is found, then, the system
displays the duplicates in a window. You may use the default settings (Figure 2.7) as such or
change the settings using the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data
> Preparations for Creating Customer Master Data > Change Message Control for Customer
Master Data.
Figure 2.7 Message Control Settings
You may use the enhancement SAPMF02D to copy and create your own: by modifying
the source code for a standard SAP transaction, and adding the elements you need, for
checking the data entered, before saving.
The next activity is to define the accounting clerks.
2.1.1.5 Define Accounting Clerks
You can define the name of the accounting clerks under an identification code which you can
later enter in the customer master records (Figure 2.8) - under ’Correspondence’ block in the
‘Customer: Correspondence’ tab - that the accounting clerk supervises. The accounting clerk
data can be printed on various forms (like payment forms, dunning notices, correspondence,
interest calculation etc), and you can use this information for evaluations and correspondence
as well.
60
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.8 Accounting Clerk Field in Customer Master
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Accounting Clerks or Transaction
OB05. On the resulting screen, maintain the company code (‘CoCd’), enter the identification
code of the clerk in ‘Clerk’ field, enter the name in ‘Name of Accounting Clerk’ and provide
the corresponding ‘Office User’ details (Figure 2.9).
Figure 2.9 Accounting Clerk Definition
The accounting clerk data is taken from the corresponding office user, from the structure
FSABE. You therefore need to maintain the address data of the office user.
The next step is to define the industries.
2.1.1.6 Define Industries
Using this activity, you can define industries (also known as ‘industry sector’) by a ‘industry
key’, and, later, you can group your customers together by industry, and use that information
for evaluations; for example, to create a customer list according to industry.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Industries. You may also use
Transaction OB44. On the resulting screen, click on ‘New Entries’ and maintain the required
details on the next screen (Figure 2.10). You can also access this Transaction, on the SD side,
using the menu path: SAP Customizing Implementation Guide > Sales and Distribution >
Master Data > Business Partners > Customers > Marketing > Define Industry Sector For
Customers.
Customer Accounts
61
Figure 2.10 Defining Industries
The Standard Industrial Classification (SIC) include four-digit codes categorizing the
industries that companies belong to, while organizing the industries by their business
activities. The SIC codes were created by the U.S. government in 1937 to help analyze
economic activity across various industries and government agencies. However, SIC codes
were partly replaced in 1997 by a system of six-digit codes called the North American Industry
Classification System (NAICS). The NAICS codes were adopted, in part, to standardize industry
data collection and analysis in between Canada, the United States, and Mexico, under the
North American Free Trade Agreement. Despite having been replaced, the government
agencies and companies still use the SIC codes even now, for classifying the industry that
companies belong to, by matching their business activity with similar companies.
Depending on the standards your organization uses (for example, SIC), you can configure SIC
codes in SAP using the menu path: SAP Customizing Implementation Guide > Sales and
Distribution > Master Data > Business Partners > Customers > Marketing > Define Industry
Sector Codes. Once done, you may enter the appropriate code in the customer master record
(Customer: General Data). You can assign more than one industry code to a customer (Figure
2.11).
Figure 2.11 Assigning Industry Code in Customer Master Record
With this, we can, now, move on to define the number ranges for the customer accounts.
62
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
2.1.1.7 Create Number Ranges for Customer Accounts
As in the case of G/L account master records, you also need to maintain the required number
ranges for the customer master records that you will be creating in the system. Define as
many number ranges that you may require and specify whether a range is external or internal.
Make sure you provide sufficient interval, in each of the number ranges, so as not to run out
of numbers in the middle.
Except for the customer master records that you will be transferring from the external
system(s) for which you specify external number ranges, go ahead with the internal
numbering for all other number ranges. You may not need several number ranges to exactly
match the number of account groups, as you can use the same number range for more than
one account group.
Project Dolphin
BESTM requested the project team create six number ranges from B1 to B5, and B9 with the
specifications that B5 should be used for one-time accounts (OTA) and B9 for external
numbering to accommodate the customer accounts transferred from the external systems.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Create Number Ranges for Customer
Accounts or Transaction XDN1 to create the new number ranges:
i.
On the ‘Edit Intervals: Customer, Object DEBITOR’ screen, click on the ‘Change
Interval’ button and maintain the required number ranges on the next screen (Figure
2.12) by entering the interval number (‘No.’), ‘From No.’ and ‘To Number’.
Figure 2.12 Number Ranges for Customer Accounts
ii.
Select the ‘Ext’ check-box, if the interval is to be used for external numbering.
Now that we have defined the required number ranges, the next step is to assign these
number ranges to the appropriate account groups.
Customer Accounts
63
2.1.1.8 Assign Number Ranges to Customer Account Groups
Use this configuration step to assign a number range to an account group. As indicated
already, you can assign the same number range to more than one account group.
Figure 2.13 Assigning Number Ranges to Customer Account Groups
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Assign Number Ranges to Customer
Account Groups or Transaction OBAR. On the resulting screen, enter the number range
against each of the account groups and ‘Save’ the details (Figure 2.13).
The next activity is to define the A/R pledging indicator.
2.1.1.9 Define Accounts Receivable Pledging Indicator
You can use the A/R factoring (or pledging) indicator to select customer master records and
line items, within a company code, to participate in the factoring procedure.
Project Dolphin
As BESTM wants customer master records and line items within a company code to
participate in the factoring procedure, the project team has decided to activate A/R pledging
for each of the company codes, both in USA and India.
64
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
In order to use the functionality:
i.
You need to activate the A/R factoring procedure in the required company code (s).
You may do this by following the menu path: SAP Customizing Implementation Guide
> Financial Accounting > Financial Accounting Global Settings > Global Parameters for
Company Code > Activate Accounts Receivable Pledging Procedure per Company
Code. Since BESTM wants to enable all the company codes to participate in factoring,
select the ‘AR Pledg.’ check-box for all the company codes of BESTM group (Figure
2.14).
Figure 2.14 Activating AR Pledging Indicator
ii.
iii.
You need to make sure that the accounts receivable factoring indicator (‘Accts recble
pledging ind.’) field is set as an ‘optional’ or ‘required’ entry field in the customer
account group and the company code (customers) screen layout. We have already
completed this in Section 2.1.1.1 and 2.1.1.2 of this Chapter.
You also need to adapt a line layout variant for the customer line item display to take
care of this. Alternatively, you can create your own line layout variant for the A/R
factoring procedure. You can do this using the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts
Payable > Customer Accounts > Line Items > Display Line Items > Define Additional
Fields for Line Item Display.
To define the A/R pledging indicator:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Accounts Receivable
Pledging Indicator.
On the resulting screen, click on ‘New Entries’ and maintain the details on the next
screen as indicated in Figure 2.15. The ‘AR Pled. Stat.’ (Accounts Receivable Pledging
Status) field indicates the type of A/R pledging procedure and assigns the factoring
indicator (‘AR Pled. Stat.’) to the open (1) or closed (2) procedure. This pledging status
appears as additional information in the customer master record and is therefore
visible, to you, in the line item and open item list.
Customer Accounts
65
Figure 2.15 AR Pledging Indicator - Details
iii.
Repeat the definition for all the company codes and ‘Save’ the details. We have, now,
defined the A/R pledging indicator for all the company codes of BESTM Corporate
(Figure 2.16).
Figure 2.16 AR Pledging Indicator for BESTM Company Codes
Once defined, and entered in the customer master record (Figure 2.17) under ‘Additional
Company Code Data’ under the ‘Customer: Payment Transactions’ tab, the system
automatically transfers the AR pledging indicator to the customer line item on posting; of
course, you can also enter this manually.
66
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.17 AR Pledging Indicator in Customer Master
With this, we are, now, ready to configure the sensitive fields for dual control.
2.1.1.10 Define Sensitive Fields for Dual Control (Customers)
Here, you define the ‘sensitive fields’ for dual control in the customer (or vendor) master
records. If you define a field (say, payment terms) in the customer (or vendor) master record
as ‘sensitive’, then, the system blocks corresponding customer (or vendor) account for the
payment run if there is a change to the entry. The system will, however, remove the block
when a second person, with proper authorization, checks the change and confirms the same.
Customer Accounts
67
Project Dolphin
BESTM wants the project team to manage ‘Payment Terms’, ‘Alternate Payer’ and ‘House
Bank’ as the sensitive fields. Accordingly, these fields need to be brought under dual control
to avoid any misuse.
To define the sensitive fields for dual control:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Creating Customer Master Data > Define Sensitive Fields for Dual
Control (Customers). You may also use Transaction S_ALR_87003378.
On the resulting screen, click on ‘New Entries’ and select the required fields in ‘Field
name’ and ‘Save’ the details when done (Figure 2.18). With these settings, now, if
anyone changes the field content of any of these sensitive fields, the system brings
up a message when saving the master record. Though the system will eventually allow
to save the data, it will not allow this account to be included in any payment run
unless the change is verified and confirmed (or rejected) by another user, other than
the one who has changed the field contents.
Figure 2.18 Sensitive Fields for Dual Control
Suppose that you have changed the payment terms (for customer 9500000027) to 0001 from
the previous value:
i.
The system pops-up a message that the changes you have done are yet to be
confirmed (Figure 2.19).
68
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.19 System Displaying a Message on the Changes to Sensitive Fields
ii.
You can use Transaction FD08 (for single records) and FD09 (for multiple customer
master records) to view and confirm/reject the changes. On entering the Transaction
FD08, for example, the system brings up the last record, and you can press ‘Enter’ to
continue, if that is the record you want to review. The system will, now, bring up the
next screen showing the ‘Current Status’ that there are field contents which needs to
be confirmed (Figure 2.20).
Figure 2.20 System Displaying the Confirmation Status
Customer Accounts
iii.
69
You can click on ‘Changes to sensitive fields’ button to view which field’s content has
been changed to (Figure 2.21).
Figure 2.21 System Displaying the Changed Sensitive Field
iv.
The system shows that the contents of ‘Payment terms’ field has been modified. You
may double-click on ‘Payment terms’ to view the changes: the system brings up the
details indicating when the change was made, what was the old value and what is the
new value (Figure 2.22).
Figure 2.22 System Displaying the Details of Changes Made to Sensitive Fields
v.
If you go back to the previous screen, and try confirming the changes the system will
not allow you to do so, if you are the same person who has made the changes in the
first place. The system will bring up a message that you are not allowed to change but
can only display the details (Figure 2.23).
Figure 2.23 System Not Allowing to Confirm the Changes by the Same User
70
vi.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Now you need to approach another accounting clerk / supervisor, who has the
necessary authorization, to confirm / reject the changes.
You may also display the critical changes (and take action) using the SAP Easy Access
menu path: SAP Menu > Accounting > Financial Accounting > Accounts Receivable >
Information System > Reports for Accounts Receivable Accounting > Master Data >
Display/Confirm Critical Customer Changes. You may also use Transaction S_ALR_87012183.
This completes our discussion on dual control of sensitive fields and also the preparations
required for creating customer master records. Let us, now, look at the settings that you can
make to exercise control on changing customer master records.
2.1.2 Preparations for Changing Customer Master Data
SAP uses the report RFDABL00 to display changes to the customer master record data, across
accounts. The default ‘select option’ brings out the change date, the name of the person who
made the change and the field group. However, you can choose additional fields for which
you may want to see the changes for the general data, the company code data or the sales
area data. You can also display the technical field names of the changed fields. Besides
selecting additional fields, for which you want to see the changes, if any, you can also protect
these individual fields via authorizations when maintaining master data.
You need to complete the preparations in two steps: in the first step, you need to define the
field groups and in the second step, you will assign the required fields (to the field group you
just defined) for which you want the program to display the changes. By establishing suitable
authorization, you may also restrict the changes to these fields.
Project Dolphin
BESTM management has indicated that they want to include additional fields like ‘Alternative
Payer’, ‘House Bank’, ‘Payment Terms’, ‘Reconciliation Account’, ‘Customer Classification’,
‘Payment Block’ and ‘Credit Control Area’ in logging the changes made by users while
changing the customer master records. However, they have indicated that they do not want
to exercise restricting the changes to these fields as such action for some of the fields
(‘Alternative Payer’, ‘House Bank’ and ‘Payment Terms’) are better handled by dual control of
sensitive fields.
Let us start with the first step of defining the field groups for customer master change.
2.1.2.1 Define Field Groups for Customer Master Records
Here, you will define field groups by entering a key and description for each field group. When
you set the indicator ‘No authorization’, then, the system does not subject this group to the
Customer Accounts
71
authorization check when maintaining master data; the system uses this field group only for
selecting the fields via the report (RFDABL00) for displaying changes.
To define the required field groups:
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Changing Customer Master Data > Define Field Groups for Customer
Master Records.
On the resulting screen (Figure 2.24) click on ‘New Entries’ and enter a 1 or 2-digit
numeric identifier for the new ‘Field group’, provide a ‘Description’ and select the ‘No
authorization’ check-box to prevent any authorization checks on this field group,
when changing the master records.
‘Save’ the details and create more field groups, if required.
Figure 2.24 Field Group for Customer Master Change Control
With the definition of field group, we are now ready to assign individual fields (to the field
group) for which you want to show the changes, while displaying the customer master
changes.
2.1.2.2 Group Fields for Customer Master Records
Using this activity, you will, now, assign the customer master record fields to the field group(s)
that you have defined in the previous step. Once done, you can enter this field group in
program RFDABL00 afterwards, to display the changes.
To include the fields to the field group:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Master Data >
Preparations for Changing Customer Master Data > Group Fields for Customer Master
Records.
On the resulting ‘Change View “Customer field group fields”: Overview’ screen (Figure
2.25), click on ‘New Entries’, enter the field group identifier (‘Field grp’) and add the
customer master fields (‘Fld name’) that you want to include in report RFDABL00,
under this field group. ‘Save’ when completed; the system brings up the ‘Field Label’
for each of these fields.
72
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 2.25 Adding Fields to Field Group
Now that you have defined the field group and added the customer master record fields to
the field group, you can use them in the selection screen of report RFDABL00. Use the SAP
Easy Access menu path: SAP Menu > Accounting > Financial Accounting > Accounts Receivable
> Information System > Reports for Accounts Receivable Accounting > Master Data > Display
Changes to Customers or Transaction S_ALR_87012182 and maintain the entry (Figure 2.26)
for the ‘Field group’ (01).
Figure 2.26 Selection Screen of Report RFDABL00 Showing the Field Group
Customer Accounts
73
When you execute the report, the system brings up the list displaying the changes made to
the fields, including the ones in the field group (01), for example. You can notice (Figure 2.27)
that the system is displaying the changes for the additional fields (for example, ‘Recon.
Account’), besides the sensitive fields (for example, ‘Payt terms) for which there were changes
in the master record.
Figure 2.27 Report RFDABL00 Displaying Changes
This completes our discussion on the settings required to control changing of customer
master records. Let us, now, see the deletion of customer master records.
2.1.3 Delete Customer Master Data
Using this configuration step, you can delete the customer master records through the
standard SAP program SAPF019. The system deletes general customer master data for
customers who are not created as customers in SAP SD.
You will be able to delete master records for accounts which do not have any transaction data.
The other condition is that the company code for which you are trying to delete the master
records should not have been flagged as ‘productive’. Use this program only in the test phase.
To delete, use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Delete
Customer Master Data or Transaction OBR2. Maintain the required selection parameters on
the resulting screen and run the program. As you can see, you will be using the same program
to delete G/L and vendor master records as well.
You can use the program SAPF019 to delete master data in FI. You can use it to delete
customer master data, vendor master data and G/L account master data. You can run this for:
(1) deleting general master data (in the case of G/L accounts, in one chart of accounts), (2)
deleting master data dependent on company code and (3) deleting general master data and
master data dependent on company code. For each of the deletion run, you can specify
74
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
whether or not the system should take into account the deletion flag in master records by
selecting or deselecting the ‘Delete per deletion flag only’ check-box. The system checks the
deletion block always at general data and company code-dependent data level: if there is a
block at company code-dependent data level, then the general data is not deleted either. The
‘deletion block’ (NODEL) takes precedence over the ‘deletion flag ‘(LOVEM).
In the case of customer master records, the program deletes general master data, bank
details, VAT registration numbers, addresses, classifications, credit management (across
control areas and centrally), unloading points, tax indicators, contact persons, licenses,
partner function limit, shipping data, master data in the company code, dunning data and the
linked data. As regards the vendor master records are concerned, the program deletes
general master data, bank details, contact persons, VAT registration numbers, addresses,
classifications, master data in the company code, dunning data and the linked data. In the
case of G/L accounts, the program deletes, general master data in the chart of accounts,
names in the chart of accounts, key word list in the chart of accounts, master data in the
company code and sample accounts, if selected in the selection screen. Besides the above,
the program also deletes the change documents for master data and the SAPScript text files.
The general master data can only be deleted if no other application makes reference to that
account. If you want to delete only general master data, master data dependent on company
code should not have been created in FI. If a customer or vendor is referenced by another
customer or vendor (for example, via alternative payee), you can only delete the referenced
master record by deleting the referencing master record at the same time. Also, you can
delete master data in FI, only if no transactions have been posted to the corresponding
accounts; if there are transaction figures in any of the selected accounts, then, you have to
manually run the program SAPF020 (to reset transaction data from company code) before
deleting that account.
After execution, the log lists every table which is processed in the program selection. You can
also create a detail log, for each account type, to find out why certain data was not deleted.
The detail logs show you what other company codes and applications use the data and how
customers and vendors are linked to one another. Since deleting or displaying even smaller
volumes of data can result in runtime problems, you should always run this program only as
a background job.
This completes our discussion on preparations for creating / changing / deleting customer
master records. Let is now see the settings required for line items.
Customer Accounts
75
2.2 Line Items
The settings that are required to be configured for customer line items can be grouped into
three categories viz., (1) display open items, (2) open item processing and (3) correspondence.
2.2.1 Display Line Items
In the case of ‘display open items’, you will have to make the settings for the line item display
using the ABAP List View (ALV). By default, the system displays the line items with the ALV.
However, if you do not wish to use ALV, you can continue to use line item display without
ALV, as a modification. To enable this, you have to complete the settings listed under the
configuration step ‘Display Line Items without ALV’. You can access this IMG node through
the menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Customer Accounts > Line Items > Display Line Items >
Display Line Items without ALV.
Project Dolphin
The project team has recommended to the BESTM Corporate to stick to the line item display
using the ABAP List View. Also, they have suggested not to define additional fields for
customer line item display as that may result in performance issues. Besides, they are also of
the view that no additional settings would be required than the default ones, for processing
open items.
You may use ‘Define Additional Fields for Line Item Display’ (menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Customer Accounts > Line Items > Display Line Items > Define Additional Fields for Line Item
Display) to include additional fields (such as, ‘User’ or ‘Quantity’ etc) for display. However,
consider carefully whether you really need to enhance the line item display, as such
enhancements can reduce performance since the system has to read more table entries.
2.2.2 Open Item Processing
As in display of line items, you may make additional settings for open item processing. Follow
the menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Customer Accounts > Line Items > Open Item Processing,
and complete the individual configuration steps there on.
2.2.3 Correspondence
In the case of settings for correspondence, you can make new settings for correspondence
using the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Line Items >
Correspondence, or check your existing settings to ensure completeness. We have already
76
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
discussed the settings for correspondence when we configured the FI global settings. Of
course, you can check here, now, whether the settings are correct / complete. If you have not
yet made any settings earlier, you can do so here.
2.2.3.1 Define Period Types for Customers
Additionally, you can create account statements automatically by entering a key (say, 1 for
monthly statements, 2 for quarterly statements, 3 for half-yearly statements and so on)
specifying with which frequency the account statements are to be created in the ‘Bank
Statement’ field in the customer master and ’Account Statement’ field in the vendor master
records. You may specify this key as a selection criterion for the program for creating account
statements periodically.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Customer Accounts > Line Items >
Correspondence > Define Period Types for Customers. On the resulting screen, enter the
identifier for the frequency key (‘Acct Stmnt’) and provide an explanation in the ‘Text’ field
(Figure 2.28).
Figure 2.28 Periodic Account Statement Indicator
You need to determine the customer accounts for which you plan to generate periodic
account statements. Once done, you need to enter the appropriate key (from the above
definition) in the appropriate field in customer (‘Bank Statement’) / vendor master (‘Account
Statement’) record (Figure 2.29). The system, now, creates the account statements, for all the
customers / vendors whose master record is entered with this key, through the report
program as per the periodicity defined in the key.
Customer Accounts
77
Figure 2.29 Periodic Account Statement Indicator in Customer / Vendor Master Record
This completes our discussion on the settings required for line items. Let us move on to discuss
the settings required for displaying account balances.
2.3 Balances
There are two settings that you can make to configure account balance display, for both
customer and vendor:
•
•
Maintain Worklist for Displaying Balances
Maintain Users and Accounts for Internet Services
2.3.1 Maintain Worklist for Displaying Balances
It is possible that your company codes receive goods from the same vendor. In such a case,
if you may want to display the vendor items in all these company codes at the same time,
then, you can combine these company codes in one worklist. You can create these worklists
either manually or use the worklists that are automatically maintained: in either case, you
need to determine what objects (company code, customer or vendor accounts) should go into
the worklist.
In the case of ‘manual worklists’, you need to specify the required keys of the objects (for
example, the customer account numbers) to be processed in the same manner. On the other
hand, for ‘automatic worklists’, first specify a rule according to which the name of the worklist
is to be formed. Then, start the structure of the worklist once. The system creates a worklist
78
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
automatically for every alternative payer, and for every corporate group number which is
used in the master records. If other customers or vendors refer to an alternative payer or to
a corporate group account number, then, the system allocates them automatically to the
existing worklists, or creates new worklists for them. Your accounting clerks can decide if they
want to work with worklists or individual objects, when processing business transactions.
To configure the work lists, use menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Customer Accounts >
Balances > Maintain Worklist for Displaying Balances. You may also use Transaction OB55.
Project Dolphin
BESTM management wants to create various worklists by grouping the company codes, in
each of the companies, for displaying the account balances together. Accordingly, one
worklist will be created, for example, combining company codes of 1110 and 1120, another
for 1210 and 1220, another for 2100 and 2200 and one more for 3100 and 3200.
On the initial screen, you need to decide whether you want to create the worklist by
combining company codes or customers or vendors or G/L Accounts. Accordingly, you need
to double-click on that object (say, Company Code) on the ‘Maintain Worklists: Objects’
screen. On the next screen, click on ‘Create’. On the resulting pop-up screen, enter the
identifier and a name of the work list. On the next ‘Maintain Worklists: Values’ screen, enter
the company codes that need to be grouped under the work list (Figure 2.30).
Figure 2.30 Manual Worklist for BESTM
To use worklists:
Go to ‘Settings -> Editing Options’ on the menu bar, when processing the open items. Select
the ‘Use Worklists’ check-box for the open items (Figure 2.31). You can, then, enter the key
for the work list in the ‘Account’ field. If both an account and a work list exist for one key,
then, the worklist has priority.
Customer Accounts
79
Figure 2.31 Enabling Worklist Entry during Open Item Processing
The next activity is to maintain users / accounts for internet services.
2.3.2 Maintain Users and Accounts for Internet Services
Here, in this activity, you decide which of your users can carry out which ‘Financial Accounting
Internet’ services. While doing that, you can specify which accounts / company codes these
users can view. By this, you can ensure that an internet user cannot have unauthorized access
to the data of other users.
To configure, use menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Customer Accounts > Balances > Local
Reporting for Account Balances > Maintain Users and Accounts for Internet Services.
On the resulting screen, click on ‘New Entries’ and maintain the details on the next screen:
select a ‘User’, select appropriate ‘Action’ from the drop-down values for that user, enter the
limiting conditions for accounts (‘From acct’ and ‘To acct’) and company code (‘Fm co.code’
and ‘To co.code’. ‘Save’ the details when completed (Figure 2.32).
Figure 2.32 Maintaining Users / Accounts for Internet Services
With this, we have completed the discussion on configuring the customer accounts.
80
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
2.1 Conclusion
In this Chapter on ‘Customer Accounts’, you learned that a customer can be a person
(individual), an organization or a group. You understood that a typical customer master data
is made up of four areas (segments) namely: general data, company code data (FI area), sales
& distribution data (SD area) and ETM data. You learned that you can create customer master
data, in SAP, in three different ways: central maintenance (for all the three areas), FI
maintenance (for FI area alone) and sales data maintenance (for SD area alone). You
understood that there are certain pre-requisites - like defining number ranges, creating
customer account groups and maintaining field status - which you need to complete before
you can create master data for your customers. You learned how to define the ‘sensitive
fields’ for dual control in the customer (or vendor) master records.
You also saw the preparations that you need to make for changing / deleting customer master
records. You understood that you will be able to delete master records for accounts which do
not have any transaction data, with the additional condition that the company code for which
you are trying to delete the master records should not have been flagged as ‘productive’.
Later, you learned about the settings that are required to be configured for customer line
items for displaying open items, open item processing and correspondence.
Finally, you learned about the settings that you need to make for configuring the account
balance display, for both customer and vendor.
Let us, now, move on to discuss the vendor accounts in the next Chapter.
3 Vendor Accounts
A
s in the case of customer accounts, we shall see the settings that are required for
configuring vendor accounts in this Chapter. Besides master data and line items, we
shall discuss the settings required for overdue payables as well here.
Let us start with the vendor master data.
3.1 Master Data
As in the case of customer accounts, you need to create one master record for each vendor
account that you require in the system. Both the financial accounting (FI-A/P) and the
purchasing (SAP MM) departments of your organization use the same master records. By
creating and storing vendor master data centrally, you enable their access throughout the
organization, and this avoids (a) the need to enter the same information twice and (b)
inconsistencies in master data that may creep in if not maintained centrally. If the address of
one of your vendors changes, for example, you only have to enter this change once and your
accounting and purchasing departments will always have the updated details.
A vendor, like a customer, can be a person (individual), an organization or a group. A typical
vendor master data is made up of three areas (segments) as shown in Figure 3.1:
•
•
•
General Data
Company Code Data (FI area data)
Purchasing Organization Data (MM area data)
As in the case of a customer account, the ‘general data’ with the information such as address,
control data, payment transactions, status, legal data etc., will be at the Client level and hence
is valid across company codes. The ‘company code data’ (account management, payment
transactions, withholding tax, correspondence etc) is valid only for the specific company code
in which the vendor has been created. The ‘purchasing organization data’ is made up of
information relating to purchasing organization, purchasing data (conditions, sales data,
control data, default values for material etc), additional purchasing data and texts and will be
valid for the purchasing organization.
The specifications you make in a vendor master record are used (a) as default values when
you post items to the account (for example, the terms of payment you specify in the master
record are defaulted for document entry), (b) for processing business transactions like
payment processing for which the date of the last payment run is required for the automatic
payment program, (c) for working with master records so as to, for example, prevent certain
82
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
users (through appropriate authorization groups) from accessing an account, (d) for
communication with the vendor using the address details and (e) in the purchasing
department for material procurement activities.
Figure 3.1 Vendor Master Data
You should have implemented the Materials Management (SAP MM) application
component in order to enter / process vendor master records for processing the purchasing
related business transactions.
You can create vendor master data, in SAP, in three different ways:
•
•
•
Central maintenance (for all the three areas)
FI maintenance (for FI area alone)
Purchasing organization data maintenance (for MM area alone)
The Table 3.1 outlines the menu path and Transaction for creating / changing / displaying
vendor master records from different maintenance areas (FI, MM and central). All these
Transactions are now bundled into a single Transaction known as BP. However, if you still
enter any of the earlier Transactions like FK01 / FK02 / FK03 or MK01 / MK02 / MK03 or XK01
/ XK02 / XK03 to create / change / display vendor master in FI area, MM area and centrally,
the system redirects you to the new Transaction BP automatically, after briefly displaying the
earlier Transaction screen.
Vendor Accounts
Maintenance
Area
Accounting
(FI)
Area Menu
FDMN
Purchasing
(MM)
Area Menu
ME00
Activity
SAP Easy Access Menu
Create
Vendor
(Accounting)
Change
Vendor
(Accounting)
Display
Vendor
(Accounting)
Create
Vendor
(Purchasing)
Change
Vendor
(Purchasing)
Display
Vendor
(Purchasing)
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Create
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Change
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Display
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Purchasing > Create
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Purchasing > Change
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Purchasing > Display
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Maintain Centrally
> Create
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Central > Create
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Maintain Centrally
> Change
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Central > Change
SAP Menu > Accounting > Financial
Accounting > Accounts Payable >
Master Records > Maintain Centrally
> Display
SAP Menu > Logistics > Materials
Management > Purchasing > Master
Data > Vendor > Central > Display
Create
Vendor
(Centrally)
Centrally
Change
Vendor
(Centrally)
Display
Vendor
(Centrally)
Table 3:1 Vendor Master Maintenance
83
Transaction
BP (earlier
FK01)
BP (earlier
FK02)
BP (earlier
FK03)
BP (earlier
MK01)
BP (earlier
MK02)
BP (earlier
MK03)
BP (earlier
XK01)
BP
(earlier
XK02)
BP
(earlier
XK03)
84
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
As in the case of customer accounts, in some companies, accounting (FI) and purchasing
(MM) departments maintain the general data together but FI and purchasing organization
data separately. In other companies, vendor master records are maintained centrally (for all
the areas).
3.1.1 Preparations for Creating Vendor Master Data
As in the case of customer master records, you need to complete certain pre-requisites - like
defining number ranges, creating vendor account groups and maintaining field status - before
you can create master data for your vendors. Since we have discussed them in details in
Section 2.1.1 of Chapter 2, we are not repeating the details here. It is sufficient to note that
you need to (a) decide on suitable numbering (internal / external) for the vendor master
records with appropriate number range intervals, (b) have adequate vendor account groups
for creation of vendor master records as the account group determines which fields have to
be filled compulsorily (mandatory) and which ones can be optionally filled when creating the
master records besides allocating a number (external or internal) to the master record and (c)
have field status definitions - suitably defined for the account group (and also for the company
code and/transactions) - to determine the status of the fields on the screens for the master
data creation.
Let us start with the creation of (vendor) account groups.
3.1.1.1 Define Account Groups with Screen Layout (Vendors)
This is similar to the one that we have seen earlier for customers. Use this activity to define
the required account groups for crating you vendors (suppliers). As in the case of customer,
you can have more detailed classification of vendor account groups like domestic vendor
(0001), goods supplier (0002), alternate payer (0003), invoice presented by (0004), forwarding
agent (0005), special vendor (0010), one-time vendors (0099) and so on or you can have
limited ones like domestic vendors, foreign vendors etc.
Project Dolphin
BESTM management has asked the Dolphin project manager to create elaborate account
groups like vendor (0001), goods supplier (0002), alternate payer (0003), invoice presented
by (0004), forwarding agent (0005), special vendor (0010) and one-time vendors (0099)
besides separate account groups to take care of vendor accounts that are transferred from
the external system.
The project team has recommended to the BESTM management, to control the field status
through accounts groups. Accordingly, no new screen layout settings are to be defined for the
company codes (of BESTM) or for transactions.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations
Vendor Accounts
85
for Creating Vendor Master Data > Define Account Groups with Screen Layout (Vendors) to
create new account groups (Figure 3.2). You may also use Transaction OBD3.
Figure 3.2 Vendor Account Groups
As in the case of customer account groups, you must have at least one vendor account group
defined in the system without which you cannot create any vendor master record. As stated
elsewhere, you will be able to delete an existing account group only if no master record is
referencing that group. You also need to be cautious in changing its field status settings of an
existing account group; else, you may run into serious issues. For example, if you change the
field status of an already existing field (with the status ‘display’) to ‘suppressed’, then, you
will not be able to see that field on the screen even though the earlier field contents would
still be valid for that field.
3.1.1.2 Define Screen Layout per Company Code (Vendors)
As already discussed in Section 2.1.1.2 of Chapter 2, you should manage the field status via
the account groups, except for special situations wherein you may define company-code
specific field status, for example, if the company codes are in different countries or some
company codes do not use automatic payment processing for vendors.
Project Dolphin
BESTM does not want to manage the field status via either company codes or processing type
(= transaction); instead, it has to be through the account groups.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations
for Creating Vendor Master Data > Define Screen Layout per Company Code (Vendors), to
86
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
define the necessary settings, if fields are to have an alternative status depending on the
company code. Once you are into the Transaction, specify the company code and determine
the status of the fields as required. In the standard system, as in the case of customers, you
will see default settings that are valid for all the company codes as denoted by ‘*’ in the
‘Company Code’ field (Figure 3.3). You may create new settings by clicking on ‘New Entries’
for specific company codes, or use the default settings as such or with some modifications.
We are not doing any change to the standard settings as BESTM wants to manage the field
status via account groups.
Figure 3.3 Defining Screen Layout per Company Code (Vendors)
3.1.1.3 Define Screen Layout per Activity (Vendors)
Here, you determine, depending on the transactions (display, create or change) for vendor
master data, which master record fields are ready for input, require an entry and are hidden.
As discussed previously, these specifications will be linked with the field status of the account
group and the company code-dependent specification; the ‘link rule’ will determine which
final status the fields have on the entry screen for master data. Since, for BESTM, the field
status will be controlled via account groups, we will not be configuring this activity.
However, should you really need to control via transactions, you can do so by using the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor
Master Data > Define Screen Layout per Activity (Vendors).
Figure 3.4 Defining Screen Layout per Transaction (Vendors)
Vendor Accounts
87
On the resulting screen (Figure 3.4), you will see the listing of various transactions like create
vendor (accounting), change vendor (accounting), delete vendor (accounting), create vendor
(purchasing), create customer (centrally) and so on. You may double-click on the required
transaction, and change the field status, as required, on the ‘Change View “TransactionDependent Field Selection (Vendor)”: Details’ screen.
We will not be discussing (a) change message control, (b) define accounting clerks and (c)
define industries, again in this Section, as we have already discussed them in Section 2.1.1.4,
2.1.1.5 and 2.1.1.6 (of Chapter 2) respectively, when we discussed the customer accounts.
You do not need to repeat defining industries. However, you can define the accounting clerks
who will handle vendor accounts, using the menu path SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Vendor Accounts
> Master Data > Preparations for Creating Vendor Master Data > Define Accounting Clerks.
Similarly, you can change the standard message control (or define new) by using the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor
Master Data > Change Message Control for Vendor Master Data.
With this we are now ready to define the number ranges for vendor master records.
3.1.1.4 Create Number Ranges for Vendor Accounts
As with number ranges for customer accounts, you will use this configuration step to maintain
the required number range intervals for the vendor accounts. You can have several number
ranges with each range being allocated to a single account group, or have fewer number
ranges wherein you will allocate more than one account group with the same number range.
Project Dolphin
BESTM wants numbering the vendor accounts similar to that of the customer accounts.
Accordingly, the project team wants to create six number ranges from B1 to B5, and B9 with
the specifications that B5 should be used for one-time vendors and B9 for external numbering
to accommodate the vendor accounts transferred from the external systems.
The configuration is similar to the one that we have discussed in Section 2.1.1.7 of Chapter 2
when we defined the number ranges for customer accounts. Use the menu path: SAP
Customizing Implementation Guide > Financial Accounting > Accounts Receivable and
Accounts Payable > Vendor Accounts > Master Data > Preparations for Creating Vendor
Master Data > Create Number Ranges for Vendor Accounts or Transaction XKN1 to create the
required number ranges (Figure 3.5). While defining, select ‘Ext’ check-box if you need to
denote one or more number ranges as external. For all the number ranges which are external,
you will need to supply the account number while creating the master records; for all other
88
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
cases, the system will automatically supply the number ranges, internally, from the respective
number range intervals.
Figure 3.5 Number Ranges for Vendor Accounts
Now that we have defined the required number ranges, the next step is to assign these
number ranges to the appropriate (vendor)account groups.
3.1.1.5 Assign Number Ranges to Vendor Account Groups
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations
for Creating Vendor Master Data > Assign Number Ranges to Vendor Account Groups or
Transaction XKN2 to assign the number ranges to the vendor account groups (Figure 3.6). As
already indicated, you can have a single number range assigned to more than one account
group, if required. For example, in the case of BESTM, we have assigned the number range
B3, B4 and B9 to more than one account group.
Figure 3.6 Assigning Number Ranges to Vendor Account Groups
With this, we are now ready define the sensitive fields for dual control.
Vendor Accounts
89
3.1.1.6 Define Sensitive Fields for Dual Control (Vendors)
As in the case of customer accounts, you need to define the sensitive fields (if any) here, so
that these fields will be brought under dual control for additional security. This means, that
the user who changes the field content of a sensitive field will not be able to approve the
same; but need to approach another user, with the required authorization, to confirm/reject
the changes. Unless the changes are confirmed or rejected, you will not be able to include
that account, for example, into certain transactions like say, payment run. Till the changes are
verified, the system will pop-up with the message, indicating that the changes are yet to be
actioned upon, when you enter any Transaction to edit the master record. It is a general
practice that a sensitive field will be verified by the supervisor or senior accounting clerk in
the accounts department.
Project Dolphin
BESTM wants to have a strict control to unauthorized changes to some of the important fields
in vendor master records. Accordingly, they have indicated to the project team to bring
‘Alternative Payee’, ‘Payment Block’, Bank Account’, ‘Account with Vendor’ and ‘Tolerance
Group’ under dual control by denoting them as ‘sensitive’ fields. Only the supervisor or
manager of the accounting clerk, will have the required authorization to confirm or reject the
changes made to these sensitive fields.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Preparations
for Creating Vendor Master Data > Define Sensitive Fields for Dual Control (Vendors) or
Transaction S_ALR_87003179 to define the sensitive fields (Figure 3.7).
Figure 3.7 Sensitive Fields under Dual Control for Vendor Master
90
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You may use Transaction FK08 to confirm changes to sensitive fields of a single vendor
or Transaction FK09 to confirm changes belonging to multiple vendors (Figure 3.8).
In the case of multiple accounts, you have the option to select (a) accounts not yet confirmed,
(b) accounts refused and (c) accounts to be confirmed by yourself. In the case of option (b),
you can display the accounts for which sensitive field changes have earlier been rejected. In
option (c), the system displays only those accounts for which you have authorization to
confirm changes. As a part of dual control, the system also checks to see if you were involved
in such changes.
Figure 3.8 Confirming Changes to Sensitive Fields of Multiple Records
You may also use the SAP Easy Access menu path: SAP Menu > Accounting > Financial
Accounting > Accounts Payable > Information System > Reports for Accounts Payable
Accounting > Master Data > Display/Confirm Critical Vendor Changes or Transaction
S_ALR_87012090, to display the critical changes made to the sensitive fields (and take action,
if required). If you notice closely, you will see that this is nothing but the Transaction FK09.
SAP uses the program RFKCON00 for displaying and changing the vendor account’s
confirmation status (LFA1-CONFS, LFB1-CONFS). The system provides you with the status as
to whether sensitive fields have been changed in the vendor master record, and whether the
changes have been confirmed or rejected by dual control. You will see the confirmation status
represented by a coloured stoplight with Green (status: confirmed), Yellow (status: to be
confirmed) and Red (status: rejected).
This completes our discussion on dual control of sensitive fields and also the preparations
required for creating vendor master records. Let us, now, look at the settings that you can
make, to exercise control on changing vendor master records.
Vendor Accounts
91
3.1.2 Preparations for Changing Vendor Master Data
This is exactly similar to that preparations for changing customer master data. SAP uses a
similar report, as that of customer, RFKABL00 to display changes to the vendor master record
data across various accounts. As in the case of customer accounts, first, you need to define
one or more field groups, and then in the second step you will assign the additional fields to
the field group(s) thus defined. Once done, when you run the report, you can include this field
group in the ‘select option’ so as to enable the program to display changes made to these
fields as well, besides the default display of, for example, date of change, person who has
made the changes etc. Also, by establishing suitable authorization, you can restrict the
changes to these fields.
Project Dolphin
BESTM management has indicated that they want to include additional fields Like ‘Alternative
Payee’, ‘House Bank’, ‘Reconciliation Account’, ‘ABC Indicator’, ‘Payment Block’ and ‘Interest
Indicator’ in logging the changes made by users while changing the vendor master records.
However, they have indicated that they do not want to exercise restricting the changes to
these fields as such action for some of the fields (‘Alternative Payee’, ‘House Bank’ etc) are
better handled by dual control of sensitive fields.
Let us start with the first step of defining the field group(s) for vendor master change.
3.1.2.1 Define Field Groups for Vendor Master Records
Define the required field group(s) by entering a key and a description for each field group.
Select the indicator ‘No authorization’, if you do not want the system to subject this group to
the authorization check when maintaining master data; in this case, the system uses this field
group only for selecting the fields via the report () for displaying changes.
To define the required field groups:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data >
Preparations for Changing Vendor Master Data > Define Field Groups for Vendor
Master Records.
On the resulting screen, click on ‘New Entries’ and enter a 1 or 2-digit numeric
identifier for the new ‘Field group’, provide a ‘Description’ and select the ‘No
authorization’ check-box to prevent authorization checks on this field group when
changing the master records (Figure 3.9). ‘Save’ the details and create more field
groups, if required.
92
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 3.9 Field Group for Vendor Master Change Control
With the definition of field group, we are now ready assign individual fields (to the field group)
for which you want to show the changes made, while displaying the vendor master changes.
3.1.2.2 Group Fields for Vendor Master Records
Assign the required vendor master record fields to the field group(s) that you have defined in
the previous step. Once done, you can enter this field group in program RFKABL00 afterwards,
on the selection screen, to display the changes.
To include the fields to the field group:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data >
Preparations for Changing Vendor Master Data > Group Fields for Vendor Master
Records.
On the resulting ‘Change View “Fields of the Vendor Field Groups”: Overview’ screen,
click on ‘New Entries’, enter the field group identifier (‘Field grp’) and add the vendor
master record fields (‘Fld name’) that you want to include in report RFKABL00 under
this field group. ‘Save’ when completed; the system brings up the ‘Field Label’ for
each of these fields (Figure 3.10).
Figure 3.10 Assigning Fields to Field Group for Vendor Master Change Control
As you have now defined the field group (10) and added the vendor master record fields to
that you can, now, use this field group in the selection screen of report RFKABL00. Use the
SAP Easy Access menu path: SAP Menu > Accounting > Financial Accounting > Accounts
Payable > Information System > Reports for Accounts Payable Accounting > Master Data >
Vendor Accounts
93
Display Changes to Vendors or Transaction S_ALR_87012089. On the resulting selection
screen, you may enter ‘Field group’ (10), among other entries (Figure 3.11).
Figure 3.11 Selection Screen of Report RFDABL00 Showing the Field Group
When you execute the report, the system brings up a list displaying (Figure 3.12) the changes
made to the fields, including the ones in the field group 10.
Figure 3.12 Report Output of RFKABL00 with List/Detail of Changes to Vendor Records
94
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You can notice that the system is displaying the changes for the additional fields in the field
group 10 (for example, ‘Interest indic.’ And ‘Alternat. Payee’), besides the sensitive fields (if
any) for which there were changes in the vendor master record.
This completes our discussion on settings required to control changing of vendor master
records. Let us, now, see the deletion of vendor master records.
3.1.3 Delete Vendor Master Data
Using this configuration step, you can delete the vendor master records through the standard
SAP program SAPF019. The system deletes general vendor master data for vendors who are
not created as vendors through Purchasing in SAP MM. As discussed in Section 2.1.3 of
Chapter 2, you will be able to delete master records for accounts which do not have any
transaction data. The other conditions are similar to the deletion of customer master records.
To delete, use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Vendor Accounts > Master Data > Delete
Vendor Master Data or Transaction OBR2. Maintain the required selection parameters on the
resulting screen and run the program. As you can see, you will be using the same program to
delete G/L and customer master records as well. Refer to Section 2.1.3 of Chapter 2 for
additional details on the program SAPF019.
This completes our discussion on preparations for creating / changing / deleting vendor
master records. Let is, now, see the settings required for vendor line items.
3.2 Line Items
The settings that are required to be configured for vendor line items, are similar to the ones
we have discussed for customers, and can be grouped into three categories viz., (1) display
open items, (2) open item processing and (3) correspondence.
Let us start with the settings for displaying open items, for vendors.
3.2.1 Display Line Items
In the case of ‘display open items’, you will have to make the settings for the line item display
using the ABAP List View (ALV). By default, the system displays the line items with the ALV.
However, if you do not wish to use ALV, you can continue to use line item display without ALV
as a modification. To enable this, you have to complete the settings listed under the
configuration step ‘Display Line Items without ALV’. You can access this IMG node through
the menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Vendor Accounts > Line Items > Display Line Items >
Display Line Items without ALV.
Vendor Accounts
95
Project Dolphin
The project team has recommended to the BESTM Corporate to stick to the default and
standard line item display settings using the ABAP List View. Also, they have suggested not to
define additional fields for vendor line item display as that may result in performance issues.
Besides, they also of the view that no additional settings would be required than the default
ones, for processing open items.
You may use ‘Define Additional Fields for Line Item Display’ (menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Vendor Accounts > Line Items > Display Line Items > Define Additional Fields for Line Item
Display) to include additional fields (such as, ‘User’ or ‘Quantity’ etc) for display. However,
consider carefully whether you really need to enhance the line item display, as such
enhancements can result in performance issues since the system has to read more table
entries to bring up the display.
3.2.2 Open Item Processing
As in display of vendor line items, you may make additional settings for open item processing.
Follow the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendors Accounts > Line Items > Open Item
Processing, and complete the individual configuration steps there on. We have not configured
this, as BESTM wants to stick on to the default settings for the open item processing.
3.2.3 Correspondence
In the case of settings for correspondence, you can make new settings for correspondence
using the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Line Items >
Correspondence, or check your existing settings to ensure completeness. We have already
discussed the settings for correspondence, when we configured the FI global settings. You can
check those settings, here, and make additional or new settings, if required.
3.2.3.1 Define Period Types for Vendors
The settings we have defined in Section 2.2.3.1 of Chapter 2, for customers, are valid as
‘period types’ for vendors as well. Use the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Customer
Accounts > Line Items > Correspondence > Define the ‘Period Types’ for Vendors, if you have
not created these keys, earlier. Refer Section 2.2.3.1 of Chapter 2, for the configuration steps
and how to use this key in vendor master records.
96
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
This completes our discussion on the settings required for line items. Let us move on to discuss
defining the overdue thresholds for vendor account groups.
3.3 Define Thresholds for Vendor Account Groups
Here, you can define a threshold (in percentage) to flag when an overdue payment to a vendor
should actually be termed as ‘critically overdue’. The system flags an overdue payable amount
as ‘critically overdue’, when the actual overdue payable amount to the total payable is equal
to or greater than the defined threshold. You can differentiate the settings, per company
code, and make that as more stringent or relaxed (called as ‘exceptional threshold’) that will
then override the ‘generic threshold’ defined for a particular account group.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Vendor Accounts > Overdue Payables > Define
Thresholds for Vendor Account Groups. On the resulting screen, define the required
thresholds per vendor group (and company code).
For example, as depicted in Figure 3.13, the ‘generic threshold’ for account group 0001 is 80%.
However, since there is another entry for the same account group with the specification of
company code (1110), the ‘company code-vendor account group’ entry of 70% is considered
as the ‘exceptional threshold’.
Figure 3.13 Overdue Thresholds for Vendor Account Groups
Now, consider a situation wherein the actual overdue payable amount is $7,690 against the
total payable amount of $10,000, for a vendor, who has been assigned with the account group
of 0001, in company code 1110:
Vendor Accounts
•
•
97
When there is both a generic entry and also a (more stringent) company code-specific
entry, (for the account group 0001), with the overdue payable being 76.9%, the
system flags the vendor’s payable as ‘critically overdue’ based on the ‘exceptional
threshold’ definition (70%), even though the ‘generic threshold’ definition (80%) does
not make that as critically overdue.
When there is no company code specific entry (for account group 0001), but only the
generic entry (80%), then, this overdue is not be considered as ‘critically overdue’ as
the actual overdue payable to the total payable is less than 80%.
This completes our discussion on settings that are required for vendor accounts.
3.4 Conclusion
You learned that, as in the case of customer accounts, you need to create one master record
for each vendor account that you require in the system. You understood that both the
financial accounting (FI-A/P) and the purchasing (SAP MM) departments of your organization
use the same master records. You further understood that by creating and storing vendor
master data centrally, you enable their access throughout the organization, thereby avoiding
the need to enter the same information twice and also the inconsistencies in master data that
may creep in if not maintained centrally.
You learned that a vendor, like a customer, can be a person (individual), an organization or a
group, and a typical vendor master data is made up of three areas (segments): the general
data, the company code data (FI area data) and the purchasing organization data (MM area
data).
You learned that, as in customer master records, you need to complete certain pre-requisites
before you can create / change / delete master data for your vendors. You also learned about
the settings that you are required to configure for vendor line items: for displaying open
items, open item processing and for correspondence.
Finally, towards the end of the Chapter, you learned that you can define a threshold (in
percentage) to flag when an overdue payment to a vendor should actually be termed as
‘critically overdue’. Once defined, you learned that the system flags an overdue payable
amount as ‘critically overdue’, when the actual overdue payable amount to the total payable
is equal to or greater than the defined threshold. You also learned that you can differentiate
the settings, per company code, and make that as more stringent / relaxed (called as
‘exceptional threshold’) that will, then, override the ‘generic threshold’ defined for a
particular account group.
Let us, now, move on to discuss the settings that you need to make for some of the important
business transactions in both A/R and A/P. Let us start with incoming invoices / credit memos,
in the next Chapter.
4 Incoming Invoices/Credit
Memos
T
here are a couple of tasks which you need to complete, for configuring ‘incoming
invoice’ / ‘credit memo’ business transaction, including making / checking document
settings, making / checking settings for document parking, defining terms of payment
and defining cash discount base for incoming invoices. The first task will be to make / check
the document settings.
4.1 Make and Check Document Settings
Towards checking and making document settings for incoming invoices / credit memos, you
need to complete the following activities, if you have not already completed them while
configuring FI Global Settings:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Define Document Types
Define Posting Keys
Validation in Accounting Documents
Define Default Values
Define Field Status Variants
Assign Company Code to Field Status Variants
Define Subscreens for Coding Blocks
Screen Variants for Document Entry
Substitution in Accounting Documents
Define Text IDs for Documents and Line Items
Define Line Layout for Document Posting Overview
Define Line Layout for Document Change/Display
Select Standard Line Layout for Document Change/Display
Document Change Rules, Document Header
Maintain Fast Entry Screens for G/L Account Items
If you have already made these settings while configuring FI global settings, you can
check them, here.
100
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Let us start with the definition of document types.
4.1.1 Define Document Types
As you are aware, the ‘document type’, in SAP, is used to classify accounting documents and
distinguish between business transactions to be posted. Entered in the document header, it
applies to the whole document. You define your document types at the client level. You will
specify a number range key for each document type. You create the desired number range
intervals, for each number range key based on the company code.
A document type helps to:
•
•
•
•
Differentiate between business transactions: you can always tell what type of
business transaction is involved, as the document type is shown for every line item.
You can also use the document type for evaluation purposes.
Control the posting to the appropriate account types: the document type controls as
to what type of account namely vendor, customer, or G/L, you can post to.
Assign document numbers: you will assign a number range to every document type.
The document numbers are chosen from this number range. You can use the same
number range for several document types.
Apply the vendor net procedure: the applicable discount and the net amount are
calculated (and posted) when the vendor invoice is posted.
You can establish the link between the original document and the processing document,
by storing them correctly. If you want to store original documents (paper documents) along
with their corresponding processing documents (EDP documents) generated in the system,
then, store all them together with the same document type. If you want to store several
document types together, assign a separate number range to each document type. For
example, suppose you want to store the original invoice (say, CD-2019-44444) along with the
processing document (8888899999) posted in SAP for invoice posting. You just need to enter
CD-2019-44444 in the ‘Reference’ field of the document 8888899999. In doing so, you can
always cross-reference these two documents, besides using the ‘Reference’ field in the search
criteria.
Store your original documents (paper documents) under the EDP number of the SAP System.
You should write the EDP document number (say, 8888899999) on the original document
(say, CD-2019-44444). In this way, the original document for a business transaction can be
found at any time.
As in other cases, SAP comes delivered with several (40+, actually) standard document types
(Table 4.1), that you can use as such or change to create new. The standard document types
cover business transactions relating to G/L accounting, A/R, A/P, AA and consolidation in SAP
Incoming Invoices/Credit Memos
101
FI. In SAP MM & SD, there are standard documents to meet business transactions involving
GR/IR, invoicing (incoming and outgoing), stock taking (inventory) etc.
Type
AA
AB
AD
AF
AN
AP
CC
CL
CO
DA
DG
DR
DV
DZ
ER
EU
EX
KA
KG
KN
KP
Description
Asset Posting
Journal Entry
Accruals/Deferrals
Depreciation Pstngs
Net Asset Posting
Periodic asset post
Sec. Cost CrossComp.
CL/OP FY Postings
Secondary Cost
Customer document
Customer credit memo
Customer invoice
Customer interests
Customer Payment
Manual Expense Travel
Euro Rounding Diff.
External Number
Vendor Document
Vendor Credit Memo
Net vendors
Account maintenance
Type
KR
KZ
ML
PR
RA
RE
RK
RN
RV
SA
SB
SC
SE
SK
SU
UE
WA
WE
WI
WL
WN
Description
Vendor Invoice
Vendor payment
ML Settlement
Price Change
Sub.Cred.Memo Stlmt
Invoice - Gross
Invoice Reduction
Invoice - Net
Billing doc.transfer
G/L Account Document
G/L Account Posting
Transfer P&L to B/S
Inventory Postings
Cash Document
Intercomp./Clearing
Data Transfer
Goods Issue
Goods Receipt
Inventory Document
Goods Issue/Delivery
Net Goods Receipt
Table 4:1 Default Document Types
If you want to delete any of the already available document types in system, check if it
is currently being used. If already in use, you will not be able to delete those document types.
Project Dolphin
BESTM does not want to define any new document type, and has decided to use the standard
ones available in the system. It has also been decided to use the same document type for
document reversals. To restrict the access to the closing operations, BESTM wants to make
use of user authorization through document type CL. To make cross-verification easier, the
project team has recommended to the BESTM management to make the ‘Reference’ field
mandatory for data input for invoice postings (customer and vendor) and credit memos.
Let us configure the settings relating to document types.
102
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Since BESTM does not want to have any new document types, we do not need to configure
this activity for Project Dolphin. However, we have given the details below to make you
understand how to create a new one:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Define Document
Types. Or, you may use Transaction OBA7.
On the ‘Change View “Document Types”: Overview’ screen, select the appropriate
row containing the standard document type (say, ER).
Click on ‘Copy As’. You will be taken to the ‘Change View “Document Types”: Details
of Selected Set’ screen:
• Change the ‘Document Type’ from ER to a new identifier; say, YR.
• You can now keep the ‘Number range’ proposed by the system; or, change it
to a new one by maintaining the required number range for the company
code by clicking on ‘Number range information’.
• Enter the ‘Reverse Document Type’: if you want the same document type for
the reversal documents also, you can just leave that as blank. You may also a
enter a different document type.
• Leave the ‘Authorization Group’ as blank, or enter the group identifier should
you wish to control the document entry for select group of users.
• Select the appropriate check-boxes (say: vendor, G/L account etc) under
‘Account types allowed’ and ‘Control data’ blocks.
• You may also maintain other details like ‘Reference Number’ and ‘Document
Header Text’: if you select these check-boxes, then the system will expect an
input for these fields while posting this document.
‘Save’ when completed. You have now created the new document type YR. You need
to go back to the initial screen to change the ‘Description’. ‘Save’ again (Figure 4.1).
Figure 4.1: New Document Type (YR)
Now that you have understood how to create a new document type, let us move on to
configure the specific requirements of BESTM for the various document types:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Incoming Invoices/Credit Memos
ii.
iii.
iv.
103
Invoices/Credit Memos > Make and Check Document Settings > Define Document
Types. Or, you may use Transaction OBA7.
On the ‘Change View “Document Types”: Overview’ screen, select the appropriate
row containing the standard document type (say, CL).
Click on ‘Details’. On the next screen, enter the desired ‘Authorization Group’ under
the ‘Properties’ block. The authorization group allows extended authorization
protection for particular objects. The authorization groups are freely definable. The
authorization groups usually occur in authorization objects together with an activity.
Enter B100. (You have to create this authorization group in the specific authorization
object, and attach the required users to this authorization group to make this
effective). ‘Save’.
Now, go back to the initial ‘Change View “Document Types”: Overview’ screen,
double-click on the row DR. On the next screen, select the ‘Reference Number’ checkbox under ‘Required during document entry’ block, and ‘Save’ (Figure 4.2).
Figure 4.2: Making ‘Reference Number’ as Required Entry for Document Type DR
104
v.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Repeat the steps and select the ‘Reference Number’ check-box for the remaining
document types (KR, DG and KG).
You have now made the ‘Reference Number’ (displayed as ‘Reference’ in the document
header) as a mandatory field for data entry for document types DR, KR, DG and KG as required
by BESTM management. With this let us move on to discuss the posting keys.
4.1.2 Define Posting Keys
The ‘posting key’ controls how a line item is entered and processed in a document. You will
specify a posting key, for each of the line items in a document. For each posting key, you will
define (a) which side of an account it can post to, (b) which type of account it can post to and
(c) which fields the system should display on the entry screen and whether an entry must be
made (field status). SAP comes delivered with several standard posting keys (Table 4.2).
Posting
Key
01
02
03
04
05
06
07
08
09
0A
0B
0C
0X
0Y
0Z
11
12
13
14
15
16
17
18
19
Name
Invoice
Reverse Credit Memo
Bank Charges
Other receivables
Outgoing payment
Payment difference
Other clearing
Payment clearing
Special G/L debit
Bill.doc. Deb
CH Cancel.Cred.memoD
CH Clearing Deb
CH Clearing Cred
CH Credit memo Cred
CH Cancel.BillDocDeb
Credit memo
Reverse invoice
Reverse charges
Other payables
Incoming payment
Payment difference
Other clearing
Payment clearing
Special G/L credit
Cr/Dr
Indicator
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Credit
Credit
Credit
Credit
Credit
Credit
Credit
Credit
Credit
A/c Type
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Reversal
Key
12
11
13
14
15
16
17
18
19
1A
1B
1C
1X
1Y
1Z
02
01
03
04
05
06
07
08
09
Incoming Invoices/Credit Memos
1A
1B
1C
1X
1Y
1Z
21
22
24
25
26
27
28
29
31
32
34
35
36
37
38
39
40
50
70
75
80
81
82
83
84
85
86
89
90
91
92
93
C CH Cancel.Bill.docDe
CH Credit memo Deb
CH Credit memo Deb
CH Clearing Cred
CH Cancel.Cr.memo C
CH Bill.doc. Cred
Credit Memo
Reverse invoice
Other receivables
Outgoing payment
Payment difference
Clearing
Payment clearing
Special G/L debit
Invoice
Reverse credit memo
Other payables
Incoming payment
Payment difference
Other clearing
Payment clearing
Special G/L credit
Debit entry
Credit entry
Debit asset
Credit asset
Inventory taking
Costs
Inventory difference
Price difference
Consumption
Change in stock
GR/IR debit
Stock inward movement
Inventory taking
Costs
Inventory difference
Price difference
Credit
Credit
Credit
Credit
Credit
Credit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Credit
Credit
Credit
Credit
Credit
Credit
Credit
Credit
Debit
Credit
Debit
Credit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Debit
Credit
Credit
Credit
Credit
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Customer (D)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
Vendor (K)
G/L (S)
G/L (S)
Assets (A)
Assets (A)
G/L (S)
G/L (S)
G/L (S)
G/L (S)
G/L (S)
G/L (S)
G/L (S)
Material(M)
G/L (S)
G/L (S)
G/L (S)
G/L (S)
105
0A
0B
0C
0X
0Y
0Z
32
31
34
35
36
37
38
39
22
21
24
25
26
27
28
29
50
40
75
70
90
91
92
93
94
95
96
99
80
81
82
83
106
94
95
96
99
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Consumption
Change in stock
GR/IR credit
Stock outward movement
Credit
Credit
Credit
Credit
G/L (S)
G/L (S)
G/L (S)
Material (M)
84
85
86
89
Table 4:2 Default Posting Keys
(The standard SAP posting key for account assignment model is 00)
It is strongly recommended to use the SAP supplied standard posting keys, without
resorting to creating new ones.
Project Dolphin
BESTM does not want to define any new posting keys in the system, as the project team has
explained to the management that the standard keys supplied by SAP will be good enough to
meet the business processing requirements of the company. However, BESTM has requested
to configure the posting keys in such a way that (a) 'Invoice Reference' to be made mandatory
for all payment transactions, (b) 'Payment Reference' is optional for document reversals and
(c) a valid reason to be mandatory for all payment difference postings.
You may not need to define a new posting key in the system. However, should you want to
create a new posting key:
Figure 4.3: Standard Posting Keys
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Incoming Invoices/Credit Memos
ii.
iii.
107
Invoices/Credit Memos > Make and Check Document Settings > Define Posting Keys.
Or, you may use Transaction OB41.
On the ‘Maintain Accounting Configuration: Posting Keys – List’ screen, you will see
the list of SAP supplied standard posting keys that are already available in the system
(Figure 4.3), arranged according to the account type.
Double-click on any of the rows, to see the details of the configuration settings for
that posting key (Figure 4.4) on the ‘Maintain Accounting Configuration: Posting Keys
– Details Screen’:
Figure 4.4: Settings for a Posting Key
•
•
•
You will see the ‘Debit/credit Indicator’ indicating to which side of the
account the posting key posts to.
You will also see the ‘Account type’ indicating to which account, the key posts
to. Each posting key can be used for a specific account type. In setting the
account type indicator, you specify whether the document type is valid for
asset accounts (A), material accounts (M), customer accounts (D), vendor
accounts (K), or G/L accounts (S).
You will see other details including the ‘Reversal Posting Key’ and whether
this relates to ‘Payment Transaction’.
108
iv.
v.
vi.
vii.
viii.
ix.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Click on ‘Create’ on the initial ‘Maintain Accounting Configuration: Posting Keys – List’
screen, to define a new posting key.
On the ensuing ‘Create posting key’ pop-up screen, enter an identifier for the new
posting key in ‘Posting Key’ field, and input an explanation in ‘Posting Key Name’.
Click ‘Enter’.
On the next ‘Maintain Accounting Configuration: Posting Keys – Details Screen’,
maintain the settings as already discussed in step (iii).
Now, click on ‘Maintain Field Status’ and make the required settings for the new
posting key, for each category under the ‘Select Group’ block.
‘Save’ the entry; you have now created a new posting key along with the appropriate
field status setting for that key.
Let us look at configuring the specific requirements for BESTM for some of the posting keys:
since(a) 'Invoice Reference' is to be made mandatory for all payment transactions, (b)
'Payment Reference' is to be made optional for reversals and (c) a valid reason is to be
mandatory for all payment difference postings, we need to make the changes in field status
as described in Table 4.3:
Transaction
Outgoing payment
(Customer)
Incoming payment
(Customer)
Outgoing payment
(Vendor)
Incoming payment
(Vendor)
Reverse credit
memo (Customer)
Reverse invoice
(Customer)
Reverse invoice
(Vendor)
Reverse credit
memo (Vendor)
Payment difference
(Customer)
Payment difference
(Vendor)
Posting Field Name
Key
Invoice Reference
05
15
25
35
Invoice Reference
Invoice Reference
Invoice Reference
Default Field
Status
Field Status for
BESTM
Optional entry
Required entry
Optional entry
Required entry
Optional entry
Required entry
Optional entry
Required entry
02
Payment Reference
Suppressed
Optional Entry
12
Payment Reference
Suppressed
Optional Entry
22
Payment Reference
Suppressed
Optional Entry
32
Payment Reference
Suppressed
Optional Entry
06
Reason Code
Optional entry
Required entry
26
Reason Code
Optional entry
Required entry
Table 4:3 Field Status Configuration for Posting Keys for BESTM
Incoming Invoices/Credit Memos
109
To make the required changes for BESTM:
i.
ii.
iii.
iv.
v.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Define Posting Keys.
Or, you may use Transaction OB41.
On the ‘Maintain Accounting Configuration: Posting Keys – List’ screen, double-click
on the row containing the posting key 05.
On the next ‘Maintain Accounting Configuration: Posting Keys – Details Screen’, click
on ‘Maintain Field Status’.
On the ‘Field Status Group: Overview’ screen, double-click on ‘General data’ FSG
under the ‘Select group’ block.
On the ‘Field Status Group: General Data’ screen, change the ‘Invoice Reference’ radio
button from ‘Opt. entry’ to ‘Req. Entry’ and ‘Save’ (Figure 4.5)
Figure 4.5: Settings for Posting Key 05
vi.
vii.
Repeat the steps for making the required changes for posting keys 15, 25 and 35.
Now, you have made ‘Invoice Reference’ as a mandatory field for all the payment
transaction postings.
You need to repeat the steps above for configuring the other posting keys:
• For posting key 02, 12, 22 and 32 you will see that the ‘Payment Reference’
field is available under the FSG ‘Payment transaction’ under the ‘Select group’
block, on the ‘Field Status Group: General Data’ screen. You will see that the
110
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
field ‘Payment Reference’ is having a default field status as ‘Suppress’; you
need to change that to ‘Opt. entry’ (Figure 4.6)
Figure 4.6: Settings for Posting Key 02
•
For posting keys 06 and 26, we need to make the field ‘Reason Code’ as a
mandatory for input.
Figure 4.7: Field Status Settings for Posting Key 06
You will see that this field is available under the FSG ‘Payment transaction’
under the ‘Select group’ block, on the ‘Field Status Group: General Data’
Incoming Invoices/Credit Memos
111
screen. You will see that the field is having a default field status as ‘Opt.
entry’; you need to change that to ‘Req. Entry’ (Figure 4.7).
We have, thus, configured posting keys as required by BESTM. This completes our discussion
on posting keys. Let us now understand configuring validation in accounting documents.
4.1.3 Validation in Accounting Documents
Here, you can define ‘additional checks for accounting documents’ in the form of validations,
for each of your company codes. You can assign a validation for the document header and
also for the line items, per company code. Once assigned, the validations will be valid both
for manual entry of documents as well as for the automatic creation of documents (for
example, payment program).
While configuring, for every company code to which you want to assign a validation, you need
to store (a) validation callup point (enter 1 for checking the document header, and 2 for
checking line item), (b) validation and (c) activation level ( 0 indicates inactive validation, 1
denotes that the validation is active and 2 indicates that the validation is active except for
batch input).
Project Dolphin
BESTM wants it build additional check for accounting documents in the form of ‘validation’,
wherein it needs to be ensured that no user will be able to enter an incorrect business area
in each of the company codes. The company code-wise business areas are shown in Figure
4.8.
Figure 4.8 Company Code – Business Area Relationship, for BESTM Group
112
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
To configure a new validation:
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Validation in Accounting
Documents. Or, you may use Transaction OB28.
On the resulting screen click on ‘New Entries’ and maintain the details as under:
i.
ii.
Enter the company code (say, 1110) in ‘CoCd’ and select a callup pint (‘Callpnt’). Select
0002 for line item validation (other values are: 0001 document header and 0003
entire document), as we need to validate the value of business area during line item
entry itself.
Now, select ‘Environment > Validation’ on the menu bar. The system brings up the
‘Change Validation: Overview’ screen (Figure 4.9).
Figure 4.9 Change Validation: Overview Screen
iii.
Click on ‘Create Validation’. On the next screen, enter an identifier (say, BMBAV1) for
the new validation and provide a name (‘Validation Name’).
Incoming Invoices/Credit Memos
iv.
113
Click on ‘Step’. The system creates a new ‘Validation Step’ 001. You may enter a name
for this step (Figure 4.10).
Figure 4.10 Create Validation: Creating a Step
v.
Now, click on ‘Prerequisite’ on the left-hand side ‘Validations’ pane. The system
brings up the next screen ‘Create Prerequisite BMBAV1: Step 001’ screen (Figure
4.11). Enter the prerequisite for the validation. For example, you may mention that
the company code should be 1110. Towards this, you need to enter the condition
BKPF - BUKRS = ‘1110’.
• On this screen, below the grey text box at the top, you will see ‘Table Fields’
/ ‘Rules’ / ‘Exits’, ‘Status’ and a few buttons for entering the condition.
• Double-click on ‘Accounting Document Header’ under ‘Table Fields’, and
scroll down till you see the field ‘Company Code’. Double-click on that and
the system enters the field name in the top ‘Prerequisite’ text box.
• Now, click on ‘=’.
• Now, click on ‘Constant’. The system brings up a pop-up screen for entering
the company code; enter 1110. Press ‘Continue’. The system adds the
constant to the equation in the text box above. At this point, you may notice
that the ‘Status’ is green (Figure 4.11).
114
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 4.11 Create Validation: Creating Prerequisite
vi.
vii.
viii.
Now, if you click on ‘Step 001’ on the left-hand side pane, the system brings up the
‘Create Validation BMBAV1: Step 001 - Overview’ screen.
Double-click on ‘Check’ and the system brings up the ‘Create Check BMBAV1: Step
001’ screen. Follow the steps listed in (v), and complete building up of the check for
the validation step: Business Area = 'ATRA' OR Business Area = 'GEQP' OR Business
Area = 'AEQP' OR Business Area = 'FEQP' OR Business Area = 'ASER'.
Now, click on ‘Step 001’ on the left-hand side pane, the system brings back the ‘Create
Validation BMBAV1: Step 001 - Overview’ screen. You will see now that both the
‘Prerequisite’ and ‘Check’ boxes are filled with the conditions that you entered (Figure
4.12).
Incoming Invoices/Credit Memos
115
Figure 4.12 Create Validation: Prerequisite and Check Configured
ix.
x.
xi.
xii.
The final step is to define the message, for the validation result. Double-click on
‘Message’ on the left-hand side pane.
You will reach the ‘Create Validation BMBAV1: Step 001 - Message’ screen. Under
‘Message (Output if prerequisite is met and check is NOT fulfilled)’ enter the ‘Message
number’ and adapt or create the appropriate message text.
If you click on ‘Step 001’, now, on the left-hand side pane, the system brings back the
‘Create Validation BMBAV1: Step 001 - Overview’ screen, and you will see that all the
three requirements (prerequisite, check and message), for Step 001, have now been
completed.
‘Save’ the details (Figure 4.13).
116
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 4.13 Create Validation: Fully Configured Step
xiii.
Now, go back to the initial screen wherein you started creating the new validation.
Select the newly created ‘Validation’ and assign the activation level (1) in ‘Actvn level’
field. And, ‘Save’ the details (Figure 4.14).
Figure 4.14 New Validation in Accounting Documents
xiv.
You can build similar validations for business area, for other company codes of
BESTM.
This completes our discussion on defining validation in accounting documents. With this, let
us move on to the next activity of defining the default values for documents.
4.1.4 Define Default Values
You may define the default document type and posting key for a Transaction (like, F-02, F-05,
F-31, F-47 etc), so that you do not need to enter them during document entry. For example,
when posting customer invoices (Transaction F-22), you need to use the document type DR
and posting key 01. You can store this information using this configuration step, so as to make
Incoming Invoices/Credit Memos
117
the system to propose them, when you call up the relevant Transaction. This is a cross-client
customizing step and is valid across the clients.
You can use SAP’s default settings (Figure 4.15) as such that cover most of the Transactions.
Figure 4.15: Default Values: Document Type and Posting Key
Project Dolphin
The project team, as suggested by BESTM, will not make any change to the SAP standard
defaults relating the document type and posting key for the common transactions.
However, if you want to change the defaults, use the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Business Transactions > Incoming Invoices/Credit Memos > Make and Check Document
Settings > Define Default Values. Or use Transaction OBU1. To change the defaults, doubleclick on a row and make changes on ‘Change Default Values’ pop-up screen.
Do not to change the default values provided by SAP for any of the Transactions.
The next step is to define the field status variants.
118
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
4.1.5 Define Field Status Variants
Before discussing ‘field status variant’ (FSV), let us first understand what is a ‘field status’, and
what is a ‘field status group’ (FSG). As you might be aware of, every field has a ‘status’ which
controls the behaviour of that field on a screen: whether it is displayed or hidden
(suppressed), and whether that field is a required (mandatory) or optional for data entry.
Hence, the ‘field status’ refers to the characteristic or behaviour of a field on a data entry
screen as to its display and/or receiving a data entry input. Though all fields on a form will
normally have a field status, there are some fields - for example, fields on a document header
- for which you cannot attach a field status; however, you can define some fields from the
document header also as ‘required’ or ‘optional’ fields in the document type.
Keep only the most important fields as ‘required entry’ or ‘suppressed’, with all others
as ‘optional entry’ to prevent unnecessary issues while transaction entry.
A ‘field status group’ (FSG) is a collection of field statuses, defined in the company code data
of G/L account, and is used to determine which fields are ready for data entry input
(required/mandatory or optional), and which needs to be hidden. By default, every field is
displayed; only by applying one of the three statuses, you decide if that field needs to be
required one, optional or suppressed (hidden). Additional account assignments (for example,
cost centers or orders), if any, are only possible if the corresponding fields are ready for input.
The FSG that you enter in the reconciliation accounts affects the corresponding customer /
vendor accounts when posting.
In addition to the FSG, the other factors that influence the field status are the (a) posting key
and (b) document type. The status ‘optional entry’ field has been assigned to the standard
G/L account posting keys 40 and 50 in the standard SAP system. As regards document type,
you can – for example - specify that a ‘reference number’ and a ‘document header’ must
always be entered. There are several FSGs defined in the standard SAP system, all starting
with ‘Y’: for example, YB01 (General with text & assignment), YB05 (Bank Accounts), YB29
(Revenue Accounts) and so on (Figure 4.16).
Each FSG is made up of sub-groups that include general data, additional account assignments,
materials management, payment transactions, asset accounting, taxes, foreign payments,
consolidation, real estate management and financial assets management that group the
associated fields. You will see sub-groups in both blue and black letters: the fields in black
groups will all have the ‘suppressed’ field status because they are not relevant to that
particular FSG.
Incoming Invoices/Credit Memos
119
Figure 4.16 Standard Field Status Groups (FSG)
Make sure that you control the field status properly through posting keys and FSGs; conflicting
field statuses between an FSG attached to an account and the FSG attached to the underlying
posting keys may result in chaos. If not properly controlled, you will end up with a situation,
for example, wherein you would have inadvertently assigned both ‘suppressed’ and ‘required
entry’ statuses to the same field. SAP uses ‘link rules’ to overcome this conflicting situation.
The details of the link rules are outlined in Figure 4.17: when one field status is ‘suppressed’
and the other is ‘optional entry’, the resulting field status is always ‘suppressed’. A
combination of ‘suppressed’ and ‘required entry’ always result in an error due to conflict.
Hence, the link rule determines what should be the final status of a field if there are two
conflicting statuses for the same.
You cannot directly enter an FSG in customer / vendor accounts; they are determined
from their respective reconciliation accounts (via the G/L account number), in their respective
master records.
You group several FSGs in one field status variant (FSV), and then assign that FSV to a company
code. By this, you will be able to work with the same FSGs in multiple company codes. These
FSVs use FSGs to specify which fields are ready for input, which fields must be filled, or which
fields are suppressed (hidden) when entering postings.
120
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 4.17 SAP Link Rules to resolve conflicting Field Statuses
With this we are now ready to define the FSV.
As in other customizing objects, SAP comes delivered with a standard FSV (0010). Look at that
and decide if you really need a new one. The easiest way to create a new one, is to copy a
standard FSV, make the changes in the field statuses to suit your need.
Project Dolphin
The Dolphin Project implementation team has decided to use a single FSV across all the
company codes of BESTM. They have further recommended that (a) ‘Business Area’ and
‘Functional Area’ fields to be set as ‘required’ for data entry, and (b) ‘Payment Reference’ field
to be set as ‘optional entry’ field so as to enable the users to input payment reference, if any,
while undertaking the payment transactions.
Incoming Invoices/Credit Memos
121
Let us now define the FSV for BESTM:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Define Field Status
Variants. You may also use Transaction OBC4.
On the ‘Change View “Field status variants”: Overview’ screen, select the FSV row
0010, and click on ‘Copy as’ button.
You will now be taken to ‘Change View “Field status variants”: Overview of Selected
Set’ screen. Rename the ‘FStV’ (say, B100) and ‘Field Status Name’ fields to suit your
naming conventions.
Press ‘Enter’ and go ahead with ‘Copy All’; the system completes copying all the
dependent entries; they are nothing but the FSGs associated with this FSV. ‘Save’
(Figure 4.18).
Figure 4.18 Defining FSV ‘B100’ for BESTM
v.
vi.
Now, select the row containing the FSV B100. You can double-click on ‘Field status
group’ folder on the dialog-box on the left pane.
You are now looking at the ‘Change View “Field status groups”: Overview’ screen. You
can see all the FSGs associated with the FSV B100, on the right-hand side of the dialog
box (Figure 4.19).
Figure 4.19 FSGs associated with FSV ‘B100’
122
vii.
viii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Double-click on the FSG ‘YB01’. You will reach ‘Maintain Field Status Group: Overview’
screen; double-click on ‘Additional account assignments’ under ‘Select Group’ block.
On the next screen ‘Maintain Field Status Group: Additional account assignments’,
you will see that the fields ‘Business Area’ and ‘Functional Area’ have ‘suppressed’
field status at this point of time. Since, you need to make them ‘required’ for BESTM,
select the ‘Req. Entry’ radio button against these fields.
Figure 4.20 Field Status change for ‘Payment Reference’ field
ix.
‘Save’, and you are taken back to ‘Change View “Field status groups”: Overview’
screen. Now, double-click on the FSG YB09 {Bank accounts (obligatory due date)}, on
the next screen double-click ‘Payment transactions’ group, and change the
‘suppressed’ field status of ‘Payment Reference’ to ‘optional entry’ by selecting the
‘Opt. entry’ radio button against this field. And, ‘Save’ (Figure 4.20).
You have now defined the FSV ‘B100’ and made the required field status changes to some of
the fields as required by BESTM. Now, we are ready to assign this FSV to the company codes.
4.1.6 Assign Company Code Field Status Variants
Now that we have defined the FSV in the previous Section 4.1.5, it is time we assign the
company codes to this FSV, so that they can use the variant. As already indicated, you can use
the same FSV across multiple company codes:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Incoming Invoices/Credit Memos
ii.
123
Invoices/Credit Memos > Make and Check Document Settings > Assign Company Code
to Field Status Variants. You may also use Transaction OBC5.
On the ‘Change View “Assign Company Code -> Field Status Variant”: Overview’
screen, select the FSV ‘B100’ under the column ‘Fld stat. var.’ against the appropriate
company codes (1110, 1120 etc) and ‘Save’. You have now assigned the company
codes to the FSV (Figure 4.21).
Figure 4.21 FSV – Company Code Assignment
You can also assign the FSV to a company code while maintaining the company code
global parameters (Transaction OBY6).
Let us now move on define subscreens for coding blocks.
4.1.7 Define Subscreens for Coding Blocks
The account assignment transactions, in SAP, use subscreens containing the various account
assignment fields. The system, when generating the data entry screens for these transactions,
searches for the most suitable subscreen (containing the most ‘required’ fields), and brings
up that for data entry. If there is no such subscreen that contains all the necessary fields, the
system will force you to enter the additional fields in a separate dialog box. By defining your
own subscreens, you can structure these subscreens to suit your own requirements, thereby
avoiding the need to enter the account assignment fields in an additional dialog box.
As this is a client-independent configuration activity, note that any changes you make
here will apply in all clients and for all the transactions that use that particular coding block.
You will need the authorization S_TABU_CLI to maintain the subscreens.
We will not be defining any new subscreen for BESTM; however, let us see the steps should
you decide to create a new subscreen:
i.
To define your own subscreens, use the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Incoming Invoices/Credit Memos > Make and Check Document
Settings > Define Subscreens for Coding Blocks. You may also use Transaction OXK1.
124
ii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the ‘Maintain Coding Block Subscreens: Overview’ screen, you will see all the
standard SAP subscreens, listed in a table. On this screen, note that you can either
create your own subscreens or change the one already defined in the system.
However, you will be able to change only the ‘Priority’ and ‘Active’ flag on the SAP
supplied subscreens, and nothing else. As already mentioned, the system searches
through the existing subscreens for the one which fulfils most of the requirements,
using the values entered in the ‘Priority’ field which serves to fine tune the search: 1
is the highest priority, 9 the lowest. The logic of search is: (a) first, it searches for
subscreens containing all ‘required’ account assignment fields; if there is more than
one, it selects the one with the highest priority, (b) if that is unsuccessful, the system
then looks for subscreens containing all of the ‘optional entry’ fields, or as many of
them as possible; the subscreen containing the most ‘optional entry’ fields is selected,
and (c) if two subscreens contain the same number of ‘optional entry’ fields, then the
one containing the most ‘required’ account assignment fields is selected; if there is
still more than one, the selection is made according to the priority.
You can use a subscreen in the individual account assignment transactions only
when the ‘Active’ flag is set. Since you cannot delete SAP supplied subscreens, you
can deactivate them using this flag, enabling the system to use your own subscreens
instead of the standard one.
iii.
iv.
If you want to define new a subscreen, click on the ‘Create’ button on the initial
‘Maintain Coding Block Subscreens: Overview’ screen.
On the ‘Maintain Coding Block Subscreens: Details’ screen, maintain the details:
• Enter the number for the ‘Subscreen’, the number can be anything between
9000 and 9999; note that system proposes ‘9000’ if you have not created a
new subscreen earlier. And, enter the name for the subscreen in the adjoining
text field.
When numbering the new subscreens, note to use the numbers
between 9000 and 9999 for your own subscreens. SAP will not allow a
numbering between 0001 and 8999 as this range is used for SAP delivered
subscreens.
•
•
•
Set the ‘Priority’, any value between 1 and 9; by default, system proposes 9.
Select the ‘Active’ flag; unless you activate, you cannot use the newly defined
subscreen.
Enter the field’s starting position in ‘Position’ against the fields listed on the
left. Each subscreen can accommodate a maximum of 10 fields. The positions
Incoming Invoices/Credit Memos
•
125
are numbered from 1 (1st line left) to 10 (5th line right). For certain fields,
you can display master data texts for the field values; for this, select the ‘With
text’ check-box. In such cases, note that, you will need an entire row for that
field.
‘Generate’ and ‘Save’, when completed (Figure 4.22). The system, now, adds
this new subscreen under ‘Customer Subscreens’ on the initial ‘Maintain
Coding Block Subscreens: Overview’ screen.
Figure 4.22 Defining a new Subscreen for Coding Block
This completes our discussion on defining new subscreen. Let us move on to define screen
variants for document entry.
4.1.8 Screen Variants for Document Entry
The ‘screen variant’, specified per company code, controls the special screens (if any) for
documents, for several specific functions. We have already seen, while configuring the
company code global parameters, that SAP comes delivered with four standard variants for
document entry (Table 4.4):
Variant
1
2
3
Description
Standard version
For Austria and Switzerland
For France and countries with withholding tax
Countries with classic withholding tax
Table 4:4 Standard Screen Variants for Document Entry
We have already configured this for company code 1110 with screen variant 2, as this variant
will be the most suitable one for all the US-based company codes. Since we used this company
code to copy to other US-based company codes like 1120, 2100 etc, this configuration has
already been completed. For company codes in India, the standard version is the right one.
126
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
However, to assign/change the screen variant for document entry, then:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Screen Variants for
Document Entry.
On the ‘Change View “Document Entry Screen Variant”: Overview’ screen, select the
appropriate screen variant for the company codes, and ‘Save’ (Figure 4.23).
Figure 4.23: Screen Variant for Document Entry
Let us now move on to discuss substitution in accounting documents.
4.1.9 Substitution in Accounting Documents
Similar to that of ‘validation’ in accounting documents that we discussed in Section 4.13, you
can define ‘substitution’ to replace of the field contents, per company. Here also, you can
make changes both in the document header and in the line item, and the defined
substitutions will be valid for both the manual entry of documents and for the automatic
creation of documents (for example, payment program). In each of the company codes to
which you plan to assign substitution, you need to define the (a) time of substitution (within
the document header, within the line item level or for the whole document), (b) details of the
substitution and (c) activation.
Project Dolphin
BETM wants to derive the value of ‘Region’ from ‘State’ for all both US-based and India-based
company codes.
To configure a new validation:
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Substitution in Accounting
Documents. Or, you may use Transaction OBBH.
The configuration step is similar to that validation. You shall define the prerequisite and, then,
complete the substitution rule, if the prerequisite is met (Figure 4.24).
Incoming Invoices/Credit Memos
127
Figure 4.24: Substitution in Accounting Documents
The next activity is to define the text IDs for documents and line items.
4.1.10 Text IDs for Documents and Line Items
It is possible that you can define text IDs for both document header and line items, to store
additional or detailed information for a document header or for the line items during
document entry, as you cannot have all the information stored in the long text field:
Figure 4.25: Using Text IDs in Document Header
•
In the case of ‘text IDs for a document’, you define the text IDs for the long texts.
During document entry, you can enter detailed texts for a text ID by calling the ‘Texts
in Accounting Document’ pop-up screen (Extras > Document texts) and proceeding
further (Figure 4.25) to store additional information relating to the document by
128
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
clicking on ‘Detailed text’ on the pop-screen: a text editor opens up and you can enter
the details therein for a later reference. When you maintain additional information,
you will see that the check-box ‘M’ selected on the pop-up screen indicating that
there are more texts available.
Similar to the text IDs for the document, you can also create the ‘text IDs for the line
items’ to note down additional information for that particular line item. This is over
and above the line item text that you will enter during a line item entry. During
document entry, when you are entering the line items, you can click on the ‘Long Text’
icon for a line item, and you will see a pop-up screen displaying the text IDs. You may
click on ‘Editor’ to input additional details. When done, you will see that the checkbox ‘T’ selected, on the pop-up, indicating that there are more texts for this line item
(Figure 4.26).
Figure 4.26: Using Text IDs in a Line Item
•
You can also define text identifiers (also known as ‘keys’) for line items, which you
can enter in the line item text field, instead of inputting the details to save time. The
actual texts associated with the text key will transferred, later, to the line item.
Let us first see how to define the text IDs for documents
Incoming Invoices/Credit Memos
129
4.1.10.1 Define Text IDs for Documents
The text IDs defined for documents are valid across the system, and SAP comes delivered with
a number of text IDs which you can make use of. If you want to define new text IDs:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Define Text IDs for
Documents, or Transaction OBT8.
On the ‘Maintain Text Determination Configuration: List’ screen, click on ‘Create’.
Figure 4.27: Configuring Text IDs for Document Header
iii.
iv.
v.
On the ensuing pop-up screen, enter a text ID (4 character) and provide ‘Description’.
Press ‘Enter’ to continue and the new text ID will now be added to the already
available standard text IDs provided by SAP.
Unless you select the ‘Relevant Text’ check-box for a specific text ID on the initial
screen, you will not see this screen on the document entry screen when you reach
the list the text IDs through ‘Extras > Document texts’ as already shown in Figure 4.25.
When completed, ‘Save’ your entries; you have now created new text IDs that you
can use to enter additional information for the document header while entering a
document (Figure 4.27).
4.1.10.2 Define Text Identifications for Line Items
Using this configuration activity, you can define the text identifications (text IDs) for long texts
at line item level. When you, then, enter a document, you can enter additional text or
information for each of the text ID, thereby providing more information that concerns the line
items in that particular document. As in the case of text IDs for document, these are also valid
across clients. SAP delivers one text ID as a default setting.
130
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
To define a new one:
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
Financial Accounting Global Settings > Document > Texts and Text Identifiers for
Documents > Define Text Identifications for Line Items, or Transaction OBT10.
On the ‘Maintain Text Determination Configuration: List’ screen (Figure 4.28), click on
‘Create’.
Figure 4.28: Configuring Text IDs for Line Items
iii.
iv.
v.
On the ensuing pop-up screen, enter a text ID (4 character) and provide ‘Description’.
Press ‘Enter’ to continue and the new text ID will now be added to the already
available standard text IDs provided by SAP.
Unless you select the ‘Relevant Text’ check-box for a specific text ID on the initial
screen, you will not see the list the text IDs when you click on the ‘Long Text’ icon
against a line item as already described in Figure 4.26.
When completed, ‘Save’ your entries; you have now created new text IDs that you
can use to enter additional information for the line items while entering them in a
document (Figure 4.28).
4.1.10.3 Define Texts for Line Items
Here, in this, activity, you can define texts under keys (IDs) which you can the transfer to the
line item, while processing documents. You will enter the key when you input the details in a
document (Figure 4.29). You may also use these keys to transfer the required text in the
payment notices that you send to your customers. You can also assign variables (as
placeholders for certain data like posting period, posting date etc) to the line item texts, and
the system will replace these variables by current values, during document posting (Figure
4.29).
Incoming Invoices/Credit Memos
131
Figure 4.29 Entering Text Key (ID) in Text Field
To the texts for line items:
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Define Texts for Line Items.
i.
ii.
iii.
On the ‘Change View “Line Item Text Templates”: Overview’ screen, click on ‘New
Entries’.
On the next screen:
• Enter a 4-character ‘ID’.
• In the ‘Text Edit Format’ field enter the long text (not exceeding 50
characters) that will be input in the ‘Text’ field when the user enters the ID.
The text may contain the following variables which will be replaced by the
current value:
o $BLD Document date
o $BUD Posting date
o $ZFB Baseline date for payment
o $BUP Posting period
o $XBL Reference document number
• Use the ‘Control Display’ check-box to indicate that the text transferred
during document entry is to be displayed for control purposes. This means
that when the flag is set, you can check and to adapt the text proposed as
required.
‘Save’ when completed. You have now created text keys that you can use while
entering line items in a document to quicken document entry (Figure 4.30).
132
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 4.30 Line Item Text ID
The Figure 4.29 shows that you have entered the text ID B101 in the line item ‘Text’ field
(=B101). When you post the document, the system populates the ‘Text’ field with the actual
text, for the text ID B101, along with the value for the variable (in this case $XBL) as shown in
Figure 4.31.
Figure 4.31 Text ID replaced by Actual Text together with the value of Variable
The next activity is to define line layout for document posting overview.
Incoming Invoices/Credit Memos
133
4.1.11 Define Line Layout for Document Posting Overview
If you do not want to use the default line layouts for document posting, you can define, here,
the new line layout variants you want for document posting. While doing so, you need to
specify which information (like document number, account number, company code etc.) you
want to have onscreen. While defining the new variant, you can also assign a display format
to each of the fields.
Project Dolphin
The project team has suggested not to define any new line layout for document posting, or
change / display; instead, they recommended to use the standard ones supplied by SAP.
Since BESTM does not need any new line layout to be defined for document posting, we are
not defining any new line layout variant. However, should you want to define a new one, use
the menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Incoming Invoices/Credit Memos
> Make and Check Document Settings > Define Line Layout for Document Posting Overview.
Or, you may also use Transaction O7Z2.
With this, let us move on to define line layout for document change / display.
4.1.12 Define Line Layout for Document Change/Display
As in the previous section, you will define new line layout variants for document change /
display, only when SAP supplied standard ones do not fulfil your requirements. SAP provides
you with three standard variants (A1, AA and CC) which you can use as such. However, if you
need to define new variants, you may copy an existing one and adapt, or define everything
anew. To do so, you may use the menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions >
Incoming Invoices/Credit Memos > Make and Check Document Settings > Define Line Layout
for Document Change/Display. Or, you may also use Transaction O7Z1 (Figure 4.32).
Figure 4.32 Standard Line Layout Variants for Document Change / Display
With this, we can now move on to discuss selecting the standard line layout for document
change / display.
134
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
4.1.13 Select Standard Line Layout for Document Change/Display
Use this configuration activity to select the standard line layout variant for (a) displaying /
changing documents and (b) displaying / processing payment proposals. When you do not
specify a variant during these functions, then, the system uses these as the default variants.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings > Select Standard Line Layout
for Document Change/Display. Or, you may also use Transaction O7V1.
On the resulting screen, you will see the standard Transaction Codes for display / change /
process various functions. Double-click on a Transaction Code to bring out the default line
layout variant for that function. If you have not defined a new line layout variant, then, you
just need to go ahead the system-proposed defaults; else, if you have defined new variants,
as outlined in the previous Section 4.1.12, then, select the appropriate one from the dropdown list. Since we have not defined any new line layout variant, we are going ahead with the
system defaults (Figure 4.33).
Figure 4.33 Selecting Default Line Layout Variant for Document Change / Display
With this, let us move on to discuss the document change rules for document header in the
next Section.
Incoming Invoices/Credit Memos
135
4.1.14 Document Change Rules, Document Header
In general, it is not recommended to try changing an already posted document, as that goes
against the document principle of maintaining and preserving the integrity of documents. The
system itself determines, for a number of fields, that you can no longer change them after
posting. This includes all the fields - like, the amount posted and the account - which are
central to the principles of orderly accounting. However, there could be instances when you
may want to change the contents of some of the fields, of an already posted document,
without undermining the document principle. SAP’s document change rules will help you in
those circumstances. Even with these rules, the system will prevent you from changing the
update objects like cost center, profit center, business area etc., in an already posted
document.
The update objects are elements in the system, for which transaction figures or line
items are updated. You shall enter them, as additional account assignments during posting.
There are two rules for changing documents: (a) rules for changing the header and (b) rules
for changing the line items.
Let us now understand the rules for changing the header.
The document change rules have special provisions only for transaction types A (down
payments) and W (bills of exchange). For all other transaction types, you will use the <blank>
rule for transaction type. If you make entries for document change rules with transaction
types other than <blank>, A or W, then the system will ignore that.
It is recommended that you do not change the default document change rules (for document
header) which you can display using the menu path: SAP Customizing Implementation Guide
> Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions
> Incoming Invoices/Credit Memos > Make and Check Document Settings > Document Change
Rules, Document Header. Or Transaction OB32. From the ‘Change View “Rules for Changing
Documents”: Overview’, you will see that you can change the contents of the fields ‘Text’
(document header text) and ‘Reference’ in a document header, even after posting (Figure
4.34)
Figure 4.34: Document Change Rules for Document Header
136
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You may use an appropriate Transaction, for example, for changing a document, like FB02.
When you call up a document, using this Transaction, the system brings up the last document
that you have posted in the system. You may press F5 to bring up the document header. On
the ‘Document Header: 1110 Company Code’ pop-up screen, you can see that the fields ‘Doc.
Header Text’ and ‘Reference’ as editable (Figure 4.35) in line with the document change rules
(for document header), that we have discussed earlier in this Section.
Figure 4.35: Document Change: Editable Fields in Document Header
The last configuration step under ‘Make and Change Document Settings’ is to maintain the
fast entry screen for G/L account items.
4.1.15 Maintain Fast Entry Screens for G/L Account Items
Here, in this activity, you can define screen templates for the fast entry of G/L account items
when posting documents. You can, for example, generate screen templates with the fields
account, amount and company code.
Incoming Invoices/Credit Memos
137
As in the case of line layout variants, you can use SAP supplied standard screen variants SAP01
and SAP02, without defining a new screen template. However, should you really need a new
screen layout for fast entry of G/L account items, use the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Business Transactions > Incoming Invoices/Credit Memos > Make and Check Document
Settings > Maintain Fast Entry Screens for G/L Account Items. Or Transaction O7E6.
On the resulting screen, you will see the standard screen variants (Figure 4.36). Click on
‘Create’ to define your own variants. Once done, do not forget to ‘activate’ the same.
Figure 4.36: Standard Screen Variants for G/L Account Items Fast Entry
This completes our discussion of configuration activities for making / changing document
settings. Let us, now, make or check the settings that are required for document parking.
4.2 Make and Check Settings for Document Parking
The settings for document parking include several configuration steps:
•
•
•
•
•
•
•
•
•
•
Define Entry Screens for Parking Documents
Create Workflow Variant for Parking Documents
Assign Company Code to a Workflow Variant for Parking Documents
Define Release Approval Groups for Parking Documents
Define Release Approval Paths for Parking Documents
Assign Release Approval Paths for Parking Documents
Assign Release Approval Procedure for Parking Documents
Define Users with Release Authorization for Parking Documents
Reset Release Approval (Customers)
Reset Release Approval (Vendors)
Let us discuss the settings one-by-one, in the following Sections.
138
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
4.2.1 Define Entry Screens for Parking Documents
As in the case of fast entry screens for G/L account items (Section 4.1.15), you can also define
entry screens for parking of documents.
Project Dolphin
BESTM wants to go with the standard default settings for parking document entry screens.
As BESTM has decided to go on with the standard settings for entry screens for parking
documents, we have not defined anything new. However, should you want to define a new
one, use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Document Settings for Parking Documents > Define
Entry Screens for Parking Documents. Or Transaction O7E4.
Let us now see how to create workflow variant for parking documents.
4.2.2 Create Workflow Variant for Parking Documents
While defining the workflow for parking documents, you can make specifications as to (a) if a
posting release is required (the system triggers a workflow within the release for posting),
and (b) the amount limit beyond which the release for payment is to take place. Once defined,
you can attach the variant(s) to the appropriate company codes. SAP comes delivered with
the standard workflow 0001 that can be copied and required changes made to suit your
requirements.
a) You will define a workflow using the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Incoming Invoices/Credit Memos > Make and Check Settings for
Document Parking > Create Workflow Variant for Parking Documents, or Transaction
OBWA.
b) On the ‘Change view “Preliminary Posting Workflow Link”: Overview’ screen, you can
highlight the row containing the variant 0001 and press ‘Copy As’. On the next screen,
enter the details:
• Provide the identifier for the workflow variant in “Workflow var.’ field (US01).
• Change the ‘Currency’ to USD if the currency is other than USD.
• Enter a ‘Name’.
c) Under ‘Preliminary posting release’, select the ‘Posting Release’ check-box if you want
to ensure that a release has to take place before a document can be posted. Do not
enter the subworkflow which we will do later when we discuss release approval later
in this Section, wherein we shall control both the document release and payment
Incoming Invoices/Credit Memos
139
release through release groups and approval paths for various payment levels (single
level, two level and three level) of control.
d) Under ‘Payment release’, set the indicator ‘Release Payts’ to ensure that a payment
release must take place before you can pay a document (if the indicator is not set, no
payment release is necessary).
e) ‘Save’ the details, and you have now created the workflow variant US01 for the
release of payment for BESTM (Figure 4.37). Repeat the steps and create another
variant, by copying US01, in the name IN01 to be used by Indian company codes of
BESTM.
Figure 4.37 Defining Workflow Variant US01
This completes our discussion on creating a new workflow variant. Let us now proceed to
assign company codes to a workflow variant for parking documents.
4.2.3 Assign Company Code to a Workflow Variant for Parking Documents
In this step, you need to assign the company codes to the workflow variant that you have
defined in the previous Section. If you do not assign a company code to a workflow variant,
then, you cannot carryout document release.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
140
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Invoices/Credit Memos > Make and Check Settings for Document Parking > Assign Company
Code to a Workflow Variant for Parking Documents, or Transaction OBWJ, to assign the
required company codes to the workflow variant (Figure 4.38).
Figure 4.38 Assigning Workflow Variant US01 to Company Code
The currency of the workflow variant and of the corresponding company codes must be
the same.
Let us now look at defining release approval groups for parking documents.
4.2.4 Define Release Approval Groups for Parking Documents
Define the release approval groups and later enter them in the master records of your
customers / vendors. You will need these approval groups for the next steps like assigning
release approval paths / release approval procedures for parking documents. Based on the
release approval path and amount specified, the system will determine the subworkflow to
be triggered by the payment release; it also determines who needs to release the payment.
Project Dolphin
BESTM wants to have separate release approval groups, for customers / vendors who have
been classified into A, B and C buckets, for parking documents.
To define new release approval groups:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Define
Release Approval Groups for Parking Documents.
On the resulting screen, click on ‘New Entries’ and create the required entries and
‘Save’ the details (Figure 4.39).
Incoming Invoices/Credit Memos
141
Figure 4.39 Release Groups
The next step is to define the release approval paths.
4.2.5 Define Release Approval Paths for Parking Documents
Define the release approval paths which you will need for the subsequent steps. Use the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Business Transactions > Incoming Invoices/Credit Memos > Make and
Check Settings for Document Parking > Define Release Approval Paths for Parking Documents.
On the resulting screen, click on ‘New Entries’ and create the required entries and ‘Save’ the
details (Figure 4.40).
Figure 4.40 Release Approval Paths
The next step is to assign release approval paths for parking documents.
4.2.6 Assign Release Approval Paths for Parking Documents
Use this activity to assign a release approval path to a combination of ‘workflow variants,
document types and release approval groups’. Unless you complete this assignment, you will
not be able to assign release approval procedures for parking documents, later.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Assign Release
Approval Paths for Parking Documents. On the resulting screen, click on ‘New Entries’ and
create the required settings for each combination of ‘workflow variant, document type,
142
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
release group and release approval path’ (Figure 4.41). Ensure to cover all the document types
for which you may require release approval.
Figure 4.41 Assigning Release Approval Paths for Parking Documents
With this, we are, now, ready to assign release approval procedures.
4.2.7 Assign Release Approval Procedure for Parking Documents
Here, you make the required settings to determine as to from which amount which release
approval procedure (also known as ‘subworkflow’) is triggered for each combination of
‘workflow variant and release approval path’. The procedure controls how the release is to
be carried out and how many release levels are to be triggered.
You may use SAP’s standard settings wherein the subworkflows are predefined, or you
may use them as reference templates to create your own.
There are three such subworkflows for document release:
1. WS10000052 (single-level release) requires only one person to release the document.
2. WS10000053 (two-level release) requires two people to release (dual control).
3. WS10000054 (three-level release) requires three people (triple control) for the release.
And, three more for payment release:
a. WS00400011 (single-level release) requires only one person to release the payment.
b. WS00400021 (two-level release) requires two people to complete the release (dual control).
c. WS00400022 (three-level release) requires three people (triple control) for the release.
Incoming Invoices/Credit Memos
143
To complete the settings:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Assign
Release Approval Procedure for Parking Documents. You may also use Transaction
OBWE.
On the ‘Change View “Subworkflow Allocation”: Overview’ screen, click on ‘New
Entries’ and on the next screen (Figure 4.42):
Figure 4.42 Assigning Release Approval Procedures for Parking Documents
•
•
•
•
•
Enter the workflow variant (‘Wrkf’).
Enter the approval path (‘APth’).
Enter the amount (‘Amount To’) up to which the release approval procedure
is to be triggered. Note that the system determines (from the parked
document) the amount in such a way that the subledger account with the
highest amount is selected.
Enter the number of release levels (‘Rel. Levels’) that you require for the
‘workflow-release approval path’ combination.
Enter the document (amount) release workflow in ‘Swf Amt Rel.’ field. For
example, if you want to have 3-level release, then, enter WS10000054.
If you do not want to use amount release, then, enter a blank workflow
template (WS2000006).
•
Also enter the appropriate payment release workflow (WS00400022) in ‘Swf
Payt Rel.’ field.
Next, you can assign the persons authorized to release at each release level.
4.2.8 Define Users with Release Authorization for Parking Documents
Using this configuration step, for each combination of ‘workflow and approval release path’,
define the levels and amount limits which can then be assigned to appropriate persons, for
144
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
effecting the required releases. For example, in the case of 3-level release, you need to have
three rows defined with the amount for each of the levels.
To define the settings:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Define
Users with Release Authorization for Parking Documents. You may also use
Transaction OBWF.
On the resulting screen, click on ‘New Entries’ and define the amount limits for each
level (‘Lv’) for each combination of workflow and approval release path (Figure 4.43).
Figure 4.43 Release Levels with Amount Limit
iii.
Now, select the desired row and choose ‘Goto -> Detail (OrgObject)’ on the menu bar
and create and/or assign the required organizational object for the level of release
(Figure 4.44). Repeat and make the settings for all the levels, and ‘Save’ the details.
Figure 4.44 Allocating Organization Object to Release Levels
The next action is to define the fields for reset release approval for customers.
Incoming Invoices/Credit Memos
145
4.2.9 Reset Release Approval (Customers)
Here, you can include the fields that are to be checked in case of changes to the customer
document. If the system detects changes to any of the fields included here, then, the system
cancels the document release and the process is reset.
Project Dolphin
The project has suggested to the BESTM management, to include fields like ‘House Bank’,
‘Tolerance Group’, ‘Payment Terms’, ‘Payment Method’, ‘Alternative Payer’ and ‘Payment
Block’ to be checked by the system. If any changes are found for these fields, then, the system
should cancel customer document release. For vendors, the fields will include ‘Alternate
Payee’, ‘Interest Indicator’, ‘House Bank’ and ‘Payment Block’.
To define the settings, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Reset Release
Approval (Customers). You may also use Transaction OBWG.
On the resulting screen, click on ‘New Entries’, select ‘Customers’ as the account type (‘Acct
type’), and enter the ‘Field name’. You may select ‘Incomplete’ check-box, if you want the
system to cancel the document release when someone attempts to change the contents of
such fields when the document is incomplete. When you do not select the ‘Incomplete’ checkbox, the system restarts the document release for such fields only when the document is
complete (Figure 4.45).
Figure 4.45 Customer Line Item Fields for Resetting Document Release
Similarly, we need to define the vendor line items fields for reset of release approval.
146
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
4.2.10 Reset Release Approval (Vendors)
Here, you can include the fields that are to be checked in case of changes to the vendor
documents. As in the case of fields that are included for reset release of customer document,
if the system detects changes to any of the fields included here, then, the system cancels the
document release and the process is reset.
To define the settings, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Make and Check Settings for Document Parking > Reset Release
Approval (Vendors). You may also use Transaction OBWH. On the resulting screen, click on
‘New Entries’ and include the required fields (Figure 4.46).
Figure 4.46 Vendor Line Item Fields for Resetting Document Release
This completes our discussion on making / checking settings for document parking. Let us now
understand terms of payment, in the next Section.
4.3 Maintain Terms of Payment
You will use the ‘terms of payment’ (or ‘payment terms’) to specify the payment conditions
when you, for example, sell on credit. You can specify conditions such as the number of days
before which the payment is to be made, whether there is a discount for early payment and
what will be the discount amount in percentage. It is a common practice to offer higher
discount with early repayments.
In SAP, using this configuration step, you can define the terms of payment in which you can
specify the rules with which the system will determine the required terms of payment
automatically. The system stores these rules using a 4-character key. Once defined, you can
assign a key in business partner’s master record. The system will, then, propose the terms of
payment under this key when you enter a document for that vendor, for example; you may
go ahead with the proposal or you can change, if required.
Incoming Invoices/Credit Memos
147
Though you may use the same key, for the terms of payment, for both customers and vendors
who needs to be associated with the same payment terms, it is recommended to use different
keys for customers and vendors thereby limiting the permitted account type within the terms
of payment itself. By this, you can – for example – change the payment term for a customer
without affecting the vendor having the same payment terms.
You may use the standard payment terms pre-defined in the system or you can create your
own to meet your business requirements.
Project Dolphin
BESTM wants to have different set of payment terms for customers and vendors so that if
there is a change that needs to be done for either customer or vendor, then, that can be
carried out without affecting the other. However, there will a single payment term that will
apply for both customers and vendors when the due date is immediate.
For customers, the three payment terms will cover a credit period of 90 days, 60 days, and 30
days.
1). BC90: 15 Days 3%, 45/2%, 90 Net (there will be a discount of 3% if paid within 15 days, 2%
discount for within 45 days and no discount beyond that).
2). BC60: 15 Days 3%, 30/2%, 60 Net
3). BC30: 15 Days 4%, 30 Net
Similar payment terms will need to be configured for vendors but the key will be changed to
BV90, BV60 etc. A common payment term B001 will also be configured for immediate
payment without any discount, and this can be used for both customers and vendors.
To configure:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Maintain Terms of Payment. You may also use Transaction
OBB8.
On the resulting screen, click on ‘New Entries’ and make the required settings on the
next screen (Figure 4.47):
148
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 4.47 Configuring Payment Terms BC90 for BESTM
•
•
•
•
•
Enter a 4-character key to identify the ‘Payment terms’.
Enter the appropriate ‘Sales text’ like ‘5 Days 3%, 45/2%, 90 Net’. When you
enter in this format, then the system automatically fills the ‘Explanations’ (at
the bottom of the screen) as ‘within 15 days 3 % cash discount’, ‘within 45
days 2 % cash discount’ and ‘within 90 days Due net’.
Enter a description in ‘Own Explanation’, if that will be different to the
automatically created explanations. Only specify such an explanation, here, if
you want to use this text instead of the automatically created ‘Explanations’
by the system.
Select the ‘Account type’: Select ‘Customers’ if this is only for customer
accounts, or ‘Vendors’ if for vendors only, and select both the check-boxes if
this will be valid for both customers and vendors.
You may maintain additional details under ‘Baseline date calculation’: if you
enter a calendar day number in ‘Fixed Day’ field, the system overwrites the
day of the baseline date for payment of the line item; an entry in the
Incoming Invoices/Credit Memos
•
•
•
149
‘Additional Month’ will be added to the calendar month of the baseline date
for payment. For example, if the baseline date is 02-15-2020, and you enter
02 in this field, then, the system calculates the baseline date as 04-15-2020.
Under ‘Pmnt block/pmnt method default’, you may enter a default value for
the payment blocking key in ‘Block Key’ field. The system proposes this block
key along with the payment terms when you enter a document. If you leave
the field as blank, then, it means, the document is free for payment.
The check-box adjacent to ‘Block Key’ controls whether the payment block is
transferred if the terms of payment key is changed in an invoice item: if set,
the system transfer the payment block from the terms of payment when the
item is first entered and also when the terms of payment key is changed; if
not set, the system only transfers the payment block from the terms of
payment when the item is first entered.
You may enter a ‘Payment Method’ associated with this payment terms. If
you want to control payment methods through customer / vendor master
record, then, leave this field as blank.
In general, you enter the default payment methods in the customer /
vendor master record. You can also enter a specific payment method to be
applied for a particular open item in the that line item. However, in case, you
want the system to apply specific payment method applied based upon
payment terms, then, you can enter the same while configuring the payment
terms in the ‘Payment Method’ field.
•
•
•
•
Similar to the ‘Block Key’ check-box, the ‘Payment Method’ check-box
controls whether the system transfers the payment method in an invoice
item, if the payment terms key is changed. If set, the system transfers the
payment method from the terms of payment when the item is first entered
and also when the payment terms key is changed. If not set, then, the system
only transfers the payment method from the terms of payment when the
item is first entered.
Select ‘Posting Date’ as the ‘Default baseline date’. Do not select the ‘No
Default Option’; otherwise, you need to enter the baseline date, manually,
every time you process a document.
Maintain the details of ‘Payment terms’ as indicated in Figure 10.51. Instead
of an entry in the ‘No. of Days’ field, you may also maintain ‘Fixed Date’ of
‘Additional Months’ in defining the payment terms.
Do not select ‘Installment Payments’ for payment terms that are associated
with normal payments.
150
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Use the menu path SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Incoming Invoices/Credit Memos > Define Terms of Payment
for Installment Payments or Transaction OBB9 to define payment terms for
instalment payment. Note to maintain a separate payment term key for
instalment payment terms (using Transaction OBB8), before getting into
Transaction OBB9. Refer Section 4.4, for more details on payment terms for
instalment payments.
•
iii.
Select ‘Rec Entries: Supplement frm Master’ check-box if you want the system
to take the payment terms in a recurring entry from the customer / vendor
master record, when there is no payment terms key available in the recurring
entry original document.
‘Save’ the settings. Repeat the steps and define the other payment terms like BC60
and BC30 for use with BESTM customers (Figure 4.48).
Figure 4.48 Payment Terms for BESTM
iv.
v.
Also define payment terms with the keys BV90, BV60 and BV30 for BESTM vendors;
in that case, select ‘Vendors’ check-box for ‘Account type’. When defining the
payment terms for vendors, you will not be able to maintain the ‘Sales text’; instead,
enter ‘Own Explanation’.
Finally, define the payment term B0001 to be used for both customers and vendors
of BESTM.
The next step is to understand how to define the payment terms for instalment payments.
Incoming Invoices/Credit Memos
151
4.4 Define Terms of Payment for Installment Payments
When you have an invoice amount that is to be divided into partial amounts (instalments)
with different due dates, then, you can use one or more payment terms to take care of the
instalment payments. For instalment payment terms, you need to determine the amount of
the instalment in percentage and the terms of payment for each instalment payment. When
posting an invoice with terms of instalment payment, then, the system generates the
corresponding number of line items as per your specifications for the instalments.
Maintain a separate terms of payment key as described in the previous Section 4.3
(Transaction OBB8) by selecting the ‘Installment Payments’ check-box. Then, define the
percentage of each instalment and assign the key of the payment terms here in this step.
Project Dolphin
For instalment payments, BESTM want the system to be configured with the payment terms
key BINS. The number of instalments will be three, with the first instalment at 20%, second at
30% and the third being 50%. All the instalments need to be paid within a maximum of 30
days, with 4% discount for early birds but within 15days.
Let us first define a new ‘payment terms’ for instalment payment for BESTM (BINS):
i.
Follow the steps listed in Section 4.3, and create a new entry: enter the payment term
key as BINS, enter an appropriate ‘Sales text’. Select ‘Customer’ check-box under
‘Account type’ and select the appropriate ‘Default for the baseline date’. Do not enter
anything, except selecting the ‘Installment Payments’ check-box. ‘Save’ the details.
As we have completed defining the new instalment payment term BINS, let us, now, configure
the instalments, and to assign the payment terms:
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Define Terms of Payment for Installment Payments. You
may also use Transaction OBB9. On the resulting screen, click on ‘New Entries’ and
make the required settings on the next screen (Figure 4.49):
Figure 4.49 Defining Installments for Payment Terms BINS
152
iii.
iv.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Repeat entering the details for other installments, and ensure that sum of all the
installments are totalling to 100%. In the case of assigning the payment terms, you
may assign different payment terms for each of the installments or assign a single one
for all the installments. ‘Save’ the details.
If you go back and open the payment term BINS, you will now see that the system has
populated the ‘Explanations’ as depicted in Figure 4.50, indicating the percentage of
instalment amount and the payment term (BC30).
Figure 4.50 Instalment Payment Term BINS - Details
Let us move on to the next configuration step to define the cash discount base for incoming
invoices.
4.5 Define Cash Discount Base for Incoming Invoices
The 'net’ discount base system of discount calculation is followed in countries like France.
When you select this check-box ’DiscBaseNet’ during this configuration activity, you enable
the system to ignore the tax amount – if any - in arriving at the discount base for calculating
the discount. The discount, now, is on the invoice amount less the tax. If you do not select
the check-box, the system includes the tax amount also in arriving at the discount base
(‘gross’). The setting here does not affect company codes where the discount calculation is
configured at the jurisdiction code level, as in US-based company codes including 1110.
Hence, leave this as blank; but select the same for India-based company codes.
When the cash discount base is 'net', note that SAP does not take into account the
freight and setup charges also. On the other hand, these charges along with the input tax,
are all considered while arriving at the discount base, when the cash discount base is 'gross'.
If the tax base is 'net', the discount base also needs to be 'net'.
Incoming Invoices/Credit Memos
153
You may use the menu path SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Invoices/Credit Memos > Define Cash Discount Base for Incoming Invoices, or Transaction
OB70 or to configure the settings (Figure 4.51).
Figure 4.51 Configuring Cash Discount Base
You can also configure this setting while configuring the company code global parameters. In
that case you will use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Financial Accounting Global Settings > Global Parameters for Company Code >
Enter Company Code Global Parameters, or Transaction OBY6, and configure the ‘Discount
base is net value’ check-box as per your requirements.
This completes our discussion of settings required for incoming invoices / credit memos.
4.6 Conclusion
Here, in this Chapter, you learned about the various configuration settings relating to the
business transaction, ‘incoming invoice’ / ‘credit memo’.
Towards that, first, you learned about the various document settings including document
types, posting keys, validation & substitution in accounting documents, fiscal status variant,
screen variant etc. In that, you learned that the ‘document type’, in SAP, is used to classify
accounting documents and distinguish between business transactions to be posted. You
learned that the ‘posting key’ controls how a line item is entered and processed in a
document. You learned that you can define ‘additional checks for accounting documents’ in
the form of validations, for each of your company codes. You learned that you can define the
default document type and posting key for various Transactions so that you do not need to
input them during document entry. You learned about field status, field status group (FSG)
and field status variant (FSV). You understood that an FSG is a collection of field statuses,
defined in the company code data of G/L account, and is used to determine which fields are
ready for data entry input (required or mandatory / optional), and which needs to be hidden.
You also learned that SAP uses ‘link rules’ to overcome conflicting field status situations. You
understood that you can group several FSGs in one field status variant (FSV), and then assign
that FSV to a company code. By this, you learned that, you will be able to work with the same
FSGs in multiple company codes. Similar to that of ‘validation’ in accounting documents, you
154
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
learned that you can define ‘substitution’ to replace of the field contents, per company and
that the defined substitutions would be valid for both the manual entry of documents and for
the automatic creation of documents. You understood that you can define text IDs for both
document header and line items, to store additional (or detailed) information for a document
header or for the line items during document entry, as you cannot have all the information
stored in the ‘long text’ field. Then, you learned about the configuration settings relating to
line layouts for document posting, change and display. You also learned about document
change rules and how to maintain the fast entry screens for G/L account items.
Then, you learned about the settings required for document parking, including the
configuration of entry screens for parking documents, creating & assigning workflow variant
for parking documents, the release approval process including release approval groups /
paths, and so on. While defining the workflow for parking documents, you learned that you
can make specifications as to whether a posting release is required, and the amount limit
beyond which the release for payment is to take place. You understood that you can attach
the workflow variant to the appropriate company codes. You also understood that you need
to define the release approval groups and later enter them in the master records of your
customers / vendors, because you would need these approval groups for the next steps like
assigning release approval paths / release approval procedures for parking documents. You
learned that, based on the release approval path and amount specified, the system would
determine the subworkflow to be triggered for the payment release. You, then, learned about
how to reset release approval, both for customers and vendors.
You, then, went on to learn ‘terms of payment’ (or ‘payment terms’) in which you specify
payment conditions such as the number of days before which the payment is to be made,
whether there is a discount for early payment etc. You also learned to set up the payment
terms including payment terms for installment payments.
Finally, you learned about defining the cash discount base for incoming invoices. You
understood that when the cash discount base is 'net', the system does not take into account
the freight and setup charges in arriving at the base. However, you learned that these charges
along with the input tax, are all considered while arriving at the discount base, when the cash
discount base is 'gross'. If the tax base is 'net', you understood that the discount base also
needs to be 'net'.
Let us, now, move on to the configuration relating to release for payment, in the next Chapter.
5 Release for Payment
W
e have, already, discussed creating the required workflow variant (US01) for
release of document / payment, in Section 4.2 of Chapter4, when we discussed
the settings for document parking. Later, we assigned this variant to all the
required company codes. And, we discussed the different steps that need to be configured
for release approval of parked documents. We configured the release approval groups (B001,
B002 and B003) and release approval paths (A, B and C), and later assigned release approval
paths to each combination of ‘workflow variant, document type and release group’; we also
assigned release approval procedures (subworkflows) for each level of release to the
combination of ‘workflow and approval path’ in which we assigned the workflow for both
document release and payment release, and finally defined the users (with appropriate
authorization) for approval of the releases.
The only activity that needs to be configured is the definition of payment block reasons for
payment release. Let us do that now.
5.1 Define Payment Block Reason for Payment Release
You will be able to differentiate why invoices are to be blocked for payment in the system, by
using ‘payment block reasons’ defined under ‘block indicators’. The payment block reasons
that you define here will be valid across company codes. Using the block indicators, you can
prevent items from being processed manually with the clearing procedures (both incoming
and outgoing payments). So, for each of the block indicators, you need to decide what
changes can be allowed in the payment proposal and whether the blocked items can always
be transferred or reversed.
The default settings in the standard system include a number of payment block reasons
like R (blocked by invoice verification’, ‘blank’ (free for payment) etc.
Project Dolphin
BESTM will be using the default payment block reasons and will not require anything new.
156
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
If you want to define new payment block reasons, follow the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Business Transactions > Incoming Invoices/Credit Memos > Release for Payment > Define
Payment Block Reason for Payment Release, or Transaction OB27.
Figure 5.1 Payment Block Reasons
On the resulting screen, click on ‘New Entries’ and, on the next screen (Figure 5.1):
•
•
•
•
Enter single-character block indicator (‘Block Ind.’), and provide a ‘Description’.
Use ‘Change in Pmnt Prop.’ check-box to indicate whether a change is allowed in the
payment proposal. When not set, you can prevent – for example – changing of the
block indicator that is set in invoice verification in the payment proposal. If set, you
enable setting a new block reason or deleting the one that is already set during
processing a payment proposal. Do not select this for FI-CA (Contract Accounts
Receivable and Payable).
If you select ‘Manual Payments Block’ check-box, then you are flagging the system
from clearing that item through manual entry of incoming / outgoing payment. This
indicator is also not relevant for FI-CA.
The ‘Not Changeable’ check-box indicates, when set, that you cannot modify the
payment block within a dialog transaction. That is, the user cannot rest the payment
block. Again, this is also not relevant for FI-CA.
This completes our discussion on release for payment.
5.2 Conclusion
You learned that you can use payment block reasons (defined under ‘block indicators’), across
company codes, to differentiate why invoices are to be blocked for payment in the system.
By this, you learned that you can prevent items (both incoming and outgoing payments) from
being processed manually with clearing procedures.
Let us move on to discuss the outgoing payments in the next Chapter.
6 Outgoing Payments
T
he outgoing payments represent the payments you make to your external business
partners (vendors or suppliers) and internal business partners (staff or group
companies). Here, in this Chapter, we will discuss the (a) global settings for outgoing
payments, the settings for (b) manual outgoing payments and (c) automatic outgoing
payments.
6.1 Outgoing Payments Global Settings
There are various global settings that you need to complete to make your system to handle
both the manual and automatic payments. These settings include:
•
•
•
•
•
•
•
•
•
•
•
Make and Check Document Settings
Define Accounts for Cash Discount Taken
Define Accounts for Lost Cash Discount
Define Accounts for Overpayments/Underpayments
Define Accounts for Exchange Rate Differences
Define Account for Rounding Differences
Define Accounts for Payment Differences with Altern. Currency
Define Accounts for Bank Charges (Vendors)
Define Posting Keys for Clearing
Enable Translation Posting
Define Payment Block Reasons
Let us start with defining / checking document settings.
6.1.1 Make and Check Document Settings
As we have already completed all tasks relating to making / checking document settings vide
Section 4.1 of Chapter 4, we are not repeating them here.
Let us, hence, start with the definition of cash discount taken (received).
158
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.1.2 Define Accounts for Cash Discount Taken
Define the G/L account number(s) for accounting the cash discount received. During open
item clearing, the system posts the cash discount to the account(s) defined here. If necessary,
you may differentiate the accounts by tax codes.
Project Dolphin
BESTM wants to have a single G/L account (70040000) to manage all cash discounts received.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Accounts for Cash Discount Taken, or Transaction
OBXU. Enter the chart of accounts (say, BEUS) on the resulting pop-up screen, and enter the
appropriate G/L accounts on the next screen (Figure 6.1).
Figure 6.1 G/L Account for Cash Discount Received
Let us move on to define the accounts for cash discount lost.
6.1.3 Define Accounts for Lost Cash Discount
Here, you will define the G/L account numbers for cash discount lost. In case of nett invoices
posted, the system automatically posts the difference between the originally calculated cash
discount and the actual cash discount received, as an expense, to this G/L account.
Project Dolphin
BESTM wants to capture the difference between the originally calculated cash discount and
the actual cash discount received, and post that difference as an expense (lost discount) to a
single G/L account (71040000).
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Accounts for Lost Cash Discount, or Transaction
Outgoing Payments
159
OBXV. For the chart of accounts BEUS, enter the appropriate G/L account on the next screen
(Figure 6.2).
Figure 6.2 G/L Account for Cash Discount Lost
Let us now define the accounts for handling over / under payments (payment differences).
6.1.4 Define Accounts for Overpayments/Underpayments
Use this configuration step to define revenue and expense G/L accounts to which the system
posts the amount if (a) there is a difference payment difference resulting from an
underpayment or an overpayment, (b) the difference is within the tolerance limits for
automatic adjustment posting and (c) the difference cannot be handled adjusting the cash
discount.
Project Dolphin
BESTM wants to use G/L account 44000000 for accounting overpayment and underpayments.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Accounts for Overpayments/Underpayments, or
Transaction OBXL. On entering the Transaction, enter the chart of accounts BEUS, and enter
the appropriate G/L account on the next screen (Figure 6.3).
Figure 6.3 G/L Account for handling Under / Over Payments
The next step is to define the G/L accounts for exchange rate differences.
160
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.1.5 Define Accounts for Exchange Rate Differences
Here, you will define G/L account numbers to which you want the system to automatically
post exchange rate differences (gain or loss) realized, when clearing open items. To enable
posting of exchange rate differences, when clearing open items of customers / vendors, you
have to specify the reconciliation G/L accounts for customers / vendors in the ‘G/L account’
field in the respective master records. To automatically post exchange rate differences, when
clearing bank sub-accounts, enter the bank sub-account number in the ‘G/L account’ field.
Using this task, you can also define the accounts for valuating open items. You can define
separate accounts, for each type of currency, to post the exchange rate differences per
currency. Once you make the first valuation run, you should not change your accounts for
valuation postings; else, you will not be able to reverse valuation postings.
Project Dolphin
The project team has recommended to use a single set of accounts to take care of automatic
posting of the exchange rate differences realized while clearing open items: for loss it will be
72010000, and for the gains it will be 72510000. For valuation adjustments, the loss will be
posted to 72040000 and the gains to 72540000; the B/S adjustments will go to the G/L
account 11001099.
To make the required settings:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Outgoing Payments Global Settings > Define Accounts for Exchange Rate
Differences. You may also use Transaction OB09.
Enter the ‘Chart of Accounts’ on the pop-up screen. Press ‘Continue’.
The system brings up the G/L accounts, on the next screen, for which you need to
maintain the account(s) for automatic posting of exchange rate differences.
Select a row (G/L account), click on ‘New Entries’ and maintain the details, on the next
screen (Figure 6.4):
• Leave the ‘Currency’ and ‘Currency Type’ field as blank so that the G/L
accounts entered here will be used for all the currencies / currency types. If
you decide to define individual accounts for separate currencies / currency
types, then, maintain the ‘Currency’ and ‘Currency Type’.
• Enter the appropriate G/L account for ‘Loss’ and ‘Gain’ under the ‘Exchange
rate difference realized’ block. Similarly, enter the G/L accounts for valuation
loss / gain in the ‘Valuation’ block.
Outgoing Payments
v.
161
‘Save’ when completed, and repeat the steps to define the G/L accounts, for posting
the gain / loss, for both exchange rate differences and valuation, for other G/L
accounts by using the ‘Next Entry’ button.
Figure 6.4 G/L Accounts for Posting Exchange Rate Differences during OI Clearing
We have defined a single set of G/L accounts to take care of automatic posting of the
exchange rate differences realized in clearing open items: for loss it will be 72010000, and for
the gains it will be 72510000. For valuation adjustments, the loss will be posted to 72040000
and the gains to 72540000; the B/S adjustments will go to the G/L account 11001099.
Let us now define the account for handling rounding differences.
6.1.6 Define Account for Rounding Differences
During clearing open items, the system posts the gains / losses realised from exchange rate
differences. Hence, you need to define the appropriate revenue / expense G/L accounts for
automatically posting of the gain / loss arising out of currency rounding off during clearing.
Project Dolphin
BESTM has asked the project team to configure G/L account 72020000 and 72520000 to
handle currency rounding off during clearing.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Account for Rounding Differences, or Transaction
162
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
OB00. On the resulting screen (Figure 6.5), for the chart of accounts BEUS, define appropriate
G/L accounts: one for revenue and one for expense, to take care currency rounding off.
Figure 6.5 G/L Accounts for handling Rounding Differences
You also need to define a separate set of G/L accounts to handle payment differences if you
work with any alternative payment currencies in manual or automatic payments. Let us
configure the same, next.
6.1.7 Define Accounts for Payment Differences with Altern. Currency
As in the previous case, define the appropriate G/L accounts (debit and credit) to handle
payment differences (gain/ loss) when you work with alternative currencies for payment –
both manual and automatic.
Project Dolphin
BESTM has asked the project team to use G/L account 72010000 and 72510000 to handle to
handle payment differences (gain/ loss) when working with alternative currencies for
payment.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Accounts for Payment Differences with Altern.
Currency, or Transaction OBXO.
Figure 6.6 G/L Accounts for Payment Differences with Alternative Currencies
Outgoing Payments
163
On the resulting screen, for the chart of accounts BEUS, define the appropriate G/L accounts,
one for revenue and one for expense (Figure 6.6).
The next activity is to define the G/L account to post vendor bank charges.
6.1.8 Define Accounts for Bank Charges (Vendors)
Define the G/L account number(s) for your bank charges accounts. Once defined, the system
posts the charges that you specify for a bank item when settling payment to these accounts.
Project Dolphin
BESTM has asked the project team to use G/L account 71000000 to take care of posting of
vendor bank charges.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Accounts for Bank Charges (Vendors), or
Transaction OBXK. On the resulting screen, double-click on ‘Bank charges’ (Transaction BSP)
procedure, and define appropriate G/L account(s), for the chart of accounts BEUS (Figure 6.7).
Figure 6.7 G/L Account for Bank Charges (Vendors)
The next step is to define the posting keys for clearing.
6.1.9 Define Posting Keys for Clearing
Use this configuration task, to define the posting keys the system uses to create line items,
automatically, during clearing transactions. The payment program also uses these posting
keys. For each of the clearing transactions (or procedures) namely AUSGZAHL (outgoing
payment), EINGZAHL (incoming payment), GUTSCHRI (credit memo), JVACLEAR (JVA clearing)
and UMBUCHNG (transfer posting with clearing), you will see that there are posting keys
already defined in the standard system that you can use without making any change.
However, if you want to make a change or define your own (normally, not recommended),
you may use the menu path: SAP Customizing Implementation Guide > Financial Accounting
164
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
> Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Define Posting Keys for Clearing, or Transaction OBXH .
On the ‘Maintain Accounting Configuration: Clearing Procedures – List’ screen, you will see a
list of pre-defined standard clearing procedures like AUSGZAHL, EINGZAHL etc (Figure 6.8).
Figure 6.8 List of Clearing Transactions
You may double-click on a row, to look at the details of default posting keys for that clearing
procedure on the next screen (Figure 6.9). We are neither changing any of the standard
posting keys nor defining any new key, for BESTM.
Figure 6.9 Standard Posting Keys for the Clearing Procedure ‘Incoming Payment’
Outgoing Payments
165
Do not to change the standard settings of posting keys for the clearing transactions.
The next step is to enable company codes for translation postings.
6.1.10 Enable Translation Posting
When you enable translation posting for a company code, you determine that the translation
gain / loss for clearing open items, in foreign currency, is to be posted by the system to the
appropriate accounts. The system posts the translations if the item to be cleared has already
been revalued once during foreign currency valuation. The system, then, posts the valuation
difference to a separate G/L account (translation account), with an offsetting entry to a
clearing account.
Project Dolphin
BESTM wants the project team to enable posting of translation gain/loss for clearing open
items in foreign currency, in all the company codes both US-based and India-based.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Enable Translation Posting. On the resulting screen,
enable translation posting by selecting the ‘Post Translation’ check-box for all the required
company codes (Figure 6.10).
Figure 6.10 Enabling Company Code for Posting Translation Gain / Loss
The next step is to define the settings for payment block reasons.
6.1.11 Payment Block Reasons
There are two settings you need to make: one is to define the payment block reasons and the
other is to define the default values for payment block.
6.1.11.1 Define Payment Block Reasons
We have already discussed payment block reasons in Section 5.1 of Chapter 5.
Let us, now, look at the last configuration step in global settings for outgoing payments:
defining default values for payment block.
166
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.1.11.2 Define Default Values for Payment Block
Using this step, you can change the payment blocking key value that is proposed as a default,
per payment terms, when entering postings to customer / vendor accounts.
Project Dolphin
BESTM does not want to propose a default blocking key via payment terms, for postings
customer / vendor accounts.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Outgoing Payments Global Settings > Payment Block Reasons > Define Default Values for
Payment Block. On the resulting screen, enter the payment block key in ‘Block Key’ field that
should be proposed as the default, for each of the payment terms. If you do not want the
system to propose a default payment blocking key based on the terms of payment, you just
need to leave this field as blank, as we have done for BESTM (Figure 6.11).
Figure 6.11 Default Block Key Configuration via Payment Terms
This completes our discussion on global settings for outgoing payments. Let us move on to
discuss manual outgoing payments, in the next Section.
6.2 Manual Outgoing Payments
There are several settings you need to make to configure manual outgoing payments,
including defining accounts for payment differences and checking payment block reasons. As
you are aware, we have already configured the G/L account for taking care of payment
differences (Section 6.1.4), and defined the payment block reasons in Section 6.1.11, when
configuring the global settings for outgoing payments. Let us now look at the remaining
settings, in this Chapter, that include the following:
•
•
•
•
Tolerances (Vendors)
Define Reason Codes (Manual Outgoing Payments)
Cross-Company Code Manual Payments
Configure Manual Payments
Let us start with the definition of vendor tolerances.
Outgoing Payments
167
6.2.1 Tolerances (Vendors)
Before getting into defining tolerances for vendors, let us understand what is tolerance and
tolerance group.
You need to define a ‘tolerance’ in the system for dealing with the payment differences arising
out of transaction posting in FI. By defining a tolerance, you are instructing the system as to
how to proceed further: (a) what are the amounts or percentage rates up to which the system
is to automatically post to a separate expense or revenue account, if it is not possible to
correct the cash discount or (b) up to what difference amounts the system is to correct the
cash discount; the cash discount is automatically increased or decreased by the amount in
difference using ‘tolerance groups’.
You will come across three types of tolerances:
•
•
•
Employee tolerance
G/L account clearing tolerance
Customer / vendor tolerance
In SAP, you manage the tolerances through tolerance group. Since the same rules usually
apply to a group of employees, you can maintain the values, per employee group. This way
you can, then, enter amount limits and tolerances, per employee group and company code.
You can also define tolerances without specifying a tolerance group: the stored tolerances are
then valid for all employees who are not allocated to a group. As it is possible to specify
tolerances for clearing procedures for your customers / vendors, the system takes into
account the lower limits from the customer/vendor specifications and employee group during
clearing transactions.
SAP comes delivered with sample tolerances which you can copy and tailor to your own
requirements. You can also additionally differentiate these settings by company code: there
should at least be one entry per company code (usually a blank in the tolerance group field,
called the ‘null tolerance group’) to enable transaction posting without any glitch.
Let us now understand how to define the tolerance groups for employees.
6.2.1.1 Define Tolerance Groups for Employees
For every company code, you need to find out which tolerances are to be determined and
whether a differentiation according to employee group is necessary. If you want to define
different tolerances for your employees, specify the amount limits for each of the groups. If
the tolerance limits are to apply to all employees, leave the 'Group' field empty. Define the
tolerances correspondingly. You pre-define various amount limits for your employees with
which you determine:
168
•
•
•
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
The maximum document amount the employee is authorized to post.
The maximum amount the employee can enter as a line item in a customer or vendor
account.
The maximum cash discount percentage the employee can grant in a line item.
The maximum acceptable tolerance for payment differences for the employee.
If you have defined different tolerance groups, you then have to assign your employees to a
certain tolerance group. To do this, select the activity 'Assign users to tolerance groups' and
enter your employees under the relevant groups. You should also define separate tolerances
for employees and business partners. When clearing the open items, the system checks both
the tolerances and clears the transaction with the lowest tolerance.
It is possible that you can manage payment difference transactions with just one
tolerance group (also known as ‘null tolerance group’) per company code, that is applicable
to all the employees. However, we recommend that you to have at least one more tolerance
group, attached to a select group of employees, with relatively larger tolerances to handle
special situations or your most valued customers / vendors. Your null tolerance group, of
course, will be the most restrictive one and will apply to most of the employees.
Project Dolphin
BESTM management has indicated that it requires two additional tolerance groups, besides
the null tolerance group, to be configured in the system: one will be for taking care of all the
US-based company codes, and the other for the India-based company codes. It is further
stipulated that these special tolerance groups will have only a handful of employees assigned,
in each company code, to handle special situations and high-value customers / vendors as
these groups will have liberal tolerances in comparison to the null group.
Accordingly, the project has decided to have the following tolerance groups: TGUS and TGIN.
The tolerance group TGUS will be for all the US-based company codes. All the employees who
are allocated to this group will be allowed to post accounting documents of maximum value
USD 999,999,999 per document, with a limit of USD 99,999,999 per open item. However, they
can process cash discounts at 5% per line item, with the system allowing a maximum payment
difference of 3%, subject to an absolute maximum of USD 500. The cash discount adjustment
amount will be USD 100.
The tolerance group TGIN will be for the two India-based company codes (1210 and 1220).
The select employees who are part of this group will be allowed to post accounting documents
of maximum value INR 999,999,999, per document with a limit of INR 99,999,999 per open
item. However, they can process cash discounts at 5% per line item, with the system allowing
Outgoing Payments
169
a maximum payment difference of 3%, subject to an absolute maximum of INR 5,000. The
cash discount adjustment amount will be INR 1,000.
The null tolerance group will be applicable for all the employee, and will be the default
tolerance group for all the company codes of BESTM, both in USA and India:
(a) For all the US-based company codes, this null group will enable posting of accounting
documents with values not exceeding USD 999,000, per document with a limit of USD 99,000
per open item. The maximum cash discount allowed is 2% per line item, and the maximum
payment difference is 1%, with an amount cap of USD 50. The cash discount adjustment limit
has to be set at USD 5.
(b) In the case of India-based company codes, the null group enables posting of accounting
documents of value up to INR 1,500,000, per document with the line item limit of INR
1,000,000. The maximum cash discount allowed will be 2% per line item, with the maximum
allowed payment difference of 1% with an amount cap of INR 1,000. The cash discount
adjustment limit will be at INR 100.
Let us define the tolerance groups, for BESTM, as detailed out below:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Financial Accounting Global Settings > Document > Tolerance Groups > Define
Tolerance Groups for Employees. You may also use Transaction OBA4.
On the ‘Change View “FI Tolerance Group for Users”: Overview’ screen, click on ‘New
Entries’. On the next screen (Figure 6.12):
Figure 6.12: Tolerance Group TGUS for Company Code 1110
170
•
•
•
iii.
iv.
v.
vi.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Enter the identifier for the tolerance group in ‘Group’, say, TGUS.
Enter the ‘Company code’. Let that be 1110.
Enter the ‘Amount per document’ as 999,999,999 under ‘Upper limits for
posting procedures’ block; enter the ‘Amount per open item account item’ as
99,999,999; the ‘Cash discount per line item’ will be 5%. Note that the
maximum permitted amount entered in the ‘Amount per open item account
item’ field will not apply to the automatically created line items, as in the case
of line items created by automatic payment program.
• Maintain the ‘Permitted Payment Differences’ as set out in Figure 6.12:
o The ‘Revenue’ row describes the settings controlling overpayments
from customers. A payment difference handled in this row, is to the
advantage of the specific company code as it increases the revenue,
and is posted automatically to a revenue account. For BESTM, enter
500 in the ‘Amount’ field and enter 3 in ‘Percent’ field. Specify the
‘Cash discnt.adj.to’ (100 in our case) which is normally set to be lower
than the ‘Amount’ field: the system uses this field to adjust the
payment difference up to this amount, which is then posted using a
cash discount adjustment.
o Similar to the ‘Revenue’, the 'Expense' row denotes customer
underpayment that lowers your revenue, and is handled and posted
automatically to an expense account. You may maintain the same
amount or percentage limit as that of the revenue row or you can
define different amount / percentage. The ‘Cash discnt.adj.to’ field in
‘Expense’ row is, again, similar to that of the ‘Cash discnt.adj.to’ field
in the ‘Revenue’ row.
• Once completed, ‘Save’ your entries.
You have defined the tolerance group TGUS.
Go back to the initial ‘Change View “FI Tolerance Group for Users”: Overview’ screen,
and you will see that the tolerance group TGUS attached to the company code 1110.
Select the row containing TGUS /1110, and click on ‘Copy As’. On the next screen,
change the company code to 1120, and ‘Save’. You have now copied the tolerance
group TGUS to the company code 1120. Repeat this step to copy TGUS to all the USbased company codes.
Now, configure the null tolerance group, as required by BESTM, for company code
1110 by following the steps explained above and then copy this null/1110 to other
US-based company codes (Figure 6.13).
Outgoing Payments
171
Figure 6.13: Null Tolerance Group for Company Code 2100
vii.
viii.
ix.
Repeat the steps above to define the tolerance group TGIN for the company code
1210 with the specifications as stipulated by BESTM, and then copy this to the other
India-based company code 1220.
Maintain the details for the null tolerance group as well for the company code 1210;
once configured, use this to copy to the other India-based company code 1220.
‘Save’ when completed. You have now completed all the configuration settings for
the required tolerance groups for BESTM.
So, how the tolerance settings work in a real-life situation?
Take the case of null tolerance group for the company code 1110. Consider that you have an
invoice is for USD 10,000; You now know that ‘Cash discnt.adj.to’ is USD 5 for both revenue
and expense items. You also know that the maximum permitted payment difference
(‘Amount’) is USD 50 and the allowed percentage (‘Percent’) is 1 for this tolerance group.
Now, consider the scenario 1 in which you have received an incoming payment of USD 9,980.
Because this an underpayment, the system will make checks based on the ‘Expense’ row
settings. First, it checks whether cash discount can be adjusted to accommodate the payment
difference: because the difference (USD 20) exceeds the cash discount adjustment limit (‘Cash
discnt.adj.to’ field) of USD 5, the discount is not adjusted. Next, the system looks up the
‘Amount’ and ‘Percent’ field values: 1% of USD 10,000 = USD 100, and the maximum allowed
difference amount is USD 50. Since the actual payment difference is only USD 20 (= 10,000 –
9,980), which is well within the upper limit of USD 50 specified in the ’Amount’ field, the
172
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
system proceeds to book the loss of USD 20 to an expense account, and the transaction is
posted through.
Consider the scenario 2 in which the incoming payment is USD 9,890. Because this also an
underpayment, as in the case of scenario 1, the system will make checks based on the
‘Expense’ row settings. First, the system checks whether the cash discount can be adjusted to
accommodate the payment difference: as the difference (USD 110) exceeds the maximum
permitted cash discount adjustment limit (‘Cash discnt.adj.to’ field) of USD 5, the system does
not adjust the discount. Now, the system looks up the ‘Amount’ and ‘Percent’ field values: 1%
of 10,000 = 100, and the maximum allowed difference in amount is USD 50; but the actual
payment difference is USD 110 (= 10,000 – 9,890). As the system can tolerate only to a
maximum of USD 50, the system does not allow posting the transaction.
Let us consider another situation (scenario 3), wherein the incoming payment is USD 9,998.
Because this also an underpayment, as in the case of scenarios 1 & 2, the system will make
checks based on the ‘Expense’ row settings. First, the system checks whether the cash
discount can be adjusted to accommodate the payment difference: as the payment difference
is only USD 2 which is well within the maximum permitted (‘Cash discnt.adj.to’) amount of
USD 5, the cash discount amount is adjusted to USD 2, and the transaction is posted to.
Now, consider the scenario 4 in which the incoming payment is USD 10,040. Being an
overpayment, the system will take into account the settings specified in ‘Revenue’ row. The
system, first, checks whether the cash discount can be adjusted to accommodate the payment
difference: since the difference (USD 40) exceeds the maximum permitted cash discount
adjustment limit of USD 5 (‘Cash discnt.adj.to’ field), the system does not adjust the cash
discount. Instead, the system now looks up the ‘Amount’ and ‘Percent’ field values: 1% of
10,000 = 100, and the maximum allowed payment difference in amount is USD 50; but the
actual payment difference is an overpayment of USD 40 (= 10,040 - 10,000). As the system
can allow overpayments up to a maximum of USD 50, the system books the profit by posting
USD 40 to a revenue account and clears the payment transaction.
Now, consider yet another situation (scenario 5) in which the incoming payment is USD
10,070. Being an overpayment as in scenario 4, the system will take into account the settings
specified in ‘Revenue’ row. The system, first, checks whether the cash discount can be
adjusted to accommodate the payment difference: since the difference (USD 70) exceeds the
maximum permitted cash discount adjustment limit of USD 5 (‘Cash discnt.adj.to’ field), the
system does not adjust the cash discount. Instead, the system now looks up the ‘Amount’ and
‘Percent’ field values: 1% of 10,000 = 100, and the maximum allowed payment difference in
amount is USD 50; but the actual payment difference is an overpayment of USD 70 (= 10,070
- 10,000). As the system can tolerate overpayments only up to a maximum of USD 50, the
system does not allow you to proceed further with the transaction.
Outgoing Payments
173
Let us consider the final scenario (scenario 6), wherein the incoming payment is USD 10,003.
Because this an overpayment, as in the case of scenarios 4 & 5, the system will make checks
based on the ‘Revenue’ row settings. First, the system checks whether the cash discount can
be adjusted to accommodate the payment difference: as the payment difference is only USD
3 which is well within the maximum permitted (‘Cash discnt.adj.to’) amount of USD 5, the
cash discount amount is adjusted to USD 3, and the transaction is posted to.
In short, the system tolerates an underpayment or overpayment to a maximum of USD 50,
which can be represented as 9,950 < 10,000 > 10,050; the invoice amount being USD 10,000.
Anything below USD 9,950 or above USD 10,050 is not tolerated in the system and those
transactions will be blocked from posting.
You can treat the payment differences, exceeding the tolerance limits set for automatic
clearing, either as partial payments or residual items:
•
•
In the case of ‘partial payments’, the system will not clear the original receivable, but
will post the payment with an invoice reference, by entering the invoice number in
the ‘Invoice Reference’ field in the payment items. The system determines the due
date of the payment, by calculating the net due date for the invoice, and this due date
is then entered in the ‘Baseline Date’ field of the payment. The dunning program,
then, includes this payment on the dunning run on this date.
However, in the case of ‘residual items’, you can use the payment to clear the original
receivable and post the remaining amount (payment difference) to the customer
account as a residual item. The system enters this payment amount in the line item,
for the original receivable. You may also clear such original receivable and post the
(payment) difference to an expense account, in case of underpayment.
Now that we have defined the tolerance groups, and understood how it actually works in
transaction processing, let us proceed with the next task of assigning users to the tolerance
groups.
6.2.1.1.1
Assign User/Tolerance Groups
Once you have defined the tolerance groups, you then need to assign FI users, to whom you
wish to give special tolerances to the special tolerance group (in our case, TGUS or TGIN).
Since the null tolerance group will be the default tolerance group in a company code, and
applicable for all the employees / users, you do not need to explicitly assign the users to that.
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Financial Accounting Global Settings > Document > Tolerance Groups > Assign
User/Tolerance Groups. You may also use Transaction OB57.
174
ii.
iii.
iv.
v.
vi.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the ‘Change View “Assign Users → Tolerance Groups”: Overview’ screen, you will
notice that there is an entry with a * in ‘User name’ field against a blank ‘Tolerance
Group’, indicating that all the users are a part of this null tolerance group, by default.
To assign select users to a tolerance group, other than the null tolerance group, click
on ‘New Entries’.
On the ensuing screen, enter the ‘User name’ for the specific tolerance group (say,
TGUS). You will not see a drop-down list to select the users, but just a field to input
the names.
‘Save’ when completed (Figure 6.14). The system attaches these users to this specific
tolerance group. While saving, the system will not check whether the entered user is
already defined or active in the system. However, it validates if the entered tolerance
group is already defined; if not, it throws a warning message but still allows to save
and proceed.
Repeat this for the other tolerance groups, as well (say, TGIN).
Figure 6.14: Assigning Users to a Tolerance Group
Let us now understand defining tolerance groups for G/L accounts
6.2.1.2 Define Tolerance Groups for G/L Accounts
We have already discussed the employee tolerance groups in Section 6.2.1.1. On the similar
lines, we need to define, here, the required tolerance groups for SAP G/L Accounting. As in
the case of employee tolerance group, we can have two tolerance groups: the null group with
strict tolerance terms and a specific group, per company code, with relatively liberal terms.
For G/L account clearing, the tolerance groups define the limits within which differences are
accepted (that is, tolerated) and automatically posted to predefined accounts. You can enter
the tolerance groups defined here in the G/L account master record; if you do not enter a
group, then the null tolerance groups come into effect.
Outgoing Payments
175
Project Dolphin
The project team has been advised by the BESTM management to configure the G/L tolerance
groups in the following way:
(a) Null Tolerance Group: The null tolerance group will be applicable for all the employees,
and will be the default tolerance group for all the company codes of BESTM, both in USA and
India. This will have a tolerance of USD 1 (in absolute terms), with 0.5% as the limit for USbased company codes. In the case of India-based company codes, the null tolerance group
will have an absolute limit of INR 10 and the percentage limit will be the same at 0.5%.
Besides the null tolerance group, there will be two more tolerance groups defined in the
system: one for US-based company codes and the other for India-based company codes:
(b) BGLU: This will be for the selected employees of all the US-based company codes allowing
a tolerance of USD 10, in absolute terms, both for debit and credit transactions; in percentage
terms the limit will be 1%.
(c) BGLI: This will be for the India-based company codes - the percentage will be the same at
1%, but the absolute amounts in INR will be 100.
In all the cases, lower of the absolute amount or percentage will apply as the tolerance.
Let us configure the G/L tolerance groups:
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Master Data > G/L Accounts > Business Transactions >
Open Item Clearing > Clearing Differences > Define Tolerance Groups for G/L
Accounts. You may also use Transaction OBA0.
On the ‘Change View “Tolerances for Groups of G/L Accounts in Local Currency”:
Overview’ screen, click on ‘New Entries’.
On the next screen, enter the ‘Company Code’, leave the ‘Tolerance Group’ as blank
as this will be the null tolerance group, add a description for the tolerance group, and
maintain the tolerance values both in absolute and percentage terms for both ‘Debit
Posting’ and ‘Credit Posting’ (Figure6.15). ‘Save’ the settings. You have created and
assigned the null tolerance group for G/L account processing for company code 1110.
If you are maintaining both an absolute amount and a percentage, the system
considers the lowest limit of the two while processing the clearing. You can also
configure only absolute amount or only percentage. When assigned to the company
code(s), the lowest of either G/L account tolerance or employee tolerance applies.
176
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 6.15 Null G/L Tolerance Group for Company Code 1110
iv.
v.
vi.
Copy this to all the US-based company codes of BESTM.
Repeat the steps to create another null tolerance group for India-based company
codes.
Repeat the steps, again, to create the specific tolerance groups (BGLU and BGLI) with
the absolute amount and the percentages as required by BESTM management for the
various company codes (Figure 6.16).
Figure 6.16 G/L Tolerance Groups for BESTM
6.2.1.3 Define Tolerances (Vendors)
Similar to employee and G/L account tolerance groups, let us, now, define the tolerance
groups for vendors, here. Actually, we should call this as the ‘tolerance group for business
partners’ as you can use this for both customers and vendors, even though the configuration
step states this as ‘tolerances (vendors)’.
Specify the tolerances for vendors and use them for dealing with payment to vendors, in case
of payment differences and residual items during payment settlement. Define one or more
tolerance groups and allocate a tolerance group to each of your vendor masters. Per tolerance
group, (a) specify the tolerances up to which the system posts the differences, automatically,
either to a revenue account or an expense account while clearing the vendor open items, and
(b) specify how to handle the terms of payment for residual items that may arise during
clearing.
Outgoing Payments
177
Since there is an employee tolerance defined and set in the system, during clearing, the
system takes into account the lower of the specifications in employee tolerance and vendor
tolerance.
Project Dolphin
BESTM wants to have two tolerance groups: a strict tolerance group that will be for most the
vendors and a liberal one that will be applied to specific vendors.
For all the US-based company codes:
The strict tolerance group will be called as the ‘null tolerance group’ which will be the default
when a vendor is not assigned with a specific tolerance group. For this tolerance group, the
permitted payment difference will be $50 for gains (1%) and $10 for losses (0.5%), with a
maximum adjustment cash discount being $5. For automatic write-off of payment
differences, the amount and percent values will be $5 and 0.25% respectively, both for
revenue and expense.
For the specific tolerance group, which will be termed as BEU1, the corresponding permitted
payment difference is $500 for gains (2%) and $250 for losses (1%). The maximum cash
discount that can be adjusted, will be $50. The amount and percentage values for automatic
write-off of payment differences (revenue or expense) will be $25 and 0.5% respectively.
For all the India-based company codes:
The tolerance amount, tolerance percentage, and the cash discount amount that can be
adjusted, the amount and percentage for automatic write-off of payment differences will be
the same as that of US company codes but the amount will be in INR. The corresponding
tolerance group for BEU1 will be BEI1.
Let us configure the tolerance group BEU1:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Manual Outgoing Payments > Define Tolerances (Vendors). You may also
use Transaction OBA3.
Click on ‘New Entries’ on the resulting screen, to configure the settings (Figure 6.17):
• Enter the ‘Company code’. The system brings up the company code
‘Currency’ when you save the details.
• Enter an identifier for ‘Tolerance Group’ (BEU1), and provide a description.
• You may enter the ‘Specifications for Clearing Transactions’. When you enter
a number in ‘Grace Days Due Date’ field, then, the system adds this to the
178
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
payment deadline, to arrive at the new deadline, to take care of cash
discount. The system also takes into account the revised payment deadline(s)
for accepting the net payment.
Figure 6.17 Customer/Vendor Tolerance Group BEU1 - Details
•
•
Use a dropdown value in ‘Arrears Base Date’ to indicate how the system
should arrive at the arrears baseline date. When left blank, the system
determines the days in arrears based on document date. If you select ‘1’, then
the arrears baseline date will be the value date.
Use ‘Cash Discount Terms Displayed’ field to specify whether cash discount
terms are to be displayed or not. When left blank, or when you enter 0 or *,
then system displays the current discount term; if you enter 1, 2, or 3, then,
Outgoing Payments
ii.
iii.
179
the system displays the respective cash discount terms. You can, of course,
change the default, later, when processing an open item.
• Enter the absolute amount, tolerance percentage and cash discount
adjustment amount, for revenue and loss, under ‘Permitted Payment
Differences’. The system allows the payment difference (in local currency) to
your advantage (gain) up to the amount that is entered in the ‘Amount’ field
in the ‘Rev.’ row which increases your profit when posted. As you can also
maintain a percentage (‘Percent’) for the revenue row (‘Rev.’), the system
takes into account the lower of these two (‘Amount’ and ‘Percent’) into
account for deciding the gain (and, of course, takes only the lower of
employee or vendor tolerance). The system corrects the payment difference
up to the amount specified in ‘Adjust Discount By’ field, when the cash
discount is large enough for adjustment, with the cash discount posting,
before posting the gain. The system creates the necessary line items for all
these adjustments/postings. The explanation will be similar to the ‘Loss’ row
except that the payment difference will be to your disadvantage (loss), and
you profit decreases by this amount when the system posts the loss.
• Enter the values for ‘Permitted Payment Differences for Automatic Write-Off
(Function Code AD)’ for both revenue and loss, both in amount and in
percentage.
• You may also maintain the ‘Specifications for Posting Residual Items from
Payment Differences’. Select ‘Payment Term from Invoice’ check-box if you
want the payment terms to be transferred from the original line item to
residual items arising out of over / under payments. However, if you maintain
‘Fixed Payment Term’, then, the system will not transfer the payment terms
from invoice. The check-box ‘Only Grant Partial Cash Disc’, when selected,
indicates that the system should grant only a partial cash discount, if an
outstanding receivable is posted due to an under payment during invoice
clearing. Use the ‘Dunning Key’ filed to select an appropriate dunning level,
to enable the system to enter that into the automatically generated residual
line item.
• You may also maintain the ‘Tolerances for Payment Advices’.
When completed ‘Save’ the details. This completes creation of the tolerance group
BEU1 for company code 1110. You may go back to the previous screen and copy this
group to all other US-based company codes of BESTM.
Similarly, create the null tolerance group for BESTM US-based company codes, by
following the steps listed above. Also, create the other tolerance groups – BEI1 and
null tolerance group for India-based company codes (Figure 6.18).
180
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 6.18 Customer/Vendor Tolerance Groups for BESTM
Let us now move on to discuss the next configuration activity under manual outgoing
payments, namely, defining reason codes.
6.2.2 Define Reason Codes (Manual Outgoing Payments)
You will use ‘reason codes’ to handle business situations like, when the cash discount period
has been exceeded, or if cash discount has been taken when payment is net due etc. Define
the reason codes, per company code, for handling payment differences in the form of residual
items, partial payments and/or postings on account. For each of the reason codes, you can
decide for which of the company codes it is valid, for which correspondence type (say,
payment notice) it is connected to and an explanation in the form of both short and long text.
You can also set the clearing indicator, for each of the reason codes, so that the payment
difference is cleared using a separate G/L account. If you do not set the indicator, then, the
system generates a new item as an outstanding receivable in the customer's account.
Project Dolphin
The project team has suggested to create new reason codes to cover situations like cash
discount period exceeded, cash discount rate not kept to, cash discount deducted for net
terms, discount period exceeded & rate incorrect, calculation error on customer side, debit
paid twice, credit memo paid instead of reduction, credit memo reduced twice etc.
To configure new reason codes:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Manual Outgoing Payments > Overpayment/Underpayment > Define
Reason Codes (Manual Outgoing Payments) or Transaction OBBE.
Enter the company code on the resulting ‘Determine Work Area: Entry’ pop-up
screen. On the resulting screen, click on ‘New Entries’ and on the next screen (Figure
6.19):
Outgoing Payments
181
Figure 6.19 Reason Codes for Manual Outgoing Payments
•
•
•
•
•
Enter a 3-character identified for the reason code (‘RCd’).
Enter a ‘Short Text’ and a ‘Long Text’.
Select the appropriate correspondence type (‘Corr T’) from the drop-down
list like SAP01 (payment notice with line items), SAP02 (payment notice
without line items, SAP06 (account statement), SAP11 (customer credit
memo), SAP12 (failed payments), SAP19 (customer invoice) etc.
Select check-box ‘C’ if the payment differences with this reason code are to
be charged off via a separate G/L account.
Select check-box ‘D’ if payment differences with this reason code should lead
to a disputed item when creating a residual item.
The ‘disputed items’ will not increase the total A/R against a customer.
You can display them separately in the line item display as well as in credit
management. The system does not take into account the disputed items, in
credit reviews, against the oldest open items or against that percentage of
open items with a specific number of days in arrears.
•
When you set ‘Do Not Copy Text’ indicator, then, the system does not copy
the text of the reason code into the segment text of the residual item / partial
182
iii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
payment. You need to select this check-box only when you want to manually
enter the segment text.
‘Save’ when completed, and create any other reason code(s) that will be required for
you specific business need (Figure 6.19).
With this, we can, now, move on to the last activity of preparing for cross-company code
manual payments.
6.2.3 Cross-Company Code Manual Payments
Use this configuration activity to maintain the company codes which carry out manual
payments and other clearing procedures, on behalf of other company codes in a corporate
group. The pre-requisite is that you should have maintained the clearing accounts for crosscompany transactions while configuring the G/L Accounting. To recall, you can read through
the Section below:
6.2.3.1 Cross-Company Code Transactions
The cross-company code postings happen (a) when purchasing or payment is made centrally
by a company code (say, 1110) on behalf of several company codes (say, 1120, 2100, 2200
etc) in a corporate group, and/or (b) if one of the company codes (say, company code 1120),
of the corporate group, is a manufacturer and another (say, company code 1110) is a
merchandiser (seller). In the manufacturer-merchandiser scenario, the manufacturer sells its
products first to the merchandiser, and in turn the merchandiser sells them to the end
customers. In this case, the system posts the transactions between the merchandising
company code (say, 1110) and the manufacturing company code (say, 1210): the system
creates two documents, one for each company code for every transaction.
You may also come across a situation where in the customers (of, say, company code 1120)
make payment to the wrong company code (say, 1110) in the corporate group. In such cases,
you can use cross-company code transactions to minimize the number of entries for posting
this incorrect payment: you debit the bank account of company code 1110 and credit the
customer account of company code 1120, and the system automatically generates clearing
entries between these two company codes.
The company codes participating in cross-company code transactions should be part of
the single legal entity. You can set up cross-company code transactions for clearing customer
/ vendor accounts as well as G/L accounts. If one of the participating company codes is an
external one, you can only do this for G/L accounts clearing, and not for customer / vendor
accounts.
Outgoing Payments
183
Use this configuration activity to define the accounts for the clearing entries the system makes
when posting cross-company code transactions. You will do the settings for a pair of company
codes; if there are more than two company codes, then you need to define more than one
pairing among themselves.
Project Dolphin
The BESTM Corporate has indicated to the project team that they need to take care of crosscompany code transactions as the company code 1110 will be the central purchasing
organization for rest of the company codes in US. Besides, it was further stated that the
company code 1120 will make sales of their products through company code 1110 which will
act as the merchandiser. A similar scenario was envisaged for India-based company codes, as
well, with regard to the central purchasing by the company code 1210 for themselves and on
behalf of the other company code 1220.
To configure cross-company code transactions:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Master Data > G/L Accounts > Business Transactions >
Prepare Cross-Company Code Transactions.
Figure 6.20 Cross-Company Code Transactions – Settings for Clearing between 110 and 1120
184
ii.
iii.
iv.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the ensuing ‘Company Code Clearing’ pop-up screen, enter 1110 as ‘Company
code 1’ and 1120 as ‘Company code 2’. And, press ‘Continue’.
On the ‘Configuration Accounting Maintain: Automatic Posts – Clearing Accounts’
screen, maintain the required details as indicated below (Figure 6.20):
• Under ‘Company code 1’ block, for ‘Posted In’ the company code 1110 and
‘Clearing Against’ the 1120, enter the Debit and Credit posting keys (40 and
50 respectively). Also, enter the appropriate G/L account for receivable
(‘Receivables affiliated companies adjustments’ - 12302000) and payable
(‘Payables affiliated companies adjustments’ - 21302000) in the respective
fields as shown in Figure 6.20.
• Repeat the entries for ‘Company code 2’ block for ‘Posted In’ the company
code 1120 and ‘Clearing Against’ the company code 1110, and ‘Save’.
Maintain similar configuration for other pairs of company codes as well. When
completed, click on ‘List’ on the ‘Configuration Accounting Maintain: Automatic Posts
– Clearing Accounts’ screen, to see the pairing of company codes for cross-company
code transactions for BESTM (Figure 6.21). You may also use the ‘Create’ button on
this screen to make settings between a pair of company codes.
Figure 6.21 List of Company Codes paired for Cross-Company Code Transactions
With this let us now look at how to make the specifications for cross-company code manual
payments.
6.2.3.2 Prepare Cross-Company Code Manual Payments
The specifications you make, here, for cross-company code payments are valid only for
manual payments, and they will not have any impact on the automatic payment program.
Outgoing Payments
185
Project Dolphin
BESTM has indicated that the company code 1110 will need to be configured in such a way
the it can carry out manual payments and other clearing procedures on behalf of 1120.
Similarly, the cross-company code manual payments need to be enabled for the following
other pairs of company codes:
Paying Company Code Payments for
2100
2200
3100
3200
1210
1220
Accordingly, the project team has decided to configure the settings to cover the clearing
procedures like incoming payment, outgoing payment, credit memo and transfer posting
with clearing.
To make the settings:
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Manual Outgoing Payments > Prepare Cross-Company Code Manual
Payments or Transaction OB60.
On the ‘Change View “Company Code Allocation For Manual Payments”: Overview’
screen, click on ‘New Entries’ and make the required settings on the resulting screen:
• Enter the ‘Company code’ that will pay for the company code entered in
‘Payments For’ field.
• Select the appropriate clearing transaction (‘Clearing trans.’).
• Enter the company code for which the payments will be made, in ‘Payments
For’ field.
• Repeat the entries for all the required clearing transactions for a given pair of
company codes, and complete for all the required pairs of company codes.
‘Save’ the details when completed (Figure 6.22).
Figure 6.22 Settings for Cross-Company Code Manual Payments
186
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You need to maintain the cross-company code manual payment specifications for each
clearing procedure like incoming payment (EINGZAHL), outgoing payment (AUSGZAHL), credit
memo (GUTSCHRI) and transfer posting with clearing (UMBUCHNG).
The next step is to configure the manual payments.
6.2.4 Configure Manual Payments
Here, you can configure the settings for ‘Create Manual Payment’ application which allows
you to create manual payments for the two scenarios: (a) direct payment without an invoice
and (b) payment of open vendor line items.
Project Dolphin
BESTM suggested to the project team to configure ‘create manual payment’ application to
cover both the scenarios of direct payment without an invoice and payment of vendor open
line items, with the system posting both the payment and document.
To configure:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Manual Outgoing Payments > Configure Manual Payments.
On the resulting screen (Figure 6.23), click on ‘New Entries’ and maintain the details:
Figure 6.23 Configuring Manual Payments
•
•
Enter the company code in ‘CoCd’ field; a * indicates that the settings made
here will be valid across company codes.
Select the appropriate item scenario (‘Item Scen.’) from the drop-down list to
decide the behaviour of the payments that you create with the ‘Create
Manual Payment’ application:
➢ Select ‘Post F110 - direct and item scenarios’ option to cover both
the scenarios. Here, the system creates the document (only in the
direct scenario) and executes the payment with the payment
program; and, posts both the document and the payment.
Outgoing Payments
187
You may also look at the other two options:
ii.
➢‘Post down payment request only’ for direct payment scenario in
which the system creates document for direct payment but does not
post the payment.
➢‘Start payment media workbench – direct and item scenarios’ in
which the system creates the document (only in the direct scenario),
executes the same with the payment program, runs the payment
media workbench to create a payment file, and - of course - posts
both document and payment.
• Select the appropriate direct scenario process step as well for the ‘Direct Sc.’
field. Here, also, select ‘Post F110 - direct and item scenarios’ option to cover
both the scenarios.
• Select the appropriate document type (‘Type’), select also the target special
G/L indicator (‘Trg.Sp.G/L Ind.’) to derive the account for posting the down
payment request, and enter the identifier for payment run in the ‘Run Key’
field.
‘Save’ when completed.
This completes our discussion on configuring the system for manual outgoing payments. With
this we are, now, all set to discuss the most important aspect of outgoing payments:
configuring the automatic outgoing payments by payment program.
6.3 Automatic Outgoing Payments
With the payment program, in SAP, you can manage, automatically, both the incoming and
outgoing payments. Supporting several payment methods including check, bill of exchange
(BoE), direct debit, bank transfer, card payment etc., the payment program is delivered in the
standard SAP system with the appropriate print forms and print programs to take care of any
country-specific payment requirements of the world. Using this program, you can clear open
items of customers and vendors, manage intercompany payments, process domestic and
overseas payments, prevent a payment by payment block etc. You can create DME (data
medium exchange) file for transferring the payment data through electronic format. Via the
payment program, you can print the check, payment list and payment forms. By configuring
the program suitably, you can manage the ‘what, when and how’ of payments.
You have to determine, by suitable configuration, (a) which company codes are to be included
in payment transactions and which company code makes payments, (b) which payment
methods are to be used, (c) whether you need to use payment method supplements (c) from
188
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
which bank accounts payment is to be generated, and (d) with which form the payment is to
be made.
The configuration includes the following activities:
•
•
•
•
•
•
•
•
•
•
•
•
•
Set Up All Company Codes for Payment Transactions
Set Up Paying Company Codes for Payment Transactions
Set Up Payment Methods per Country for Payment Transactions
Set Up Payment Methods per Company Code for Payment Transactions
Set a Payment Medium Format per Company Code
Set Up Bank Determination for Payment Transactions
Define Value Date Rules
Assign Payment Method to Bank Transaction
Define Payment Groupings
Prepare Automatic Postings for Payment Program
Prepare Automatic Posting for Payment Requests
Select Search Fields for Payments
Select Search Fields for Line Item Display
You may carry out the individual steps as in IMG or use Transaction FBZP to configure
the same through an interface (Figure 6.24).
Figure 6.24 Entry Screen of Transaction FBZP
Outgoing Payments
189
Before you proceed to set up the configuration for automatic payment program, you need to
define a house bank without which you will not be able to complete the payment program
settings at a later stage.
6.3.1 Define House Banks
The bank that you will use for making payments is known as the ‘house bank’, in SAP. You can
have more than one house bank in a company code. You need to enter a house bank in the
master record of customer / vendor for the payment program to use that bank. If not, you
have to maintain a rule by which the payment program can determine the house bank
automatically.
A ‘bank directory’ consists of master data of all the banks that you have created either
manually or automatically. For automatic creation of bank master data, complete the
configuration step SAP Customizing Implementation Guide > Cross-Application Components
> Bank Directory > Bank Directory Data Transfer > Transfer Bank Directory Data – International
or Transfer Bank Directory Data - Country-Specific. Once you have created the bank directory,
you may designate one or more banks to be your house bank.
Project Dolphin
All the company codes in USA will have their primary accounts with Bank of America (BOFA),
Citi Bank (CITIU) and Chase Manhattan (CHASU) and they will accordingly be designated as
the house banks. In India, the company codes will have accounts with State Bank of India
(SBIIN), HDFC bank (HDFCI) and ICICI bank (ICICI). Each bank account in a house bank will be
assigned to a G/L account and there can be multiple bank accounts in a single house bank.
BESTM has indicated to the project team to differentiate foreign currency account numbers,
by using a separate G/L account per currency for bill discounting.
To define a new house bank:
i.
You can use the SAP IMG menu path: SAP Customizing Implementation Guide >
Financial Accounting > Bank Accounting > Bank Accounts > Define House Banks, to
create your house banks, or SAP Easy Access Menu Path: SAP Menu > Accounting >
Financial Accounting > Banks > Master Data > House Banks and House Bank Accounts
> Manage House Banks and House Bank Accounts to create both house banks and
accounts within a house bank. You can also use Transaction FI12.
To create only house banks, you may use SAP Easy Access Menu Path: SAP Menu
> Accounting > Financial Accounting > Banks > Master Data > House Banks and House
Bank Accounts > Manage House Banks or Transaction FI12_HBANK.
190
ii.
iii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the resulting screen, select the company for which you want to define the house
banks and double-click on ‘House Banks’ on the left hand side ‘Dialog Structure’.
On the resulting ‘Change View “House Banks’: Overview’ screen, click on ‘New Entries’
and on the next screen (Figure 6.25):
Figure 6.25 New House Bank Creation
•
•
•
•
•
Enter an identifier, for the ‘House bank’, of length not exceeding 5characters. For example, BOFAU for Bank of America, CITIU for Citi Bank etc.
Under ‘House Bank Data’, enter ‘Bank Country’ (say, US) where the house
bank is located and enter a ‘Bank Key’. The bank key can be up to 15
characters long and is a unique ID identifying the bank both domestically and
internationally. This is the SWIFT (Society for Worldwide Interbank Financial
Telecommunication) code for overseas banks. You can also derive the ‘Bank
Key’ from IBAN.
Enter the ‘Communications data’.
Expand ‘Address’ and provide the details like bank name, region, city etc.
In ‘Control data’ block, enter the SWIFT/BIC code, enter a ‘Bank group’ that
you can use in bank chain to optimize payments.
Outgoing Payments
191
You use SWIFT (Society for Worldwide Interbank Financial
Telecommunication) code to identify a bank branch internationally, for
routing financial transactions. Used as the BIC (Bank Identifier Code), the
SWIFT is a combination of letters and numbers, and can have a total length
of 8 or 11. It, however, does not have the account number information of the
beneficiary who will receive the money. For example, the SWIFT code of
HDBC bank, Hyderabad branch, India is HDFCINBBHYD: the first 4-characters
(say HDFC) of a SWIFT will denote the bank and will always be in letters, the
next 2-characters (say, IN) denote the country , the next 2-character (say, BB)
can be characters or a mix of characters and numbers denoting the location,
and the last 3-characters (say, HYD) denoting the branch with the last 3characters being optional.
IBAN (International Bank Account Number), was developed originally in
Europe for standardizing international numbering for individual bank
accounts across the world, for simplifying bank transactions. All the European
banks use IBAN, though its usage is becoming popular in other countries as
well, excluding USA and Canada where they do not use IBAN but recognise
that. The IBAN is made up of a number string with the first two letters
denoting the country, followed by two check digits, and with up to 35
alphanumeric characters containing the bank identifier / bank code and
account number. The alphanumeric characters are known as the BBAN (Basic
Bank Account Number). The national banking association of a country is free
to decide the length of the BBAN to make it as a standard for that country. As
a result, the length of IBAN varies from country to country: for example, the
IBAN for UK, Ireland and Germany is 22, 27 for France, 28 for Poland and so
on. IBAN cannot contain any space in between two digits / characters, when
transmitted electronically (for example: DE89370400440532013999).
However, it is denoted in groups of 4-characters separated by single spaces
(with the last group of any variable length) when printed. An example of IBAN
in print format for Germany will be DE89 3704 0044 0532 0139 99: DE is the
country code, 89 is the check digit, 37040044 is the bank code (also called as
BLZ code) and the last 0532013999 denoting the account number.
While the SWIFT code identifies a specific bank (branch) in international
financial transactions, the IBAN, on the other hand, identifies not only the
bank/branch but also the individual account involved in the international
transaction.
192
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You may maintain the other details for DME, and EDI partner profiles.
If you are creating house bank for the first time, you will see that the
‘Create’ button is enabled; else, you will see only the ‘Change’ button active.
•
iv.
v.
As we are creating the house bank for the first time, click on ‘Create’, and
‘Save’ the details.
Repeat the steps and create all other house banks that you may require.
When completed, go back to the previous screen, and you will see all the house banks
that you have created for a specific company code (Figure 6.26).
Figure 6.26 House Banks for Company Code 1110
vi.
vii.
Now, select the row containing a house bank and double-click on ‘Bank Accounts’ on
the left hand side ‘Dialog Structure’ to create the required bank accounts for that
bank.
Click on ‘Create Bank Account’ and maintain the required details on the next screen:
• Enter an account identifier (‘Account ID’) of length not more than 5
characters. This ‘Account ID’ together with the house bank ID (‘House bank’)
uniquely defines a bank account.
• Enter a proper ‘Description’ for the account ID.
• Under ‘Bank Account Data’ block: enter a ‘Bank Account Number’ of length
not exceeding 18 characters. You may, if required, generate the IBAN number
to fill this field. You may also enter an alternative account number
(‘Alternative acc no.’) and enter the ‘Currency’ in which this account is to be
maintained. Enter a ‘Control key’ which, for example, determines the type of
account in most of the countries: in USA, 01 is used to denote checking
account, 02 savings account, 03 loans and so on. Enter the ‘G/L Acct’ number
in which the transaction figures from this bank account will get updated in
the SAP system. You may also maintain a ‘Discount Acct’ which will be the G/L
Outgoing Payments
•
193
account to which you can post the credit memos arising out of BoE at this
house bank account.
‘Save’ when completed. You have now, for example, created a bank account
called ‘BA100 at the house bank ‘BOFAU’ (checking account1 at Bank of
America) as shown in Figure 6.27.
Figure 6.27 Creating a Bank Account at House Bank
viii.
ix.
Repeat the steps and create all other bank accounts at this specific house bank.
Go back to the previous screen and create all the required bank accounts for the
various house banks (Figure 6.28).
Figure 6.28 Accounts at a House Bank
Now that we defined the required house banks (and the bank accounts) for BESTM, let us
continue with our discussion on configuring the automatic payment program. The first step
will be to set up all the company codes for payment transactions.
194
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.3.2 Set Up All Company Codes for Payment Transactions
Using this configuration step, you will make the settings for all company codes that are
involved in the payment transactions. Per company code, you will define: (a) the paying
company code (the company code that pays for itself and also for other company code), (b) if
separate payment is required per business area, (c) if payment method supplements are to
be used, (d) the cash discount and tolerance which the payment program uses to determine
the appropriate cash discount strategy, and (e) the special G/L transactions that need to be
settled, if any.
Project Dolphin
BESTM wants to designate the company code 1110 as the paying company code for
themselves and also for 1120. Similarly, company code 2100 will be the paying company code
for 2200, and 3100 will be the paying company code for 3200. Similar arrangements will be
made for India based company codes as well wherein the company code 1210 will pay for
1220. BESTM Corporate wants to continue with their existing practice of making payments to
their vendors, six days after the invoices are due. BESTM has requested the project team to
configure the payment program to enable payments per ‘Business Area’, but the project team
suggested not to do that, instead suggested grouping of payments in the normal way by
‘Currency’, ‘Payment Method’, ‘House Bank’ etc, so as to have more flexibility; BESTM, after
a long deliberation, has accepted this idea and does not now require payment grouping per
‘Business Area’. However, BESTM has requested that payment should cover the special G/L
transactions like down payments (including down payment requests), security deposits,
guarantee etc., for both customers and vendors. Additionally, BESTM wants to ensure that
maximum cash discount is always taken, when paying vendor invoices automatically.
To make the required settings:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for
Payment Program > Set Up All Company Codes for Payment Transactions.
On the resulting screen, click on ‘New Entries’ and on the next screen (Figure 6.29):
• Enter the ‘Company code’ for which you are maintaining the settings (say,
1120).
• In ‘Control Data’, enter the ‘Sending company code’ that is known to your
customer / vendor as the one that is sending the payment. It can be paying
company code or different. If this field is left blank, then the system
understands that the paying company code is the same as that of the sending
company code. However, when the sending company code (1120) is not the
Outgoing Payments
•
•
195
paying company code (1110), then, the system incorporates the sending
company code in the payment transfer medium or payment advice as your
business partners (say, vendor) normally expect the sending company code
to send the payment. Also, the sending company code decides grouping of
items from different company codes: the items are grouped into one
payment for all the company codes that have the same paying company code
and sending company code.
Enter the ‘Paying company code’ (say, 1110). This is the company code that
pays on behalf of other company codes; for example, here, the company code
1110 is the paying company code for 1120. In a setting like this, which is also
known as ‘centralized payment’, the system automatically creates the intercompany postings in the system.
Select ‘Separate Payment per Business Area’ check-box only if you want to
group payments per business area. If selected, you will not be able to use the
payment program’s default grouping based on the currency / payment
method / bank (mentioned in the line item).
Figure 6.29 Setting up All Company Codes for Payment Transactions
196
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Select ‘Pyt. Meth Suppl.’ check-box if payments are to be separated according
to a pre-set characteristic. When selected, you can pre-define a ‘payment
method supplement’ for customers / vendors of the company code. The
payment method supplement is a 2-character identifier with the first
character standing for priority (say, 2 for salary & wages, 4 for remittance of
taxes etc) and the 2nd character denoting the execution method (say, N for
clearing via electronic file). So, a payment method supplement 4N, for
example, indicates that the tax remittance should be via electronic file.
You can use a ‘payment method supplement’ to group payments, in
countries like Russia, and you can print the thus separated payments by
sorting them. Though the system will default the payment method
supplement during document entry, from the customer / vendor master, you
can overwrite them during payment processing.
•
Under ‘Cash discount and tolerances’ data block, enter the ‘Tolerance Days
for Payable’ if required. Enter 6 for BESTM group of companies, as they plan
to pay only six days after the invoice becoming due.
The system adds up the number of days specified in ‘Tolerance Days for
Payable’ field, when calculating the cash discount period / due date for net
payment. Suppose that an invoice is due on 20th Mar 2020 and you have
maintained a tolerance of 6 days here in this field, then, the system arrives at
the invoice due date as 26th Mar 2020 and the invoice will not be paid until
that date even though the invoice due is on 20th Mar 2020.
•
You can use the ‘Outgoing Pmnt with Cash Disc. From’ field to specify the
lower limit for payments with cash discount deduction. When maintained,
the system pays (after deducting the cash discount) only items having cash
discount percentage rate more than (or equal to) the one specified in this
field. If cash discount percentage rate is less than the one entered by you in
this field, then, the system makes the payment only at the due date for net
payment.
Enter 99 in the ‘Outgoing Pmnt with Cash Disc. From’ field, to delay the
payment as long as possible and to ensure that the payment is always net.
•
Select ‘Max. Cash Discount’ check-box to ensure that maximum cash discount
is always deducted when paying your vendor invoices automatically.
Outgoing Payments
197
•
iii.
For both vendors and customers, enter the special G/L transactions that need
to be paid through the payment program: enter A (down payment), F (down
payment request) and H (security deposit) for vendors; for customers, enter
A (down payment), F (down payment request), G (Guarantee), H (security
deposit), and P (payment request). You may also maintain an exception list.
• ‘Save’ the settings.
Repeat the steps and configure all the company codes; in each case, identify clearly
the paying and sending company codes.
With this we are now ready to configure the 2nd step in automatic payment program: setting
up the paying company code for payment transactions.
6.3.3 Set Up Paying Company Codes for Payment Transactions
Using this configuration activity, you can specify the minimum amount for creating an
incoming or outgoing payment. Besides this, you can also maintain the forms and sender
details for payment advices and sheets accompanying EDI.
Project Dolphin
BESTM has indicated that they want to avoid large numbers of small payments. Accordingly,
BESTM wants the system to be configured in such a way that there will not be any automatic
payment processing, including the debit memos, if the payment amount is less than $25 for
all the US-based company codes and INR 500 for company codes 1210 and 1220, for all
incoming and outgoing payments. In all cases, wherein the payments proposed are less than
these minimum thresholds, the system will accumulate them till the limit is crossed and then
pay as in the normal course. In the case for bill of exchange (BoE) payments, BESTM wants
the system to be configured to create one BoE per invoice.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Method/Bank Selection for Payment Program > Set
Up Paying Company Codes for Payment Transactions:
i.
ii.
On the resulting screen, click on ‘New Entries’ and on the next screen (Figure 6.30),
enter the paying company code in ‘Paying co. code’ field (say, 1110).
You will see ‘Use in Company Codes’ button to the right of the ‘Paying co. code’ field.
When you click on that, the system brings up a pop-up screen listing the company
codes (1110 and 1120, in our case) for which this ‘Paying co. code’ (1110, in our case)
is used for payment.
198
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 6.30 Setting up Paying Company Codes for Payment Transactions
iii.
Enter appropriate settings for the ‘Control Data’:
• Specify the minimum amount for both incoming payments and outgoing
payments, below which the system will not process automatic payments. So,
the system generates a debit memo, for an incoming payment, only when it
is more than the amount entered in ‘Minimum Amount for Incoming
Payment’ field; else, the system prints the amounts in an exception list and
accumulates them for processing at a later date. In the case of outgoing
payments, the system processes the payment only if the payment is more
than or equal to the amount entered in ‘Minimum Amount for Outgoing
Outgoing Payments
•
•
•
199
Payment’ field; else, here, also such line items that are less than the threshold
limit is printed in an exception list and accumulated for payment in future.
You may select ‘No Exchange Rate Differences’ check-box enabling the
system not to post exchange rate differences, if any, for foreign currency line
items, during automatic payment processing. Else, the system determines
exchange rate difference (using foreign exchange translation), and posts the
same automatically per payment.
The behaviour of ‘No Exch.Rate Diffs (Part Payments)’ flag is similar to that of
‘No Exchange Rate Differences’ check-box except that this applies only to
partial payments.
Select ‘Separate Payment for Each Ref.’ check-box to settle invoices and
credit memos having the same payment reference in one payment. Used in
countries like Norway, Finland etc, you should set this flag only if payment
methods need a payment reference for each payment.
You cannot generate an outgoing payment for payment references
referring to credit memos, when separate payments are made by payment
reference. Also, when you make payments, by payment reference, the
system will not offset between a customer and a vendor, unless the payment
reference in a customer line item is also the same payment reference in a
vendor line item.
•
Select ‘Bill/Exch Pymt’ check-box to enable display of bill of exchange (BoE)
fields during payment transaction. You will select this if you want use BoE,
BoE payment requests, or the check/BoE procedure in the paying company
code. If not selected, but if you have already made the settings for payment
transactions with BoE, then, the system deletes all those settings.
Only when you select ‘Bill/Exch Pymt’ check-box, the system brings up
additional details on the screen under ‘Bill of Exchange Data’.
•
•
•
Under ‘Create bills of exchange’, select the appropriate radio-button. You
need to select the first one namely ‘One Bill of Exchange per Invoice’ for
BESTM’s paying company codes. In the case of BoE due date or BoE payment
requests for incoming payments, you need to maintain the due date in the
appropriate fields.
Maintain the form and sender details by expanding the data blocks ‘Forms’
and ‘Sender Details’.
‘Save’ the settings.
200
iv.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Repeat the steps and configure the appropriate settings for all other paying company
codes of BESTM Corporate.
With this, let us move on to configure the payment methods, for each country, for the
payment transactions.
6.3.4 Set Up Payment Methods per Country for Payment Transactions
A ‘payment method’, in SAP, specifies how payment is made when you enter it in customer /
vendor master record, line items, or payment run (parameter). There are several payment
methods supported in SAP, including check (or cheque), bill of exchange, bank transfer, direct
debit etc.
Per payment method per country, you have to specify (a) if the payment method is to be used
for incoming payment or outgoing payment, (b) the characteristics for classifying the payment
method that includes type of payment method (like, check, bank transfer, bill of exchange
etc) and other features including, for example, if the payment method is valid for personnel
payments, (c) the master record control settings as to, for example, entering the bank details
(say, account number, SWIFT code etc), entering the address / postal details etc, (d) the
parameters for posting like document type for posting, clearing document type to be used
etc, and (e) the settings for payment medium. You also need to maintain the currencies that
can be used per payment method per country. If you do not specify any currency, then, you
can use that payment method, in that country, for payments in all currencies.
Figure 6.31 Payment Methods in Vendor Master
Outgoing Payments
201
You will maintain the payment method in a couple of places: in the customer / vendor
master record, in a line item of customer / vendor, and also while maintaining the payment
run parameter (‘Payment Methods’ under ‘Payment Control’) for executing the automatic
payment run.
You need to enter the payment method in vendor (or customer) in the ‘Payment Methods’
field under ‘Automatic Payment Transactions’ to enable the system to pick up the appropriate
payment method for that business partner for automatic payments. You can maintain more
than one payment method in the master record. However, the order in which you maintain
the payment methods is important: the system will try making payment using the first
method, then uses the second one if the first one is not successful and so on. Consider, for
example, you have maintained (Figure 6.31) CELMN as the payment methods: now, the
system will consider the payment method C with the first priority before considering E, L, M
and so on in the order it has been maintained.
Though you can maintain more than one payment method in a customer / vendor master
record, you can enter only one payment method (from those mentioned in the master record)
in a line item. The payment method entered in the line item takes precedence; it will override
the payment methods in the master record, irrespective of the order in which they have been
entered into. For example, you have maintained M (direct debit) as the payment method in a
vendor line item, and you have maintained CELMN as the payment methods in vendor master.
Now, the payment method M (entered in the line item) has the priority over the other
methods (CELMN) even though M is not at the first place in the ‘Payment Methods’ field in
the master record.
Take care not to enter a payment method in the ‘payment run parameter’ that is conflicting
with the payment methods already maintained in the master record or line item. Else, the
system will not process the automatic payment. For example, if you enter T [Bank transfer
(ACH CTX)] as the payment method, in payment run parameter, but have maintained M as
the payment method in a line item and CELMN as the payment methods in vendor master,
then, the system will not process the line item for payment as the payment method in
payment run parameter is in conflict with the payment method maintained in line items and
master record.
The standard system comes delivered with the default settings of applicable payment
methods for each of the countries (Figure 6.32). You may use that as such.
202
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 6.32 Country-Specific Payment Methods for USA
Project Dolphin
BESTM wants does not want to define any new payment method. Instead, they have indicated
that, they will go ahead using the default payment methods that have been configured in the
standard system for both USA and India.
However, if you want to define a new payment method for a country, you may do so as
detailed below:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for
Payment Program > Set Up Payment Methods per Country for Payment Transactions.
You may also use Transaction OBZ3.
When you use Transaction OBZ3, you will see a slightly different user interface,
for the first two screens, than the one you will be seeing when you use the menu path
(Figure 6.32).
ii.
iii.
On the resulting screen, click on ‘New Entries’ and maintain the required settings as
shown in Figure 6.33, on the next screen.
Once you have maintained the settings for the new payment medium, you may
double-click on ‘Currencies’ on the left hand side ‘Dialog Structure’ to specify the
currencies for which you intend to use this new payment medium. As mentioned
already, you just need to leave this as blank if you want this payment medium valid
for all currencies.
Outgoing Payments
iv.
203
Double-click on ‘Permitted Destination Countries’ on the left hand side ‘Dialog
Structure’, to maintain the destination countries in which you want to use this
payment method. As in the case of currency settings, you can leave this table empty
so that the payment method is valid for all countries
Figure 6.33 Details of Payment Method Settings for ‘Check’ for USA
If bank details are required for a payment method, and, for example, if you have selected
‘EU Internal Transfer’ check-box for the payment method (in step ii), then, you have to enter
an EU country or one of the exception countries as the destination country in step (iii) without
which you will not be able to process the payment using this payment method.
v.
‘Save’ the settings when completed.
204
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
We have already seen that you can maintain the payment methods in a couple of places.
If that is the case, then, how the system selects the appropriate payment method for a
particular payment run?
Scenario 1: Payment method is maintained in all the three places: payment run parameter,
line item and customer / vendor master.
Suppose you have maintained C as the payment method in payment run parameter and also
in the line item. However, you have maintained multiple payment methods (ELMNC) in
customer / vendor master. Now, the payment program selects C as the payment method as
this is maintained both in the line item and also in payment run parameters notwithstanding
the payment methods mentioned in business partner’s master record.
Scenario 2: Payment method is maintained in two places: payment run parameter and
customer / vendor master. No payment method is maintained in the line item.
Suppose you have maintained C as the payment method in payment run parameter and have
maintained multiple payment methods (ELMNC) in customer / vendor master. Since there is
no payment method maintained in the line item, the program verifies if the payment method
entered in the business partner’s record is the same in payment run parameters also. If there
is a single payment method in master record and if it is the same in the payment run
parameter also, then the program uses that method. If more than one payment method has
been entered in the master record, then the program proceeds as under: (a) the program
checks the first payment method in the master record (E, in our case) and compares that with
the payment method maintained in the payment run parameter (C, in our case); if both are
same, then, the program uses that payment method, else (b) the payment program checks
the second entry of payment method in the master (L), and compares that again with the
method in the payment run parameters (C); if both are same, then, the program uses that
payment method, else (c) the program checks the 3rd method and the iteration goes on.
With this, we are now ready to configure the next step: setting up the payment methods per
company code.
6.3.5 Set Up Payment Methods per Company Code for Payment Transactions
Specify, here in this configuration activity, which payment methods you want to use per
(paying) company code. You can also determine the conditions under which a payment
method should be used. You can specify the amount limits (for payments) per payment
method, maintain the specifications for grouping items for payment (say, making a single
payment for all the marked items), enter the settings for foreign/foreign currency payments,
make the specifications for optimizing bank selection, enter the appropriate settings for the
Outgoing Payments
205
system to select the correct form for the payment medium and maintain the specifications
for issuing payment advice notes, if any.
While maintaining the amount limits for payment methods, always specify a maximum
amount; else, you will not be able to use that payment method. In case you maintain the
payment method in an open item, then, the system ignores the amount entered here, in this
configuration, as the limit for payment method.
Project Dolphin
As regards payments through automatic payment program, BESTM wants to have the system
configured to reflect the following:
All the line items that are due on a particular date should be grouped and paid in a single
payment. If line items are associated with a payment method explicitly, then, the system
should pay those items; else, if the payment method is not specified explicitly in the line item
and if the system selects the payment method automatically, then, several items can be paid
together. The ‘extended individual payment’ should be activated to make it possible to
include and offset all available credit memos for a payment group. For payment methods like
bank transfer, the system should make payments abroad using the business partners’ banks
in their respective countries. The system should be able to make payments – for all payment
methods - in other currencies, other than the company code currency. BESTM wants bank
optimization using their own house banks and business partners’ banks so as to optimize
international payments.
As regards payments, if the payment method is check, then, all in-country payments should
not be less than $25 (for US-based company codes) and INR 500 for Indian company codes. If
the payment is more than $5,000 (or INR 250,000) then, it has to be made through bank
transfer or direct debit. For direct debit, bank transfer or card payment, there is no lower limit
for payment. In cases of composite payments, BESTM wants the system to split the payment
by grouping the invoices with the appropriate credit memos, for payments exceeding $10,000
in the case of US-based company codes (or INR 500,000 for all the India-based company
codes), for all the allowed payment methods, for both domestic and international payments.
To configure the payment method per company code, for payment transactions:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for
Payment Program > Set Up Payment Methods per Company Code for Payment
Transactions.
206
ii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the resulting screen, select ‘New Entries’ and maintain the required settings per
payment method per company code (Figure 6.34), on the next screen:
Figure 6.34 Payment Method Configuration Per Company Code
•
•
•
Enter the paying company code (1110), and select the payment method (T).
Enter the amount limits (minimum and maximum). If a payment is below the
‘Minimum Amount’ or above the ‘Maximum Amount’, then, the system will
not process the payment using this payment method. If you have maintained
payment methods in the customer/vendor master record under the
‘Payment Methods’ field under ‘Automatic Payment Transactions’ data block
in the ‘Vendor (Customer): Payment Transactions’ tab in the Company Code
area, then, the system ignores the maximum / minimum amount entries
entered here, if it contradicts with the payable amount to that business
partner.
When you make an entry in ‘Distrib. Amount’ field, then, the system analyses
the payments exceeding this amount to see if it is possible to split those
payments into more than one payment but not exceeding this amount. The
system makes the payment method check independent of the payment
method specification in the document item. However, this limit in the ‘Distrib.
Amount’ field will not have any effect on payment proposal processing. The
‘Distrib. Amount’ field settings cannot be used together with ‘Enhanced
Individual Payment’ and also with ‘Payment per Due Day’.
Outgoing Payments
207
Consider that the amount limit to be split and distribute for the payment
method ‘External Payment’ is, $10,000.
Scenario: 1. You have two invoices $15,000 & $11,000 and four credit memos
$2,800, $2,200, $700 & $800. You, now, have the group of document items
totalling $19,500 to be paid together. Once the system checks the ‘External
Transfer’ as the payment method successfully, it creates two payment
documents: one for $10,000 (clearing invoice of $15,000 and credits of
$2,800 & $2,200), and another for $9,500 (clearing invoice of $11,000 and
credits of $700 & $800).
Scenario: 2. You have two invoices $15,000 & $11,000 and two credit memos
$1,800, $900. Now, you have these group of documents totalling $23,300 to
be paid together. The check, for the payment method ‘External Payment’, will
not be successful as not all the invoice items, for this payment, can be
reduced by the corresponding credit memos to the maximum distribution
limit of $10,000. To proceed, you may select a different payment method.
Else, the system puts them in the exception list as no suitable payment
method is found.
Scenario: 3. You have two invoices $15,000 & $11,000 and a credit memo
$6,000. Now, you have these group of documents totalling $20,000 to be paid
together. The check, for the payment method ‘External Payment’, will not be
successful as no proportional distribution of credit to invoices can be made
(system does not bifurcate $6,000 to distribute to invoices as $5,000 and
$1,000).
iii.
Under ‘Grouping of Items’:
• When you select 'Single Payment for Marked Item' check-box, then, it makes
the system to pay the open items, that contain this payment method,
individually. So, all the items with explicit payment method are paid
individually. However, you can pay several items together, when the payment
method is not specified explicitly, but instead is selected by the payment
program.
• Select ‘Payment per Due Day’ check-box to group payments that are due on
a particular due date. You can use this to leverage to get maximum cash
discount. When not selected, then, the payment program groups –
irrespective of due date - all the payments per vendor / customer. For
example, if the due date of a vendor line item is earlier than the payment
run’s posting date, the system replaces the due date with the payment run’s
208
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
posting date, so that all items that are overdue on the posting date are
grouped and paid together with a single payment. Suppose, if such a grouping
results in a credit balance, then, the system groups those items that have
debit balances with different due dates and then makes the payment.
If you set the ‘Single Payment’ indicator in the customer / vendor master
record (Figure 6.35), then, the system pays every customer/ vendor open
item separately during automatic payment. That is, the system does not
group open items together for payment.
Figure 6.35 Configuring ‘Single Payment’ in Vendor Master
•
You can use the ‘Extended Individual Payment’ to process open items of a
payment group (to be defined separately) individually according to predefined rules. You can include and offset all available credit memos for the
payment group. However, in case of individual payments, you can offset only
credit memos with invoice reference; you cannot offset credit memos
without invoice reference. You can form new payment groups with the rules
Outgoing Payments
iv.
209
like, items with the opposite payment direction (say, credit memos - F110)
have to be offset with the other items, invoice-related credit memos to be
offset always with the related invoice, credit memos w/o invoice reference
can be grouped together with any of the invoices for a payment group etc.
For configuring ‘Foreign Payments / Foreign Currency Payments’:
• Select ‘Foreign business partner allowed’ to enable the payment method to
be used for payments with customers/vendors abroad.
• Select ‘Foreign Currency Allowed’ flag to use the payment method for
payments in foreign currency. Set this indicator if you can transmit the
currency key to the bank using the payment medium used.
Do not select this check-box for checks with the local currency key or for
payment methods for domestic DME, wherein the currency field is not
defined in the format description.
•
Select ‘Cust/Vendor Bank Abroad Allowed?’ check-box to route the payment
from a bank of the customer/vendor who is abroad. You cannot use this
payment method if you do not set this flag and when the customer/vendor
does not have a bank account in paying company code’s country. You will
normally select this for payment methods such as bank transfer (T), and
external transfer. However, as a prerequisite, you need set up the required
bank settings in customer / vendor master records.
SAP supports a variety of bank transfers. The bank transfers happen via
different variants of ACH (Automated Clearing House) transactions. ACH
enables automatic fund transfer, across banks and financial institutions
through e-payments.
SAP supports various formats of ACH:
1. ACH-CCD where CCD refers to ‘Cash Concentration and Disbursement’ for
corporate credits and debits. This is the most common automated payment
for corporate (business) accounts.
2. ACH-PPD: with the PPD standing for ‘Prearranged Payment and Deposit’,
this is mainly used to pay (or receive) from consumer (personal) accounts, for
example, payroll payment to employee accounts.
3. ACH-CTX: here the CTX stand for 'Corporate Trade Exchange' and ACH-CTX
is used mainly by corporates and government for money transfer.
210
v.
vi.
vii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Select the suitable option under ‘Bank selection control’. You have three options
including ‘No Optimization’. The ‘Optimize by Bank Group’ option lets the system to
select the most appropriate pair of your bank and that of your business partner’s for
a payment method like bank transfer. When you select ‘Optimize by postal code’, the
system makes use of the postal code and arrives at the bank that is geographically
nearer to the business partner’s location. However, to make use of this option, you
need to define the range of postal codes serviced by the bank(s).
Maintain the required settings for ‘Form Data’ and also for the payment advice
(‘Pyt.adv.ctrl.’).
‘Save’ the settings, when completed. Repeat, and make the settings for all the
payment methods that you will use in a particular company code (Figure 6.36).
Figure 6.36 Configuring Payment Methods Per Company Code
viii.
Repeat the steps for configuring the payment methods for all the paying company
codes.
With this, we are, now, ready to set up the payment medium format for paying company
codes.
6.3.6 Set a Payment Medium Format per Company Code
The system uses the payment medium format to control how payments (and debit memos)
to the bank are created. The specifications, per payment medium format, is published by the
banks or the central banking committees of the country. Use this step to specify which
payment medium format is to be used for each combination of ‘company code-payment
method-house bank’. Per payment medium format, you can also decide if you also want to
add a note to payee.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Method/Bank Selection for Payment Program > Set
Outgoing Payments
211
a Payment Medium Format per Company Code. On the resulting screen, click on ‘New Entries’
and define the required settings:
i.
ii.
iii.
iv.
v.
Enter the paying company code (‘CoCd’), and enter a payment method (‘PM’).
Enter the house bank (‘House bk’) and select the suitable payment medium format
(‘Payt Mdm Format’). Enter the appropriate format supplement (‘Addit.’) which lets
you differentiate between the collection and direct debiting procedures in the case
of debit memos. The supplement will either be printed in the coding line of the
payment medium or transferred into the appropriate field during DME.
Enter the ‘Alternative Format Type’ which specifies how payment files from the backend system should be transferred to the house bank. When you select ‘SAP MultiBank Connectivity’, the system automatically sends the payment files to your house
bank via SAP Multi-Bank Connectivity. When left blank, the system does not send the
payment files.
You may also maintain a note to payee by selecting a row containing the ‘company
code-payment method-house bank’ combination, and double-clicking on ‘Note to
Payee’ on the left hand side ‘Dialog Structure’.
Repeat the steps for all the house bank-payment method combinations and ‘Save’
the details (Figure 6.37).
Figure 6.37 Configuring Payment Medium Format Per Company Code
vi.
Repeat the settings for all the paying company codes.
The next step is to set up the bank determination for payment transactions.
6.3.7 Set Up Bank Determination for Payment Transactions
Here, you can make settings that determines how the payment program selects the banks or
bank accounts for making the payments. In the process, (a) you specify which house banks
are permitted and rank them in a list, (b) per house bank and payment method (and currency,
if required), you then specify which bank account is to be used for payments, (c) per account
at a house bank, you, then, enter the amounts that are available for the payment run; you
212
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
can maintain separate amounts for incoming and outgoing payments, (d) you also specify how
many days should elapse between the posting date of the payment run and the value date at
the bank; this will dependent on the payment method, bank account, payment amount, and
currency, and finally (e) you define the charges that are printed on the BoE forms, if any.
In determining the bank account, the system first runs ‘classic bank account
determination’. It uses the ‘enhanced settings’ only if it cannot determine an account in classic
bank account determination.
In the classic view, you can enter only one bank account with its account determination for
each combination of ‘house bank-payment method-currency’. The settings of classic bank
account determination may not be sufficient: (a) when posting the open items wherein you
have already defined which bank account is to be used, and (b) when you want to define a
ranking of multiple accounts for the same house bank. So, in both these cases you need to
define the account determination exclusively in the ‘Bank Accounts (Enhanced)’ view.
Project Dolphin
The BESTM Corporate has indicated to the project team that Bank of America will be the
primary bank for all the payment methods, followed by Chase Manhattan and Citi Bank in that
ranking order. It has been envisaged to provide an amount limit of $ 9,999,999,999 for Bank
of America for facilitating all the automatic payment transactions (outgoing payments). The
limit for the other two banks would be $ 999,999,999 in each case. In the case of incoming
payments, there should not be any limit restriction imposed. The value date should be 1 day
after, for all the payments through electronic format; however, it would be 3 days after for all
the checks denominated in the local currency. For house banks in India, the limits will be the
same but denominated in INR.
To configure the settings for bank determination:
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for
Payment Program > Set Up Bank Determination for Payment Transactions. You may
also Transaction REMMHBACC.
On the ‘Display View “Bank Selection’: Overview’ screen, select the row under ‘Bank
selection’ and double-click on ‘Ranking Order’ on the left hand side ‘Dialog Structure’.
On the next screen, click on ‘New Entries’ and maintain the settings on the resulting
screen (Figure 6.38):
• Enter the payment method (‘PM’), currency (‘CrCy’), ranking order (‘Rank
Order’) and the house bank (‘House bk’). The ranking order is the sequence
Outgoing Payments
213
used in selecting a particular house bank. The house bank with a ranking
order of 1 will be the first bank to be picked up, by the system, for the
payment run for that payment method.
You can use the ‘House bk’ to denote the house bank that would pay
the BoE created with a check/bill of exchange payment. Also, you can use
‘Acct for Bill/Exch’ field to store the bank account at the local bank against
which a BoE should be paid from the check/bill of exchange payment.
Figure 6.38 Configuring Bank Determination – Ranking Order
•
Repeat the entries to cover all payment methods, currency and house banks
that you may require in the ranking list. Since you can assign multiple
currencies and several house banks to a single payment method, you may
need to repeat the entries for a particular payment method to cover all
scenarios.
If you want a particular house bank and a particular currency to be valid
for all payment methods, then you need to leave the payment method (‘PM’)
field as blank. You can also leave the currency (‘Crcy’) field as blank so that
the particular row will be valid for all currencies for the given ‘payment
method-house bank combination’. For a single payment method, you can
maintain a maximum of 9,999 house banks with the appropriate ranking
order.
iv.
Now, double-click on ‘Bank Accounts’ on the left hand side ‘Dialog Structure’ and
maintain the required accounts by clicking on ‘New Entries’ (Figure 6.39):
• Enter the house bank, payment method, currency (you can leave this as blank
to make the settings valid for all currencies), account identifier at the bank
(‘Account ID’) and the G/L account (‘Bank Subaccount’) to which the
transactions will be posted to in the SAP system.
214
•
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Repeat and maintain the settings for all the house banks for the given
payment method / currency combination. You will be able to maintain only
one account per ‘house bank- payment method-currency’ combination and
this is known as the ‘classic bank account determination’.
Repeat the steps and maintain for all the payment methods.
Figure 6.39 Configuring Bank Determination – Bank Accounts
v.
vi.
Similar to the step (iv) above, you can maintain the settings for ‘enhanced bank
account determination’. When the system is unable to select the appropriate account
in the classic bank account determination, then, it will use the settings maintained
here. To configure, double-click on ‘Bank Accounts (Enhanced)’ on the left hand side
‘Dialog Structure’.
Now, you may maintain the settings for available amounts. Double-click on ‘Available
Amounts’ on the left hand side ‘Dialog Structure’, click on ‘New Entries’ and maintain
the details on the next screen (Figure 6.40):
Figure 6.40 Configuring Bank Determination – Availabe Amounts
•
•
•
Enter the house bank and the account ID at that house bank.
You need to enter the ‘Days’ only if you have BoE payments to be posted
before their due date. In such a case, the value date of BoE on the bank
account is expected within the number of days entered here. Enter 999 in all
other cases, so that the system will not take this value into account.
Enter the currency.
Outgoing Payments
•
215
Maintain the amount limit for outgoing payment (‘Available for outgoing
payment’). The amount entered here in this field is only used for payments
with which the bank debit entry is expected during the number of days
(‘Days’) displayed.
For example, the system checks to see if this amount (‘Available for
outgoing payment’) in the account is sufficient for making an outgoing
payment from this house bank using that payment method. If the amount in
the bank account is insufficient for the outgoing payment, the payment
program moves on to select another bank account, based on the ranking
order, to determine if there is a sufficient amount in that bank account to
cover the entire payment. If yes, then the payment is processed; else (that is,
when the amount is not sufficient), the system will not process the payment.
Note that when the amount in a particular account is insufficient for
payment, the system will not draw the shortfall from other bank account but
moves to the other bank account to make the payment in full.
•
vii.
viii.
Also enter the incoming payment (‘Scheduled incoming payment’), if
required. This limit applies only to incoming payments for which the bank
credit memo is expected during the number of days (‘Days’) displayed. You
may also leave this as blank (as in the case of BESTM) to receive any amount
as incoming payment without a limit.
Repeat and maintain the settings for all the (‘House bank’- ‘Account ID’-‘Currency’)
combinations.
Now, double-click on ‘Value Date’ on the left hand side ‘Dialog Structure’, click on
‘New Entries’ and maintain the details on the next screen (Figure 6.41):
Figure 6.41 Configuring Bank Determination – Value Date
•
•
Enter the payment method, house bank, and account ID at the house bank.
Enter the ‘Amount Limit’ up to which the settings specified here will be valid.
216
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
In the ‘Days to value date’ field, enter the number of days before a debit
and/or a credit memo transaction is accounted for in the bank account. The
system will add the days you enter here to the posting date to arrive at the
date that is relevant for cash management and forecast. For example, if the
payment method is bank transfer, direct debit etc., then you can expect
payments to be accounted at the bank on the next day; hence, you may enter
1 in this field. On the other hand, if the payment method is, say, check then
there could be a delay of more than 1 day and it may even dependent on the
amount of the check.
For example, if you enter 3 in this ‘Days to value date’ field, then, the
system adds this to the posting date (say, 15-Mar-2020) of the payment run
date to arrive at the value date as 18-Mar-2020. If you do not enter a value
in this field, then, the posting date of the payment run = value date.
You can maintain the ‘Check Cashing Time’ in the customer / vendor master
record (Figure 6.42). The system uses this value to arrive at the value date. If
you keep this ‘Check Cashing Time’ as blank, then, the payment program uses
the value entered in ‘Days to value date’ field in the payment program.
Figure 6.42 ‘Check Cashing Time’ Field in Vendor Master
ix.
Double-click on ‘Expenses/Charges’ on the left hand side ‘Dialog Structure’ and
maintain the charges that are printed on the BoE forms, if any (not required in all the
countries, but in vogue in country like Spain).
This completes the configuration for bank determination.
Outgoing Payments
217
So, how the payment program determines the correct house bank for the payment?
First, the payment program tries identifying a house bank for a given ‘payment methodcurrency’ combination. If it is unable to find a house bank, for the given ‘payment methodcurrency’ combination, it tries to find a house bank for the same payment method but without
the currency stipulation. If it is successful, then it goes ahead with the bank. Then, secondly,
it iterates to find out the suitable account at the selected house bank. Finally, it checks if the
amount limit at the selected house bank account is sufficient for the payment. The program,
during this process, finds only one house bank that matches the criteria; if more than one
bank is found, then, it makes use of the ‘ranking order’ to select the house bank with the
highest ranking order and uses that bank for the payment. This is, of course, assuming that
there is no bank optimization either via postal code or bank group. If there is such an
optimization, the selection will be based on the results of optimization.
If the payment program does not find a house bank fulfilling all the three criteria - house bank,
house bank account and available amount limit – it tries to locate another house bank that
fulfils these requirements for the given payment method. If it cannot find a house bank, then
it concludes that the payment cannot be made using that payment method. Now, it starts all
over, and begins checking for another payment method currency combination. This iteration
goes on till the program finds suitable house bank for a given payment method.
Let us, now, move on to discuss how to configure the value date rules.
6.3.8 Define Value Date Rules
We have already discussed, in the previous Section, the effect of adding the days in ‘Days to
value date’ for specific ‘payment method-house bank-account ID’ combination (while
configuring the value date in bank determination for payment transactions) and also the
effect of entering the ‘Check Cashing Time’ in business partner’s master record. Let us see,
now, in this Section, how you can make certain specifications for some of the bank
transactions like incoming checks, BoE etc., per house bank and per account.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Method/Bank Selection for Payment Program >
Define Value Date Rules. You may also use Transaction OBBA.
On the resulting pop-up screen, maintain the company code and proceed to configure the
settings on the next screen. When fully configured, the system adds / subtracts the specified
days as deviation from the reference date (‘R’) which may be the document date or posting
218
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
date or due date. After this, the system checks the date thus arrived with a factory calendar
and decides the value date for that transaction.
You may configure the system to arrive at the value date by defining either the value
date rules (as above) or value date settings as in setting up the bank determination for
payment transactions that we discussed in the previous Section (6.3.7). Both are not required.
We will not be configuring this for BESTM as we have already configured the value date in
bank determination wherein we have maintained the ‘Days to value date’.
The next step is to assign the payment method to bank transactions to use the value date
rules that have been defined previously.
6.3.9 Assign Payment Method to Bank Transaction
Once you have defined the value date rules, you need to assign the payment method to each
house-bank related transaction using the menu path: SAP Customizing Implementation Guide
> Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions
> Outgoing Payments > Automatic Outgoing Payments > Payment Method/Bank Selection for
Payment Program > Assign Payment Method to Bank Transaction. You may also use
Transaction OBBB.
With this, we are ready to discuss payment groupings.
6.3.10 Define Payment Groupings
Using this activity, you can define the grouping keys which you can use to settle a customer
or vendor's open items together. Per grouping key, you may specify up to three fields (like,
ZUONR – Assignment Number) from the database tables BSIK (vendors) or BSID (customers).
The system, then, settles the items containing the same entries in these specified fields. You
can, then, enter the appropriate grouping key in the customer/vendor master record.
You will use grouping key if you do not want all the open items of a customer / vendor to be
paid together; instead, you want only those items which belong together, as defined in the
grouping key, to be grouped into a single payment. For example, if you use SAP Loan
Management, you may define a payment grouping so that the system uses that key for
grouping open items with the same loan number together.
Project Dolphin
BESTM has indicated that they do not want to use payment grouping; Instead, wanted to
make use of the default grouping of open items of customers / vendors in the automatic
payment program.
Outgoing Payments
219
To define a payment grouping key, which you can enter later in the customer / vendor master,
you may use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Method/Bank Selection for Payment Program >
Define Payment Groupings. You may also use Transaction OBAP.
The next activity is to prepare automatic posting for payment program.
6.3.11 Prepare Automatic Postings for Payment Program
Define the posting keys and special G/L indicators for postings that are required for the
automatic payment program. You can just go ahead with the default settings. However, you
may use this configuration step to check if the settings are correct.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Automatic Posting > Prepare Automatic Postings for
Payment Program. You may also use Transaction OBXC.
On the resulting screen, you will see three procedures namely, ZBA (Payment program: bank
posting), ZWE (Payt program: bill exch/bill payt reqst) and ZWO (Payt program: bank bill
liability) under the payment program group ZAH. You may double-click on any of the
procedures to check the associated settings (Figure 6.43).
Figure 6.43 Automatic Posting Settings for Payment Program
In the next step, let us define the posting keys and special G/L indicator for automatic posting
of payment requests.
220
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
6.3.12 Prepare Automatic Posting for Payment Requests
This is similar to the previous step except that you will be defining the posting keys and special
G/L indicator for automatic posting of payment requests through the automatic payment
program. Here, also you can just go along with the standard settings without changing
anything.
A request for payment (‘payment request’) activates a payment by the payment
program, and the system pays the same when it is due.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Automatic Posting > Prepare Automatic Posting for Payment
Requests. You may also use Transaction OBXP (Figure 6.44).
Figure 6.44 Automatic Posting Settings for Payment Requests
The next task is to include additional search fields for payments.
6.3.13 Select Search Fields for Payments
Here, you can define the search fields which will be used by the system to search and find
individual payments or line items that are paid. You can use these search fields as the filter
criteria for maintaining the payment proposal run and also for the display of the proposal run
/ payment run. The standard SAP system comes delivered with several search fields which will
meet most of the normal business requirements.
Project Dolphin
The project team has suggested to the BESTM management not to go in for any additional
search fields for payments (and line item display) as the standard fields are more than
sufficient to be used as the criteria for maintaining proposal run besides displaying the
payment proposal / payment run.
Outgoing Payments
221
You may use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Run Display > Select Search Fields for Payments.
You may also use Transaction O7FC. On the resulting screen, you may retain all or delete some
or rearrange the order of appearance (Figure 6.45). If you want to add a new field, use the
‘Insert after’ button after positioning the cursor suitably, and select the fields by clicking on,
for example, ‘Standard Fields’ on the resulting pop-up screen.
Figure 6.45 Standard Search Fields for Payments in Payment Run
The next step is to look at the standard settings of search fields for line item display in
automatic payment program execution.
6.3.14 Select Search Fields for Line Item Display
This is similar to the previous activity except that the system uses the search fields for
displaying the line items paid. As in the case of search fields for payments, you can use these
search fields, as the filtering criteria, for maintaining the proposal run besides using them for
the display of proposal run or payment run.
You may use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Business Transactions > Outgoing Payments >
Automatic Outgoing Payments > Payment Run Display > Select Search Fields for Line Item
Display. You may also use Transaction O7FE. On the resulting screen, you may retain all or
delete some or rearrange the order of appearance (Figure 6.46). If you want to add a new
field, use the ‘Insert after’ button after positioning the cursor suitably, and select the fields by
clicking on, for example, ‘Standard Fields’ on the resulting pop-up screen.
222
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 6.46 Standard Search Fields for Line Item Display in Payment Run
This completes our discussion on automatic outgoing payments, and also the discussion on
outgoing payments.
6.4 Conclusion
You learned the details about the global settings that are required for outgoing payments;
during which you understood defining of various accounts for handling discount taken,
overpayments / underpayments, exchange rate differences, rounding differences, translation
settings, payment block reasons and so on.
You also learned about the settings required for both manual and automatic payments.
While discussing manual outgoing payments, you learned about the tolerances including
vendor tolerances, reason codes and also on how to prepare the system for handling crosscompany code manual payments. You learned that you need to define a ‘tolerance’ in the
system for dealing with the payment differences arising out of transaction posting in FI. By
defining a tolerance, you understood that you are instructing the system as to how to proceed
further: (a) what are the amounts or percentage rates up to which the system is to
automatically post to a separate expense or revenue account, if it is not possible to correct
the cash discount or (b) up to what difference amounts the system is to correct the cash
discount.
In configuring the automatic payment program, which can handle both incoming and
outgoing payments, you saw how to set up: the house banks, all / payment company codes
for payment transactions, the different payment methods etc. You understood that the bank
that you will use for making payments is known as the ‘house bank’, in SAP. You also
understood that you can have more than one house bank in a company code, and that you
need to enter a house bank in the master record of customer / vendor for the payment
program to use that bank. You learned that if you are not maintaining the house bank in
Outgoing Payments
223
customer / vendor master record, then, you have to maintain a rule by which the payment
program can determine the house bank automatically.
You understood how the system determines a suitable bank for a given payment transactions,
besides understanding the value date rules, payment groupings, automatic payment posting
etc. You did understand how the automatic payment program works from selecting the open
item payables, to selecting the appropriate payment method, house bank, account and finally
making and posting the payments, besides creating the payment media for electronic data
transfer.
With this, we are now ready to discuss outgoing invoices / credit memos, in the next Chapter.
7 Outgoing Invoices/Credit
Memos
M
ost of the settings for configuring outgoing invoices / credit memos are similar to
the ones that we discussed in Chapter 4 (incoming invoices / credit memos). The
unique steps for outgoing invoices / credit memos are:
•
•
•
Define Cash Discount Base for Outgoing Invoices
Define Tax Accounts for Outgoing Invoices
Define Posting Key for Outgoing Invoices/Credit Memos
Let us start with the definition of cash discount base for outgoing invoices.
7.1 Define Cash Discount Base for Outgoing Invoices
Here, you will be determining, per company code, if the tax amount is to be taken into account
in arriving at the base amount for calculating the cash discount amount.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Outgoing Invoices/Credit Memos
> Define Cash Discount Base for Outgoing Invoices, or Transaction OB70 to check and confirm
(Figure 7.1).
Figure 7.1 Cash Discount Base for Outgoing Invoices
The 'net’ discount base system of discount calculation is followed in countries like France.
When you select the ‘DiscBaseNt’ check-box, you enable the system to ignore the tax amount,
if any, in arriving at the discount base for calculating the discount. The discount, now, is on
the invoice amount less the tax. If you do not select the check-box, the system includes the
tax amount also in arriving at the discount base (‘gross’). The setting here does not affect
company codes where the discount calculation is configured at the jurisdiction code level, as
226
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
in US-based company codes including 1110. Hence, leave this as blank; but select the same
for India-based company codes.
When the cash discount base is 'net', note that SAP does not take into account the freight
and setup charges also. On the other hand, these charges along with the input tax, are all
considered while arriving at the discount base, when the cash discount base is 'gross'. If the
tax base is 'net', the discount base also needs to be 'net'.
You can also configure this while maintaining the company code global parameters
(Transaction OBY6); there, you will need to select / deselect the ‘Discount base is net value’
check-box. Next, let us define the tax accounts for outgoing invoices.
7.2 Define Tax Accounts for Outgoing Invoices
Using this configuration step, you can define to which G/L accounts the system should post
the different tax types to, in automatic postings.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Outgoing Invoices/Credit Memos
> Define Tax Accounts for Outgoing Invoices, or Transaction OB40:
i.
ii.
iii.
On the resulting screen, you will see the list of procedures like input tax (109), output
tax (190) etc., which have already been configured for the automatic posting. You just
need to maintain the G/L accounts for the required transactions like 109, 190 etc.
Select a transaction / procedure, and double-click on the same to reach the posting
rules screen. Click on ‘Posting Key’ and define the keys (debit 40, credit 50) if that has
not been defined earlier. ‘Save’ and click on ‘Accounts’ and enter the G/L account in
‘Account Assignment’ (Figure 7.2).
Repeat maintaining the posting key settings and G/L account entry for the other
procedures as well.
Figure 7.2 Tax Accounts for Outgoing Payments
Outgoing Invoices/Credit Memos
227
With this, let us understand the final configuration for outgoing invoices/credit memos, next.
7.3 Define Posting Key for Outgoing Invoices/Credit Memos
You define the posting keys, here, for customer / vendor and G/L account items which you
can use to enter for outgoing invoices and credit memos.
To configure, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Outgoing
Invoices/Credit Memos > Outgoing Invoices/Credit Memos – Enjoy > Define Posting Key for
Outgoing Invoices/Credit Memos, or Transaction OBXW. On the resulting screen (Figure 7.3),
double-click on the appropriate ‘Procedure’ (say, ‘Customer Item on Outgoing Invoice’ –
Transaction AGD) and confirm that you can use default posting keys as set by SAP (01 for
debit, 11 for credit). Come back to the previous screen, and double-click on other ‘Procedures’
to check the posting keys for transactions AGS and AGX.
Figure 7.3 Posting Key Definition for Outgoing Invoice/Credit Memo
This completes our discussion on the settings required for outgoing invoices/credit memos.
7.4 Conclusion
In this Chapter, you learned that most of the settings for configuring outgoing invoices / credit
memos are similar to the ones that we discussed while configuring incoming invoices / credit
memos in Chapter 4. Besides that, you learned here in this Chapter how to define the cash
discount base, tax accounts and posting keys for outgoing invoices/ credit memos.
Let us, now, move on to discuss the settings for incoming payments, in the next Chapter.
8 Incoming Payments
A
s in the case of outgoing payments that we discussed in Chapter 6, you can group the
configuration settings for incoming payments into the following three categories:
1. Incoming Payment Global Settings
2. Manual Incoming Payments
3. Automatic Incoming Payments
Let us start with the global settings for incoming payments.
8.1 Incoming Payment Global Settings
We have already discussed most of the settings like defining (a) accounts for
overpayments/underpayments, (b) accounts for exchange rate differences, (c) accounts for
rounding differences and (d) accounts for bank charges, (e) posting keys for clearing
transactions, (f) the settings for enabling translation, (g) payment block reasons and (h) the
default values for payment while discussing the global settings for outgoing payments in
Section 6.1 of Chapter 6. Hence, we are not repeating them here again. However, we shall
define the accounts that are required for posting the cash discount granted.
8.1.1 Define Accounts for Cash Discount Granted
Define the G/L account number(s) for posting the cash discount amount granted when
clearing open items. If necessary, as in the case of cash discount taken (in incoming payments)
you may differentiate the G/L accounts by tax codes.
To configure, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Incoming
Payments > Incoming Payments Global Settings > Define Accounts for Cash Discount Granted,
or Transaction OBX1. On the resulting pop-up, enter the chart of accounts (BEUS, for BESTM)
and on the next screen enter the G/L account for the system to post the cash discount
expenses (Figure 8.1).
230
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 8.1 G/L Account for Posting Cash Discount Taken
With this, let us move on to understand the configuration requirements for manual incoming
payments.
8.2 Manual Incoming Payments
Here also, the configuration settings are similar to the ones that we have already discussed in
Section 6.2 of Chapter 6, for manual outgoing payments. The settings include defining &
assigning tolerance groups, settings to take care of clearing differences and preparing for
cross-company code transactions. As regards ‘Defining Tolerance Groups for Employees), we
have already completed this in Section 6.2.1.1 of Chapter 6.
Let us move on to discuss the automatic incoming payments, next.
8.3 Automatic Incoming Payments
We have already covered automatic incoming payments while we configured the automatic
outgoing payments in Section 6.3 of Chapter 6.
With this, let us move on to discuss how to manage SEPA mandates in the system.
8.4 Management of SEPA Mandates
SEPA (Single Euro Payments Area) is an initiative by the EU (European Union). It is to make
the cross-border electronic payments as inexpensive and easy like a local payment within a
country. All the customers, businesses, and the government in the EU can undertake SEPA
payments in the form of instant debit / credit by leveraging the SEPA architecture. The SEPA
payments are free and is expected to help international business in the EU. There are about
40 member countries including the 28 EU member states and others like Liechtenstein,
Iceland, Norway, Switzerland, Vatican City, Monaco, San Marino and Andorra.
Incoming Payments
231
Since we are discussing FI configuration from the point of US and India, in this book, we
will not be discussing this in detail here. However, we shall give you a brief idea as how to
configure the SEPA mandates should you work with an EU member state.
In SAP, you can enter a SEPA mandate for each of your bank accounts. The SEPA mandate is
an authorization issued by your business partner (as debtor) for payment to be collected by
you (as creditor). It will be in the form of a direct debit.
Towards configuring the SEPA mandates, the first step is to make the general settings.
8.4.1 General Settings
Here, you will activate SEPA mandate management in the system. In the process, you can
specify a subscreen for displaying additional data, register your own function modules that
make data supplements and further checks, and finally define a form name for printing SEPA
mandates.
Figure 8.2 Activating SEPA Mandate Management
To configure, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Incoming
232
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Payments > Management of SEPA Mandates > General Settings, or Transaction
FI_APAR_SEPA_CUST. On the resulting screen, click on ‘New Entries’ and:
•
•
•
•
Select the appropriate application (‘Applic.’).
Activate SEPA Mandate Management.
Add, your own program/screen details for displaying additional data, if any.
Select the ‘Form Type’ and enter the ‘Form Name’ for printing SEPA form.
When ‘Saved’, the system brings up the appropriate functional modules for data
enhancement and checks besides filling in the ‘Other Parameters’ (Figure 8.2).
The next task is to define the available function modules for generating SEPA mandate IDs.
8.4.2 Define Available Function Modules for Generating Mandate IDs
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Incoming Payments >
Management of SEPA Mandates > Number Ranges for Mandates > Define Available Function
Modules for Generating Mandate IDs, or Transaction SEPA_MND_FM_MT. You can use the
standard settings, or you may enter your own function modules, if necessary, on the next
screen (Figure 8.3).
Figure 8.3 Function Module Configuration for Generating SEPA Mandate ID
The next step is to select the appropriate function module to generate the SEPA mandate ID.
8.4.3 Select Function Module for Generating Mandate IDs
You can select the appropriate function module to generate the SEPA mandate IDs with or
without the paying company code as the prefix. You can use either of the SAP-delivered
standard function modules: FI_APAR_MANDATE_PREFIX_MNDID (to generate mandate IDs
with the paying company code as the prefix) or FI_APAR_MANDATE_WOPREFIX_MNDID (to
generate mandate IDs without a prefix).
From the function modules made available in the previous task, you can select the
appropriate one in this step, by using the menu path: SAP Customizing Implementation Guide
> Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions
Incoming Payments
233
> Incoming Payments > Management of SEPA Mandates > Number Ranges for Mandates >
Select Function Module for Generating Mandate IDs, or Transaction SEPA_MND_FM_CUST.
On the resulting screen, click on ‘New Entries’ and select the appropriate function module on
the next screen, and ‘Save’ the details (Figure 8.4).
Figure 8.4 Selecting the Function for Generating SEPA Mandate ID
The next step is to define the number ranges for SEPA mandates.
8.4.4 Define Number Range Intervals
As in any other case of defining a number range for a company code, define the required
number range intervals for SEPA mandates for all the paying company codes.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Incoming Payments >
Management of SEPA Mandates > Number Ranges for Mandates > Define Number Range
Intervals, or Transaction SEPA_NR_MT. On the resulting screen, enter the (paying) ‘Company
Code’, click on ‘Change Intervals’ and maintain the required number range(s) on the next
screen under suitable number range key(s) (Figure 8.5).
Figure 8.5 Number Ranges for SEPA Mandate
Let us, now, assign the number range that we have defined in the previous Section to SEPA
mandates.
8.4.5 Assign Number Range Intervals
Here, you need to assign the number range interval for each combination of (‘Account Group
- ‘B2B’ Boolean-Payment Type’). The B2B Boolean decides if the mandate is for business to
business or otherwise. The ’Payment Type’ will identify if it is for a single usage or recurring
234
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
usage. When you create the mandate in this way, the system checks the ‘Account Group’, the
‘B2B’ Boolean, the ‘Payment Type’ of the mandate and assigns the next available number in
the number interval as the mandate ID, when it finds a match.
To configure the settings, use the menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions >
Incoming Payments > Management of SEPA Mandates > Number Ranges for Mandates >
Assign Number Range Intervals, or Transaction SEPA_NR_CUST. On the resulting screen,
select the ‘Account Group’, ‘B2B’ and the ‘Payment Type’. Then, for each combination of
these three variables, enter the number range interval key in ‘Number Range Interval’. ‘Save’
and repeat the settings for all the required account groups (Figure 8.6).
Figure 8.6 Number Ranges Assignment for SEPA Mandate
You may also need to configure ‘Status Management’ (defining non-permitted status changes
and reason codes for status change) and ‘Returns from the Bank’ (configuring how to process
the returned debit memos in electronic account statement processing and which changes are
to be made in the mandate when debit memos are returned by the bank).
This completes our discussion on managing SEPA mandates in the system, and also our
discussion in incoming payments
8.5 Conclusion
You learned that configuring the system for payments takes care of both incoming and
outgoing payments. You understood that the settings that you have already made in Chapter
6 for outgoing payments will also enable incoming payments: both manual and automatic.
However, you learned that you need to define G/L accounts to take care of cash discounts
granted while handling incoming payments.
You also learned about the SEPA mandates in this Chapter. You learned that SEPA (Single Euro
Payments Area) is an initiative by the EU (European Union), to make the cross-border
electronic payments as inexpensive and easy like a local payment within a country. You
understood that all the customers, businesses, and the government in the EU can undertake
SEPA payments in the form of instant debit / credit by leveraging the SEPA architecture. You
Incoming Payments
235
also understood that the SEPA payments are free and is expected to help international
business in the EU.
You learned that you need to first activate SEPA mandate management in the system and in
the process, you can specify a subscreen for displaying additional data, register your own
function modules that make data supplements and further checks, and finally define a form
name for printing SEPA mandates.
Let us move on to discuss the payments with payment cards, in the next Chapter.
9 Payments with Payment
Cards
Y
ou can use ‘Payment Cards’ - credit card, debit card, charge card, deferred charge card
etc - as a form of payment that offers your vendors with an almost-risk-free payment
guarantee, as the payment includes an authorization from the card issuing bank (or
financial organization) during payment transaction processing
SAP offers you with a wide range of functions both in SD and FI modules, for payment with
payment cards. It provides you with all the basic tools that you may need to handle payment
cards in different of business processes.
On the SD side, you configure the payment card types, payment card categories, payment
card plan types, authorization & settlement of payment cards, account determination for
payments through payment cards and so on. You can configure all these and much more
following the menu path: SAP Customizing Implementation Guide > Sales and Distribution >
Billing > Payment Cards.
On the FI side, you will need to configure only two settings:
1. Make Central Settings for Payment Cards
2. Assign G/L Account to Cash Clearing Account
Let us look at these two settings, here, in this Section, and let us start with the central settings
for payment cards.
9.1 Make Central Settings for Payment Cards
Here, in this configuration step, you can decide whether to retain the customer line items in
the accounting document when transferring data from SD component to FI. The advantage of
going in for this is that you can re-create the receivables against a customer automatically
(that is, the cleared items are reset) without the need for creating them again by a new
posting. You can, then, process these customer items in the dunning / payment program. You
can also specify the type of settlement document (that clears the G/L open items and creates
line items in a cash clearing account) when the settlement is made by the payment card
238
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
company. Additionally, you can specify the document type for resetting cleared items when
the card company cannot make a settlement.
Project Dolphin
BESTM wants to configure the system to take care of payment through payment cards as well.
In the process, it has been outlined, that the system needs to be configured in such way to
retain the customer line items in FI department during transfer of payment card data from SD
department. This decision has been taken, consciously, after several deliberations knowing
fully well that this will call for more database space; BESTM is ok with this, as the configuration
will provide (a) the advantage of displaying the receivables on the debit side and (b) the ability
to the department personnel to deal with any settlement problems of the payment cards.
You configure the settings by following the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Payments with Payment Cards > Make Central Settings for Payment Cards. You
may also use Transaction OBZH.
On the resulting screen (Figure 9.1):
Figure 9.1 Central FI Settings for Payment Cards
i.
Select the ‘Retain Cut. Item’ check-box under ‘Settings for forwarding documents to
FI’ to retain the customer line item details on FI side while transferring the data from
Payments with Payment Cards
239
SD. The system, then, clears the customer item as soon as the document is posted,
creates a corresponding identical cleared payment item, and also creates an open
‘account receivables from payment card transactions’ item. Because of this, a simple
document with two line items (customer/revenue) now becomes four line items
(customer/customer/payment card receivable/revenue). If you do not select the
check-box, then, the system replaces the customer line item with a receivable from
payment card transactions in the corresponding SAP G/L account.
Even though you would require more database space when you set the ‘Retain
Cut. Item’ indicator, as the system creates additional line items, the advantage is that
you will be able to display receivables on the debit side, besides the ability to deal
with any settlement problems easily.
ii.
iii.
iv.
Enter an appropriate ‘Document Type’ for the settlement document and also for
handling resetting clearing when the settlement is unsuccessful. Also, enter an
appropriate ‘Reversal Reason’ (for example, B4-payment card settlement failed)
under ‘Settings for resetting clearing when settlement unsuccessful’. The system
defaults to this ‘Document Type’ (entered her in ‘Settings for the settlement
document’) on the initial screen of the settlement program RFCCSSTT in the ‘Journal
Entry Type’ field under ‘Data for Clearing Entry’ block (Transaction FCC1); you can, of
course, over-write the same.
You may enter a ‘Text ID and ‘MAIL Text’ for using the standard texts as settlement
responses. If you do no enter a text module here, in the ‘MAIL Text’ field, then, this
message is only for statistical purposes.
Set the ‘Define Index’ indicator to enable the system to enter the number of the
settlement run in the (already cleared) customer line item. Then, it becomes possible
for you to display all customer line items of a specific settlement run, for more than
one account, when carrying out the evaluations.
The next step is to assign a G/L account to cash clearing account.
9.2 Assign G/L Account to Cash Clearing Account
Assign the G/L account that the system will use to record the open items, per card type, to a
cash clearing account. That is, you will use this G/L account to record all the receivables that
you report to the credit card company using a settlement program; the settlement program,
then, posts these reported open items against the cash clearing account and clears them.
240
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 9.2 G/L Account Assignment to Clearing Account (Payment Cards)
Follow the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Payments with Payment
Cards > Assign G/L Account to Cash Clearing Account or use Transaction OBZI to maintain the
required G/L account(s).
On the resulting screen, click on ‘New Entries’ and maintain the chart of accounts, G/L account
for ‘Receivable’ and ‘Clearing’. You may also maintain the necessary settings for
‘Authorization control functions’ and ‘Settlement control functions’. ‘Save’ the details (Figure
9.2).
This completes our discussion on payment cards.
9.3 Conclusion
You learned that you can use ‘Payment Cards’ - credit card, debit card, charge card, deferred
charge card etc - as a form of payment offering to your vendors with an almost-risk-free
payment guarantee, as the payment includes an authorization from the card issuing bank (or
financial organization). You also learned that SAP offers you with a wide range of functions,
both in SD and FI modules, for handling payment with payment cards in different of business
processes.
Payments with Payment Cards
241
You learned about configuring the system, on the FI side, for payments with payment cards.
In that, you learned that you can decide whether to retain or not the customer line items in
the accounting document when transferring data from SD component to FI. You understood
that the advantage of retaining the customer line items in the accounting document (when
transferring data from SD component), is that you can re-create the receivables against a
customer automatically, without the need for creating them again, by a new posting. You
understood that you can, then, process these customer items in the dunning / payment
program.
Let us move on to discuss dunning, in the next Chapter.
10 Dunning
T
he word ‘Dun’ means that you make a (persistent) demand for a payment of an
outstanding debt. ‘Dunning’, in SAP, is the process of reminding your business partners
(who are falling behind the payments) to pay the outstanding payment. It is, essentially,
sending a notice of reminder (‘dunning notice’). Using the dunning program, you can
automatically dun your business partners. The program selects the overdue open items of an
account, ascertains the ‘dunning level’ of the account and creates a dunning notice using the
pre-defined dunning notice format and text, and finally saves the dunning data so determined
for the line items / account which will be looked upon during the next dunning.
Normally, you use the program to dun your customers; but, you can also dun your vendors, if
the vendor has a debit balance (arising from a credit memo). You can enable the program to
offset between credit and debit balances and raise the dunning notice for the balance, when
your customer is also a vendor. You can use the program do dun all the customers / vendors
or only a select few. Again, you can dun the customers across several company codes (‘crosscompany code dunning’), in a single dunning run. If you have your business partners with head
office / branch organization structure, you can configure the dunning program to dun, for
example, the head office but send dunning notice to the branch office(s). The dunning
program uses the currency (local or foreign) in which you have posted all the open items in
an account. If the open items of an account are not posted in the same currency, then, the
dunning program uses the local currency of the company code; it displays the items in
document currency in the dunning notice, but shows the totals in local and foreign currency.
It is possible that you can dun a ‘one-time’ account as well, like any other account. While
dunning the one-time accounts, the system groups all the items of a one-time account having
the same address into a single dunning notice. Even though the program enters the dunning
date and dunning level in both the account master record and in the line item of the one-time
account, the system determines the dunning interval solely by what is entered in the line item
notwithstanding the entry in the master record.
You can use the dunning history to understand all of the dunning runs that you have executed
and the dunning notices that you have sent. You can view the details by account type,
company code, and/or customer or vendor.
You can use the following attributes to control the dunning process in the system:
244
•
•
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Dunning Procedure: You use the dunning procedure to control how the system carries
out dunning. You can define more than one dunning procedure. You may connect the
dunning procedure to a customer / vendor master or to a dunning area. The control
parameters of a dunning program include dunning frequency, dunning levels,
minimum dunning amounts (overdue threshold), dunning charges, dunning text etc.
Dunning Level: The system calculates the dunning level based on the number of days
an open item is in arrears. Alternatively, you can have the system to calculate the
dunning levels based on the dunning amount or percentage paid. It is possible that
you can determine more than one dunning level per dunning procedure.
Dunning Area: A ‘dunning area’ is an organizational unit (for example, a division or
sales organization etc) within a company code that you can use, as the responsibility
area, for dunning. Once defined, you may assign a dunning area to an open item. With
dunning areas defined, you can dun open items separately per dunning area.
However, it is optional to define a dunning area.
The dunning process is made up of several sub-processes like (1) creating the dunning
proposal, (2) editing the dunning proposal and (3) printing the dunning notices, which you
need to need to carry out the in the proper order:
1) Creating Dunning Proposal: When you start the dunning program, you will enter the
parameters for the dunning run: the dunning date, the date up to which the program
should select the posted documents, the company code(s) and also the optional
account restrictions to select the required account(s). Now, during the dunning run,
the dunning program determines the (a) accounts and items that must be dunned,
(b) dunning level, and (c) other details required for dunning. With these details, the
dunning program creates a dunning proposal (list).
You can create the dunning proposal list as often as you require. The system
does not update the dunning data for the item / account until the dunning notices
are actually printed.
2) Editing Dunning Proposal: While editing a dunning proposal, you essentially carry out
activities like setting / resetting the dunning blocks, and changing the dunning levels.
You can manually increase or decrease the dunning level of an item or account in the
proposal. You can block an item / account from dunning. Similarly, you can unblock
an item / account so that it will be included in the dunning proposal. As all the changes
are logged, you can look at the log and confirm that the changes are taken into
account before accepting the proposal. If not, you can go ahead and still edit. It is also
possible that you can view the sample print out of the dunning notices, on the screen,
to see and understand how the notices will look like when actually printed.
Dunning
245
While editing a dunning proposal, though you can lower the dunning level by
any number of levels (for example, from level 4 to 2 or 1), you can only raise by one
level, at a time, to its next higher level (for example, you can raise the level from 2 to
3 but not from 2 to 4). You will, normally, undertake lowering / raising the dunning
level only when you unblock an item / account in the dunning proposal.
3) Printing Dunning Notices: Once you complete the editing of dunning proposal, and
execute the program, (a) the print program prints the dunning notices and (b) the
dunning program stores the relevant dunning data (like dunning level, dunning date
etc) in the line items and in the master record of the customer / vendor. While
printing the dunning notices, the system uses the pre-defined dunning formats
together with the appropriate dunning texts, for that dunning level of that dunning
procedure. You will be able to restart printing, if there is an interruption.
With this understanding of dunning in SAP, let us move on to configure the required settings
of BESTM. SAP has grouped these settings into three categories:
1. Basic Settings for Dunning
2. Dunning Procedure
3. Printout
Let us start with the basic settings for dunning.
10.1 Basic Settings for Dunning
The basic settings are the global settings for dunning in the system. They include:
•
•
•
•
Define Dunning Areas
Define Dunning Keys
Define Dunning Block Reasons
Define Dunning Forms
Let us discuss the dunning areas, first.
10.1.1 Define Dunning Areas
As already pointed out, defining a ‘dunning area’ is optional. You will use dunning areas if
there are different organizational units (distribution channel or business area or sales
organization, for example) that are responsible for carrying out dunning within the company
code. If you want to use dunning area, then, you can use the same or different dunning
procedures for these areas.
246
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
When you want the system to make use of dunning areas for dunning, then, you need
to maintain the dunning area (‘Area’) with the dunning procedure (‘Procedure’) in the master
record of the business partner by clicking on ‘Dunning Areas’ button (Figure 10.1). Else, the
system will use the standard dunning procedure (‘Dunning Procedure’) but, you can enter the
dunning area in the line item; the system will update that, automatically,in the master record.
Note that the ‘Dunning Areas’ button will be visible only when you have defined one or more
dunning area; this enables you to enter the dunning area-specific dunning procedure.
Figure 10.1 Mantaining Dunning Area in a Customer Master Record
Project Dolphin
BESTM does not want to dun its business partners through dunning areas. Instead, all the
dunning will be carried out at the company code level for all the customers / vendors.
Though we will not be defining dunning areas for BESTM, you may still want to know how to
define them. To define a dunning area, use the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Dunning > Basic Settings for Dunning > Define Dunning Areas. You may also
use Transaction OB61. On the resulting screen, click on ‘New Entries’ and define the required
dunning areas per company code on the next screen.
Let us move on to define the dunning keys
Dunning
247
10.1.2 Define Dunning Keys
The ‘dunning keys’, which are company code independent, enable you to limit the dunning
level for an item. While configuring a dunning key, you can, also, decide if some of the items
with a specific dunning key are to be displayed separately in the dunning notice.
Consider an example that you have an incoming payment and when posting you made
a residual item to carryforward, as the payment resulted in a payment difference. Now, as
you want to display this residual item in a separate section in the dunning notice, you can
accomplish this by defining a separate dunning key. You can also print the text for the dunning
key in the dunning notice.
Project Dolphin
BESTM wants to have five dunning keys defined. The first three keys should be used to initiate
the respective dunning levels, 1, 2 and 3. The 4th dunning key will be for denoting the
payments made with a separate line item display. The 5th key will be used for denoting
residual items arising out of payment differences and will also be displayed separately.
To configure the dunning keys:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning > Basic
Settings for Dunning > Define Dunning Keys, or Transaction OB17.
On the resulting screen (Figure 10.2), click on ‘New Entries’ and define the required
dunning keys (‘Dunn.Key’) and provide a description in ‘Text’ field.
Select ‘Print sep’ check-box to display the items separately on the dunning notice.
Per dunning key, you also need to enter the maximum dunning level (‘Max. Level’)
that will be triggered for that key.
Figure 10.2 Defining Dunning Key
With this, we can now move on to discuss the last step in dunning basic settings: defining the
dunning block reasons.
248
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
10.1.3 Define Dunning Block Reasons
The ‘dunning blocks’ or ‘dunning block reasons’ help you to prevent an account or an item
from being dunned. You will define a dunning block reason using a blocking key and will enter
the same in the ‘Dunning block’ field of customer / vendor master record (Figure 10.3) or in
the line item. During a dunning run, the system checks for this dunning block key in the master
record or line item, and excludes the blocked accounts and/or items in the dunning run
proposal. You can see the details blocked accounts / items, printed in an exception list, with
the reason for the block.
Figure 10.3 Entering Dunning Block Reason in Customer Master Record
Project Dolphin
The Dolphin project team has suggested to configure six dunning block reasons in the system:
disputed (A), promised to pay (B), clarification required from SD side (C), blocked by legal
department (D), other reasons (E) and blocked by invoice verification (R).
To configure the dunning block reasons:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning > Basic
Settings for Dunning > Define Block Reasons, or Transaction OB18.
On the resulting screen, click on ‘New Entries’ and define the required 1-character
block keys (‘Block’) and provide a description in ‘Text’ field (Figure 10.4). The blank in
Dunning
249
the ‘Block’ field will indicate that the item/account is not blocked and is free for
dunning.
Figure 10.4 Defining Dunning Block Reasons
With this, let us look at defining the dunning forms which you will be using to configure the
dunning procedure.
10.1.4 Define Dunning Forms
SAP provides you with the option of using either ‘SAP Smart Forms’ or ‘SAPScript’ forms for
use as the dunning forms. The standard dunning forms cater to different situations like forms
that have the provision for including the dunning interest or plain forms which you will
normally use for 1st level of dunning (or ‘payment reminders’). Depending upon whether you
want to have different layout or want to include interest etc., you will select the appropriate
form for a given level of dunning. You may need more than one form, and it is recommended
to copy the standard forms in SAP to create your own.
Project Dolphin
The project team has suggested to copy and adapt the SAPScript forms provided by SAP to
meet the business needs of BESTM group of company codes. Accordingly, there will be five
forms that will be created anew by copying the standard ones: the form F150_BE_DUNN_01
(without interest) will be copied as ZF150_BE_DUNN_01 and will be used both for the singlelevel dunning procedure and also for the first dunning level of the 5-level dunning procedure.
The standard form F150_BE_DUNN_02 (with interest) will be copied to create the other four
levels for the 5-level procedure. Also, separate spool lists will be created by copying the
standard LIST1S spool list, and five new spool lists will be created prefixed with the company
code name like 1110-1, 1110-2 etc.
250
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
To copy and create new dunning forms for BESTM:
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning >
Printout > Define Dunning Forms (with SAPScript), or Transaction SE71.
Figure 10.5 Defining a New Dunning Form (SAPScript) by Copying the Standard Form
ii.
iii.
iv.
v.
On the resulting screen, enter the form that you want to copy (say,
F150_BE_DUNN_01), and click on ‘Change’.
On the next screen (Figure 10.5), click on ‘Form > Save As’ and input the name of the
new form (say, ZF150_BE_DUNN_01).
Click ‘Activate’. You have now created the new form ZF150_BE_DUNN_01. This is the
form for dunning notice without interest.
You can, now, copy the other form F150_BE_DUNN_02 (with interest), to create the
new forms ZF150_BE_DUNN_02, ZF150_BE_DUNN_03, ZF150_BE_DUNN_04 and
ZF150_BE_DUNN_05.
This completes our discussion of configuring the basic settings required for dunning. We shall,
now, move on to discuss the settings relating to dunning procedure.
Dunning
251
10.2 Dunning Procedure
The ‘dunning procedure’ controls how the dunning program duns the business partners. It
contains specifications like dunning frequency / dunning interval with which the program
duns the open items, specifications relating to grace days and minimum number of days which
will be required to determine the open items to be dunned, details of the number of dunning
levels with the level determining the wording of the dunning notice and the specifications as
to whether to dun standard and/or Special G/L transactions.
You need to complete the following settings to complete configuring the dunning procedures
in the system:
•
•
•
Define Dunning Procedures
Define Dunning Groupings
Define Interest Rates
Let us start with the definition of dunning procedures.
10.2.1 Define Dunning Procedures
As already outlined, you control the dunning program via the specifications maintained in the
dunning procedure. It is possible that you may need more than one dunning procedure to
take care of your dunning needs. For example, you may have business partners who need to
be reminded only once and in such a situation you will need a dunning procedure with only
one dunning level; on the other hand, you may have some customers who need to be followed
up several times to get back your receivables, and in such a case you may need a multi-level
dunning procedure with the wording in the dunning notice progressively changing to stricter
and legal tone with every increase in the dunning level. The dunning procedures are company
code independent.
Project Dolphin
The BESTM management has decided to have two dunning procedures in each of the
countries where the company is operating. Accordingly, they have asked the project team to
configure the following, both for India and USA:
1. A dunning procedure that will be used to remind the VIP business partners, which will be
single level dunning procedure. This will just be a ‘payment reminder’ and there will not be
any charges / interest associated with this dunning.
2. Another dunning procedure – multi-level dunning procedure – that will be used for all other
business partners. This will have a maximum of five dunning levels, with a dunning interval of
seven days. There needs to be a cushion of three days for dunning levels 2 and 3 and five days
for levels 4 and 5. Also, there will be a grace period of five days at the account level. Further,
252
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
if the due date falls on a holiday, the dunning program should take the next working day as
the payment due date based on respective country’s public calendar. The dunning charges,
for the multi-level dunning procedure, will as set out in the Table 10.1.
Amount
Range
Up to $5,000
$5,001 – $10,000
$10,001 - $25,000
$25,001 - $50,000
$50,001 - $100,000
Above $100,000
Dunning
Level 1
Dunning
Level 2
Dunning
Charges
Dunning
Charges
0
0
0
0
0
0
$5
$10
$10
$15
$20
$50
Dunning Dunning Dunning
Level 3
Level 4
Level 5
Dunning Dunning Dunning
Charges Charges Charges
(%)
(%)
(%)
0.10
0.15
0.20
0.15
0.20
0.25
0.20
0.25
0.30
0.25
0.30
0.35
0.30
0.35
0.40
0.35
0.40
0.50
Table 10:1 Dunning Charges for Multi-level Dunning Procedure of BESTM
Besides the dunning charges, there will be an overdue interest charges, to be charged on the
arrears, at the prevailing rates subject to a minimum of $50 for level 2, $100 for level 3, $250
for level 4 and $500 for level 5. Of course, there will be no interest on arrears for the level 1.
The level 5 will be considered as legal dunning level and will use legal wording in the dunning
notice; a separate legal dunning notice format will have to be used. BESTM wants the system
to consider the interest indicator in the master record of a business partner and not through
the dunning procedure.
When printing the dunning notice, the program should display the entire account balance and
should include all the open items even if the dunning level is at the lowest. BESTM does not
want to include any of the Special G/L items in the dunning list.
Each company code will dun their business partners separately. However, they can group the
overdues of a customer across other company codes.
The charges and interest amount will be the same for India-based company codes as well,
except that the amounts will be in INR.
To define the required dunning procedures for BESTM:
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning > Dunning
Procedure > Define Dunning Procedures, or Transaction FBMP. On the resulting screen, click
on ‘New Procedure’ and, on the next screen (Figure 10.6):
Dunning
253
Figure 10.6 New Dunning Proceudre – Overview
i.
ii.
Enter the identifier for the new dunning procedure in ‘Dunn.Procedure’, and provide
a description in the ‘Name’ field.
Under ‘General Data’:
• Enter the ‘Dunning Interval in Days’. During every dunning run, the system
will check to see if the run date is at least this number of days since the last
dunning run. If not, then, the program will not select the account/ items for
dunning, even if they are overdue. For BESTM, the interval will be 7.
• Enter the highest dunning level that you want for this dunning procedure in
the ‘Number of Dunning Levels’ field. For BESTM, this will be 5.
You cannot have more than nine dunning levels in a dunning procedure.
•
•
You will enter the dunning level from which you want the program to total all
the items, in ‘Total due items from dunning level’ field. Not required in most
of the countries.
Enter the grace period, in days, at the account level in ‘Min.Days in Arrears
(Acct)’ field. This denotes the number of days that should be crossed, at least
254
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
by one item in an account, so as to create a dunning notice. This grace period
does not influence the way the system calculates the overdue.
For example, consider that you have entered 5 in ‘Min.Days in Arrears
(Acct)’ field. Now, suppose that there is an open item in the account 1235545
that is due on 20-Mar-2020. When you run the dunning on 24-Mar-2020, the
program will not select this account for dunning because as the line the item
has not crossed the minimum days of 5 in arrears (that is, the grace period)
after becoming due. But, if you run the dunning program on 26-Mar-2020,
then, the program selects this account for dunning as the item has crossed
the minimum days in arrears of 5 days.
•
•
•
Enter the days in ‘Line Item Grace Periods’, if any. The system will consider
the grace period per line item, entered here, while determining the due date
for the dunning run. So, any item whose days in arrears is less than or equal
to the grace period entered here will be considered as not due yet for that
dunning notice, and hence will not be selected for dunning.
Enter the ‘Interest Indicator’ for item interest calculation. If you do not enter
anything here, then, the entry maintained in the master record is taken into
account. Even if you enter an indicator here, the entry in the master record
has the highest priority. As BESTM wants to control the interest through the
entry in master record, we are not maintaining a value here.
Select ‘Ignore Interest Indi. in Master Record’ check-box if you want the
system to take into account the entry in the ‘Interest Indicator’ field
notwithstanding what has been maintained in the master record.
The system ignores the interest indicator entered in the master record
if you have selected the ‘Ignore Interest Indi. in Master Record’ check-box
and have maintained a value in the ‘Interest Indicator’ field; it uses the
interest indicator in the dunning procedure to calculate the dunning interest.
However, if you have not maintained an interest indicator either in the
master record or in dunning procedure but you have selected the ‘Ignore
Interest Indi. in Master Record’ check-box, then, this setting does not have
any impact and the program will not calculate the dunning interest.
•
Enter the country-specific public calendar ID in the ‘Public hol.cal.ID’ field to
enable the system to make use of the relevant calendar to arrive at the due
date that will be printed on the dunning notice, when the due date falls on a
public holiday.
Dunning
•
•
•
255
Select ‘Standard Transaction Dunning’ to ensure that the dunning program
selects only the standard G/L transactions for dunning.
Select ‘Dun Special G/L Transactions’, if you want the system to include the
Special G/L items as well along with the standard items for dunning.
When you do not select ‘Dunning Even for Credit Account Balance’ check-box,
the dunning program selects only the debit balance items for dunning.
If you set ‘Dunning Even for Credit Account Balance’ flag, then, the
system does not check the account balance as to credit or debit. But, it
ensures that the total of the overdue items is in debit to create a dunning
notice; else, it does not create the dunning notice.
iii.
iv.
v.
Under ‘Reference data’, enter the dunning procedure which is used as the reference
to determine the forms for dunning notices in the ‘Ref. Dunning Procedure for Texts’
field. When left blank, the system fills this field, automatically, with the selected
dunning procedure. You can simplify the maintenance of the form names for various
dunning procedures which have the same number of dunning levels and the same
form layout, by referencing to a particular procedure.
‘Save’ the details and proceed to configure the other settings.
Click on ‘Dunning Levels’ button to maintain dunning level settings (Figure 10.7):
Figure 10.7 New Dunning Proceudre – Dunning Level
256
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
•
vi.
Enter the ‘Days in Arrears’ for each dunning level. You will notice that based
in the configuration in the previous step, the system has already filled up this
field for each dunning level. If you have entered any ‘Line Item Grace Periods’
previously, then, the system adds this to each level to arrive at the days in
arrears.
• Select ‘Calculate Interest?’ check-box for all the dunning levels for which you
want the program to calculate the dunning interest. For BESTM, we have
selected the check-box for all the levels except dunning level 1.
Under ‘Print parameters’:
• Select ‘Always Dun?’ check-box, for the appropriate dunning levels, to
indicate that a dunning notice needs to be printed, even if no change has
been made to the dunning proposal since the last dunning run. Select this flag
for the highest dunning level.
You will consider that a dunning proposal has changed if at least one of
the items has reached another dunning level or a new item has been included
or there is a change in the dunning level of the account in question.
•
Select ‘Print All Items’ check-box, to determine if you want the dunning
program to print all open items in the dunning notices that have the particular
dunning level. You will, normally, enable this for higher dunning levels so as
to give the customer/vendor an idea of the overall account balance.
Even if you select ‘Print All Items’ check-box, note that the blocked items
(for dunning) or items for which you have allowed automatic debit, are not
displayed. Also, this indicator does not have any effect, if you have opted for
separate dunning notices per dunning level for your company code(s).
•
vii.
In ‘Payment Deadline’ field, enter the number of days that will be added to
the dunning run date to arrive at the payment deadline date, per dunning
level. The system also takes into account the public calendar for the country,
if you have maintained that in the earlier configuration step, when arriving at
the payment deadline so that it does not fall on an official holiday.
Under ‘Legal dunning procedure’, select ‘Always Dun in Legal Dunning Proc.’, if you
want to send a dunning notice irrespective of the fact that there have not been any
further account movements since the last dunning.
Dunning
257
The system usually sends a further dunning notice only when there is some
account movement since the last dunning and when you have entered legal dunning
procedure in the customer/vendor master record.
Figure 10.8 New Dunning Proceudre – Dunning Charges
viii.
ix.
Now, click on ‘Charges’ and enter the ‘Currency’ on the resulting pop-up screen. Press
‘Continue’ and maintain the required dunning charges either as amount
(‘Dunn.charge’) or percentage (‘Dunn.chrge %’) on the next screen (Figure 10.8) per
dunning level and for each amount range (‘From Dunn. Amt.’). Use the ‘Page Down’
key to add more rows, if required.
Click on ‘Minimum amounts’, enter the ‘Currency’ on the resulting pop-up screen,
and maintain the required settings on the next screen (Figure 10.9):
• Enter the minimum amount (‘Minimum amnt’) of the overdue items which is
necessary for the dunning program to set a dunning level. If this minimum
amount is not reached in a dunning level, then, the program assigns these
items in this dunning level to the next lowest level, besides checking whether
a dunning notice can then be created in this dunning level. When you have
entered both ‘Minimum amnt’ and ‘Min.Percent.’, then, the program would
look at the minimum percentage but subject to the minimum amount
specified for that dunning level.
• Select ‘NoRed.’ Check-box if you do not want the system to reduce the
dunning level of items for which the ‘Minimum amnt’ or ‘Min.Percent.’ is not
258
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
reached. In such a case, these items will not be included in the dunning
proposal and will not be dunned.
Figure 10.9 New Dunning Proceudre – Minimum Amounts
•
x.
Enter the absolute minimum of dunning interest that needs to be charged for
a dunning level in the ‘Min.Amt for Interest’ field.
Now, click on ‘Dunning Texts’ button. On the resulting pop-up screen, enter the
‘Company Code’ and select the ‘Account type’ (say, Customer) and proceed. On the
next screen (Figure 10.10):
Figure 10.10 New Dunning Proceudre – Dunning Texts
Dunning
•
259
Under the ‘Normal dunning procedure’ block, enter the dunning level (‘Dun’),
and maintain the dunning form name (‘Form’) and the list name (‘List Name’)
for all the dunning levels. We have adapted the default dunning forms for
BESTM and renamed them starting with Z (refer Section 10.1.4). The form for
1st dunning level is without interest, but for other levels the form is with
interest.
In the ‘List Name’, you enter the name for the spool list for printing the
dunning notices. As you can store the dunning notices for different company
codes or different dunning levels in the spool as separate lists, it makes sense
to specify a different name. Of course, if you do not specify anything here,
then, the system uses the standard spool list ‘LIST1S’.
•
•
•
xi.
Select ‘Adv.’ check-box to generate payment advice for that dunning level.
You may also enter the ‘Form ID’ for the accompanying media.
Repeat the settings for ‘Account type’ = Vendor (K) for the selected company
code, and do similar settings for all other company codes.
Go back to the initial screen, and go to the menu ‘Environment > Company Code
Data’. Click on ‘New Entries’ and maintain the details as depicted in Figure 10.11.
Figure 10.11 New Dunning Proceudre – Company Code Dunning Control
•
•
•
Enter the company code (‘CoCd’) for which you are maintaining the settings,
select the appropriate check boxes (‘By Dun.Ar.’ or ‘By Dun.Lev’) and enter
the reference company code (‘Ref.CoCode’) if any. The reference company
code is the one that will provide the required dunning forms.
Enter the sorting variant: K1 for MHNK and P1 for MHND. You will not be able
to use these sort variants K1 and P1, when you plan to dun by dunning level.
Also enter the dunning company code (‘Dun CoCd’) if the company code
entered in column 1 is not responsible for dunning (useful in cross-company
code dunning).
260
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
While printing the dunning notice, the system updates the dunning level
in the customer master record. If you are dunning by dunning level (‘By Dun.
Lev’ check-box selected), and sort the print in descending order (using the
sort variants K1 and/or P1), this may lead to an incorrect dunning level being
entered in the customer master record.
xii.
‘Save’ the details. This completes defining the multi-level dunning procedure for
BESTM. Repeat the settings and define the single level dunning procedure as well for
BESTM.
With this, let us understand how to use the dunning groups for dunning.
10.2.2 Define Dunning Groups
By default, the dunning program groups the dunning notices per customer / vendor. However,
you can plan to group the open items of your business partners according to certain predefined criteria and dun those items together. For example, you may want to send your
business partner a separate dunning notice per leased property; for this, you can define a
grouping key referring to the contract number field and dunning all the open items, with the
same contract number, together.
We will not be using this configuration for BESTM. However, it may help to understand that
you can configure this by using the menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions >
Dunning > Dunning Procedure > Define Dunning Groups, or Transaction OBAQ.
With this we are now ready to configure the last configuration setting, under dunning
procedure.
10.2.3 Define Interest Rates
While you have discussed entering an interest indicator when configuring the dunning
procedure (Section 10.2.1), you can use this configuration step to define interest rate % (debit
/ credit), valid from and the currency, per interest indicator. Even though we have not entered
an interest indictor in the dunning procedure for BESTM mentioning that the interest
calculation will be controlled through the master record, you can use this step to maintain the
rates for the interest indicator which you will enter in the master record of customer or
vendor.
You would have already defined the required arrears (or item) interest indicators while
configuring ‘Interest Calculation Global Settings’ as a part of ‘Bank Account Interest
Calculation’ configuration activity. If not you can configure the same as detailed below:
Dunning
261
10.2.3.1 Define Interest Calculation Types
Using this configuration activity, you can create your interest indicators with the specification
that they are to be used for account balance interest calculation. You will, then, enter this
indicator in the G/L account master record of the relevant G/L accounts, enabling the system
to select these accounts automatically during interest calculation.
Project Dolphin
BESTM has decided to use two different interest indicators, apart from the standard ones
available in SAP. The new interest indicators will be used for calculating the account balance
interest on staff loan accounts, one indicator for US-based company codes and the other for
India-based company codes.
To define new interest indicators:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Business Transactions > Bank Account Interest
Calculation > Interest Calculation Global Settings > Define Interest Calculation Types.
You may also use Transaction OB46.
On the ‘Change View “Interest Settlement (Calculation Type)”: Overview’ screen,
select the row containing the standard balance calculation interest indicator (02) and
click on ‘Copy As’.
On the next screen:
• Enter the identifier for the new interest indicator (say, 2U), and enter a
suitable ‘Name’. This will be used by US-based company codes of BESTM. The
standard interest indicators supplied by SAP are denoted as 01 (item interest
calculation) and 02 (balance interest calculation) by SAP.
• The account number as interest calculation indicator (‘Acct. no. as IntClcInd’)
check-box, determines whether the account number is to be used as an
extended interest indicator in the interest terms. You can set only the numeric
G/L account numbers as the extended interest indicator; if so, you need to
maintain the length of the G/L account number at 10 digits by padding the
account number with zeros from the left. As we will not use this, we will not
select this check-box.
• Select the appropriate interest calculation type (‘Int Calc. Type’) from the
drop-down list; select ‘S’ for balance interest calculation (‘P’ will be for item
or arrears interest calculation).
‘Save’ the settings and create the other balance interest indicator for India (2I).
262
v.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Also create the required item (or arrears) interest indicators for BESTM (1I for India
and IU for USA). You have now defined the required new interest indicators for BESTM
(Figure 10.12).
Figure 10.12 Interest Indictors
Now that we have configure the interest indicators for BESTM, let us proceed to define the
dunning interest rates.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning > Dunning
Procedure > Define Interest Rates, or Transaction OB42. On the resulting screen, click on ‘New
Entries’ and maintain the interest rates for both the indicators, 1U and 1I to be used in US and
India respectively (Figure 10.13).
Figure 10.13 Dunning Interest Rates
With this, we are now ready to discuss the settings that are required for dunning printouts.
10.3 Printout
Under this, we will be discussing the configuration relating to the settings for printing dunning
notices. The dunning notices (forms) can be either in the form of SAPScript or SAP Smart
Forms. The settings include:
•
•
•
•
Define Dunning Forms (with SAPScript)
Define Dunning Forms (with SAP Smart Forms)
Assign Dunning Forms
Define Sender Details for Dunning Forms
Dunning
263
10.3.1 Define Dunning Forms (with SAPScript)
We have already discussed this in Section 10.1.4.
10.3.2 Define Dunning Forms (with SAP Smart Forms)
Since we will be using only the SAPScript-based dunning forms, we will not be discussing in
detail about defining the dunning forms based on SAP Smart Forms.
If you want to define dunning forms which are based on Smart Forms, you may use the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Business Transactions > Dunning > Printout > Define Dunning Forms
(with SAP Smart Forms), or Transaction SMARTFORMS. The standard Smart Form supplied by
SAP is named as F150_DUNN_SF (Figure 10.14). You may copy and adapt the same, to meet
your own requirements.
Figure 10.14 Dunning Form F150_DUNN_SF (Smart Form)
The next step is to assign the dunning forms
10.3.3 Assign Dunning Forms
Here, you need to specify, per ‘dunning procedure-company code–account type’, the forms
that you want to use for the normal and legal dunning procedures. Remember we have
already configured most of these settings while defining the dunning procedure vide Section
10.2.1. Here, you just need to identify the form type: whether it is SAPScript, SAP Smart Form
and so on.
264
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Dunning > Printout >
Assign Dunning Forms. On the resulting screen:
i.
Select the dunning procedure (say, B5US) and double-click on ‘Forms for normal dunning
procedure’ on the left hand side ‘Dialog Structure’. Maintain the company code (say,
1110) and the account type (say, Customer) on the resulting pop-up screen and proceed
to the next screen (Figure 10.15).
Figure 10.15 Assigning Dunning Forms for Normal Dunning Procedure
ii.
iii.
You will notice that the system has already populated the ‘Form Object Name’ and the
‘List Name’ for each of the dunning levels. You just to need to select the form type
(‘FormTyp’) as SAPScript and ‘Save’ the details.
Repeat and select the form type for legal dunning procedure as well (Figure 10.16)
Figure 10.16 Assigning Dunning Forms for Legal Dunning Procedure
Now, we are ready to complete the final step in configuring the dunning printout, and defining
the sender details for dunning forms.
Dunning
265
10.3.4 Define Sender Details for Dunning Forms
Define which standard texts are to be used for the header / footer / sender address, in the
letter window of the dunning notice. Create the standard texts and specify the same for each
of the company codes.
To configure, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Dunning >
Printout > Define Sender Details for Dunning Forms. You may also use Transaction
S_ALR_87001305. On the resulting pop-up screen, enter the ‘Company Code’ and continue.
On the next screen (Figure 10.17), click on ‘New Entries’ and:
Figure 10.17 Configuring Sender Details for Dunning Forms
i.
ii.
iii.
iv.
v.
vi.
Leave the ‘Area’, which is nothing but the dunning area, as blank as we are not
dunning per dunning area for BESTM.
Select the appropriate ‘ID’. ST for standard text.
All the fields without a prefix of SF denotes the fields for SAPScript form: enter the
identifier for ‘Header Text’ (say, company logo, telephone etc), ‘Footer Text’ (say,
details like signatory, salutation of the signatory etc), ‘Signature Text’ and for ‘Sender’
as well. The ‘Sender’ provides the details of the company code that sends the dunning
notices.
You may maintain / display the text using the ‘Display text’ button. Alternatively, you
can use Transaction SO10, to maintain the required texts.
Repeat the steps and configure similar texts for other company codes as well, and
‘Save’ all the details.
If you are using Smart Forms for dunning notices, then, you need to maintain the text
IDs in all the fields that are prefixed with SF.
This completes our discussion on the settings that are required for printing the dunning
notices. Let us proceed to list the dunning program configuration, you have carried out so far,
to verify and modify, if required.
266
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
10.4 Generate List for Dunning Program Configuration
Using this, you can generate the list displaying the dunning program configuration in the
system, per company code, per dunning procedure. The list will come handy to check the
settings and make a change, if required. The system uses the program SAPMSSY0 to bring out
the details.
Figure 10.18 System Generated Configuration List for Dunning Program
Dunning
267
To generate the list, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Dunning >
Generate List for Dunning Program Configuration. You may also use Transaction OBL6.
On the resulting screen, enter the ‘Dunning procedure’ and ‘Company code’ and click on
‘Execute’. The system brings out all the details of the settings that you have maintained for
the dunning procedure (say, B5US) for the entered company code (say, 1110), on the next
screen (Figure 10.18). You will see all the details for basic settings, the configuration details
for the dunning procedure, details of forms used etc. Scan through the list, and, if you see a
setting that is incorrect or a setting that has not been maintained, revisit the appropriate
configuration step to correct or maintain the same.
With this, we have completed all the required settings for configuring the dunning program
in the system. In the next Section, let us understand how the system actually carries out the
dunning process.
10.5 Dunning Process Flow
1) Use the SAP Easy Access menu path: SAP Menu > Accounting > Financial accounting
> Accounts Receivable (or Accounts Payable) > Periodic processing > Dunning or use
Transaction F150, and begin the dunning process by Maintaining the Dunning
Parameters for the dunning run:
a. First enter the basic parameters like the dunning run execution date (‘Run
On’) and an identifier for the dunning run (‘Identification’).
b. Now, on the ‘Parameters’ tab, maintain the ‘Dunning Date’ (that will be
printed in the dunning notice), posting cut-off date for selection of
documents (‘Docmnts Posted up To’), ‘Company code’, and ‘Amount
Restrictions’ (for customer / vendor).
c. You may also make further restrictions in ‘Free Selection’ tab, wherein you
may enter up to eight additional selection criteria for accounts and
documents: you can use document fields (from tables BSID and BSIK),
customer master record fields (from tables KNA1, KNB1 and KNB5) and
vendor master record fields (from tables LFA1, LFB1 and LFB5) as selection
criteria.
d. When completed, ‘Save’ the details. The system will, now, display the current
status of the dunning run in the ‘Status’ tab.
2) Now, on the ‘Dunning’ initial screen, click on ‘Schedule’ to schedule the dunning run
for a later date / time or run the program immediately. If you do not select the
‘Dunn.Print with Scheduling’ check-box, then, the system prints the dunning notices
immediately after the dunning run, and you will not be able to edit the dunning
proposal manually or to delete a dunning proposal which has been created.
268
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
3) During the Creation of Dunning Proposal List, the system determines the accounts
and items to be dunned in two steps:
a. First, the dunning program checks the accounts. The dunning program
checks whether an account needs to be dunned:
i. It checks the fields ‘Dunning Procedure’ and ‘Last Dunning Notice’
(date of last run) in the customer master record to determine
whether the arrears date or the date of the last dunning run is in the
past.
ii. It checks whether the account is blocked for dunning, based on the
entry in the ‘Dunning Block’ field in the customer master record.
Following these two checks, the program determines if an account in
question is released for dunning or rejected.
b. Second, when the account is released for dunning, then, the dunning
program processes all open items that were posted to this account on or
before the date entered in the ‘Docmnts Posted up To’ field maintained in
the dunning parameters:
i. The program checks each open item, in an account, to decide if the
item:
• Is blocked for dunning?
• Is overdue according to the date of issue, the base date, the
payment conditions, and the number of grace days granted.
Following these checks, the open item in question is either released for
dunning or rejected.
c. If the open item is released for dunning, the dunning program, now, arrives
at:
i. How many days the open item is overdue?
ii. Which dunning level the open item has according to the dunning
levels specified in the dunning procedure?
From the above, the program determines the open items with specific
dunning levels for an account, and sets the highest dunning level to the
account, based on the highest dunning level of an open item of the account,
even though there are several items with different dunning levels.
d. Once the dunning program has ascertained which open items to dun and the
dunning level for the account, it processes each account by making the
following checks:
Dunning
269
i. Does the customer (or vendor) have a debit balance with regard to
overdue items and all open items?
• If NOT, the account is not dunned.
ii. If YES, is the total amount to be dunned and the percentage of all
open items more than the minimum amount and percentage defined
in the dunning procedure?
• If NOT, the account is not dunned.
iii. If YES, is the dunning level for the account or the overdue items
higher than it was for the last dunning run?
• If NOT, the account is not dunned.
iv. If YES, are there any new open items to be dunned (with a previous
dunning level = 0)?
• If NOT, the account is not dunned.
v. If YES, does the dunning procedure for this level specify that dunning
be repeated?
• If NOT, the account is not dunned.
vi. If YES, the account is released for dunning, and the program goes on
to check the next account as described above.
e. Now, the program creates a list (dunning proposal list) of all the accounts and
open items that have been proposed for dunning and assigns a dunning level
to the account according to the highest dunning level of an open item in the
account.
4) You can, now, Edit the Dunning Proposal List to manually raise or lower the dunning
level of an item or account. You can also block or unblock an item, account, or
document from being dunned. You can look at the log to confirm the changes you
have made to the dunning proposal; if you are not satisfied or want to make further
changes, you can edit further till you incorporate all the changes. You can also display
the sample printout of the dunning notice on the screen; you will be able to display
only the first 10 dunning notices.
5) Now, you are ready to Print the Dunning Notices. The program selects the dunning
form / text based upon the dunning levels. After you activate the print run, the
program prints the dunning notices besides updating the important details, such as
‘Dunning Level’ and ‘Last Dunning Notice’, in the customer (or vendor) master. You
can, always, restart an interrupted printing. You can optically archive the dunning
notices while they are getting printed.
This completes our discussion on dunning process flow. And, this also completes our
discussion on dunning.
270
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
10.6 Conclusion
You learned dunning in detail, in this Chapter.
You saw how to define the basic settings, including dunning areas, dunning keys, dunning
block reasons and dunning forms. You learned that though defining a ‘dunning area’ is
optional, you can use dunning areas if there are different organizational units (distribution
channel or business area or sales organization, for example) that are responsible for carrying
out dunning within the company code. You learned that the ‘dunning keys’, which are
company code independent, enable you to limit the dunning level for an item. While
configuring a dunning key, you understood that you can, also, decide if some of the items with
a specific dunning key are to be displayed separately in the dunning notice. You learned that
the ‘dunning blocks’ (or ‘dunning block reasons’) help you to prevent an account or an item
from being dunned. You understood that you will define a dunning block reason using a
blocking key and enter that in the customer / vendor master record or in the line item.
You learned that the ‘dunning procedure’ controls how the dunning program duns the
business partners. You learned that it contains specifications like dunning frequency / dunning
interval with which the program duns the open items, specifications relating to grace days
and minimum number of days which will be required to determine the open items to be
dunned, details of the number of dunning levels with the level determining the wording of
the dunning notice, and the specifications as to whether to dun standard and/or Special G/L
transactions. You learned that you may need more than one dunning procedure to take care
of your dunning needs. You learned that though by default, the dunning program groups the
dunning notices per customer / vendor, you can ‘group’ the open items of your business
partners, according to certain pre-defined criteria and dun those items together.
You, then, learned about the configuration relating to the settings for printing dunning
notices. You learned that SAP provides you with the option of using either ‘SAP Smart Forms’
or ‘SAPScript’ forms for use as the dunning forms, and that the dunning forms cater to
different situations: like forms that have the provision for including the dunning interest or
plain forms which you will normally use for 1st level of dunning (or ‘payment reminders’). You
understood that depending upon whether you want to have different layout or want to
include interest etc., you will select the appropriate form for a given level of dunning. You also
learned how to assign the dunning forms per ‘dunning procedure-company code–account
type’ combination, and defining the sender details for the forms.
You went on to learn how you can generate the list displaying the dunning program
configuration in the system, per company code, per dunning procedure. You learned that this
list will come handy to quickly check the settings and make a change, if required.
Dunning
271
Finally, towards the end of the Chapter, you learned about the dunning process flow: entering
the dunning parameters, creating the dunning proposal, editing the dunning proposal, and
finally printing the dunning notices.
We can, now, move on to discuss the configuration settings required for open item clearing,
in the next Chapter.
11 Open Item Clearing
A
n ‘open item’ is an uncleared transaction (say, an unpaid invoice from a vendor) that
can be cleared and closed, only when you post (say, a payment towards settling the
vendor invoice) an offsetting amount to that account: when the offsetting amount is
equal to the open item, then it is cleared in full; else, it is cleared partially as there is still a
residual amount that is ‘open’. In cases of partial clearing, the system stores the open residual
amount for the item and the cleared amount. For the open item, you can enter a due date for
net payment, due date for cash discount, or deferral date; when you enter a deferral date,
the system does not process (by dunning or payment program) that open item until that date
is passed. When clearing, the system enters a clearing document number and the clearing
date in the open items.
You can process several accounts of different account types (G/L, vendor, and customer),
including accounts from different company codes in a single clearing. The account balance is
always the total of the open items, as the sum of the items involved in any clearing transaction
is zero. The customer / vendor accounts are always managed on open item basis, allowing
you to monitor the outstanding A/R and A/P, respectively, at any point of time. However, you
need to define open item management for G/L accounts in their respective master records,
and you will normally set this option, for example, for bank sub-accounts and clearing
accounts so as to track whether the business transactions posted to these accounts are closed
yet or not.
You will be able to move a document to the ‘cold area’ of the database only if all the
open items have been cleared. This ensures that all the (open) items that are yet to be cleared
are always available in the system.
You can clear the open items either in the local currency (of the open item) or using a foreign
currency. When cleared in a foreign currency, the system translates the transaction using the
average rate between the two currencies: first translates the document currency into the
local currency, and then translates the local currency using the clearing currency. During such
a translation, if the system encounters any difference (loss or gain) due to currency
conversion, then, the system posts those differences (beyond the tolerance limits) to the predefined G/L accounts.
274
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 11.1 Payment Difference Processing during Clearing
You will also encounter payment differences arising out of clearing transaction due to, for
example, a customer’s underpayment / overpayment, or the customer has made an
unauthorized deduction for cash discount. If the difference is immaterial, you usually clear
the receivable and post the difference. You can configure the system as how to handle the
payment differences (Figure 11.1). The options are:
•
•
If the payment differences are well within the tolerance limits, the system
automatically adjusts the cash discount or posts the difference to a separate gain or
loss G/L account.
If the payment difference exceeds the tolerance limits, you can, then, process the
payment as a partial payment or enter a residual item for the difference:
o When you enter a partial payment, the system does not clear the original
receivable, but posts the payment with an invoice reference.
o When you create a residual item, the system clears the original receivable
and posts the outstanding difference as residual item to the customer
account.
You can only clear open items that are posted to accounts which are managed on an openitem basis. You should define while configuring the system, beforehand, as to which accounts
can be cleared automatically. You will not be able to clear certain open items if they trigger
another posting in the system, for example, exchange rate difference. You cannot also clear
Open Item Clearing
275
Special G/L transactions using SAP G/L Accounting clearing programs; you need to use the
special functions for that purpose.
You can clear open item either manually or automatically using the clearing program. You
can use the functions specified in Table 11.1:
Posting
transaction
Business transaction
details
Incoming
payment
Credit memo for a check
deposited at the bank
Outgoing
payment
Debit memo for an
issued check
Post with
clearing
Clearing the GR/IR
clearing account
Outgoing
payment
Debit memo for an
issued check
You need to use (SAP Easy Access):
SAP Menu > Financial Accounting > General
Ledger > Document Entry > Incoming
Payments
SAP Menu > Financial Accounting > General
Ledger > Document Entry > Outgoing
Payments
SAP Menu > Financial Accounting > General
Ledger > Document Entry > Post with
clearing
SAP Menu > Financial Accounting > General
Ledger > Document Entry > Outgoing
Payments
Table 11:1 Functions for Open Item Clearing
You will use manual clearing (a) for bank subaccounts and clearing accounts, (b) where you
have agreed a debit memo procedure and (c) if your vendor is making a refund. During manual
clearing, you manually select open items that balance to zero from an account. The system,
then, marks the items selected as ‘cleared’ and enters a clearing document number and the
clearing date in the document items. The clearing date can be the current date or a date that
you enter manually. The clearing document number is the number of the most recent
document involved in the clearing transaction.
The clearing functionality in SAP supports, besides the above, posting reversals / returns
(during reversal /returns, all the items that were cleared earlier becomes open items again)
and resetting of clearing (helps you to overcome accidental clearing transactions by resetting
to the original status).
To configure the system for open item clearing you need to complete the following tasks:
•
•
•
•
•
•
Define Accounts for Exchange Rate Differences
Define Account for Rounding Differences
Define Posting Key for Clearing Open Items
Make Settings for Processing Open Items
Prepare Automatic Clearing
Clearing Differences
276
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You have already configured some of these settings as a part of ‘Outgoing Payments Global
Settings’ vide Chapter 6: for example, we have covered defining the accounts for exchange
rate differences in Section 6.1.5, defined the accounts for rounding differences in Section
6.1.6 and covered the posting keys definition for clearing in Section 6.1.9.
Let us, now, look at the settings that will be required for processing open items.
11.1 Make Settings for Processing Open Items
There are several settings under this configuration activity like:
•
•
•
•
•
Define Line Layout for Document Change/Display
Select Standard Line Layout for Document Change/Display
Choose Selection Fields
Choose Search Fields
Choose Sort Fields
However, you need to check and/or change the settings specified in the above activities, only
if you are not using line item display without the ABAP List Viewer. Since, the Project Dolphin’s
team has recommended to use ABAP List Viewer for line item display, you do not need to
make any settings here.
With this, we are now ready to configure system for automatic clearing.
11.2 Prepare Automatic Clearing
The ‘automatic clearing program’ also uses the clearing transactions that are provided for
manual clearing. This includes, for example, automatic posting of exchange rate differences,
or automatic generation of transfer postings if items from different business areas / trading
partners are involved in clearing. Also, the program can clear journal entries that were posted
using the ‘net method’ and journal entries that contain parallel currencies.
Here, using this task, you need to specify the criteria for grouping open items, belonging to
an account, for automatic clearing. Besides the two standard criteria (account type and
account number or number interval), you can enter fiver more user-criteria. You, also, need
to specify a clearing date. The program clears the open items that are grouped together, if
their total balance equals zero in local and foreign currency.
Open Item Clearing
277
There are five user-criteria and a variety of fields you can choose from. Ensure that you
specify fields that have an internal length of up to 20 places only. You can enter separate
criteria for each account type, and use an account number interval to determine the accounts
to which the criteria should apply. If you want the system to continue to group open items by
business area or trading partner for automatic clearing, you have to maintain these as usercriteria in the configuration settings.
Project Dolphin
The BESTM management, after some discussion with the project team, requested to
configure four more user-criteria for grouping clearing items for automatic clearing, for more
flexibility: ‘Assignment Number’, ‘Business Area’, ‘Trading Partner’ and ‘Contract Number’ for
customer and vendor, and ‘Segment’ (in the place of contract number) for G/L accounts.
To make the required settings:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > G/L Accounts >
Business Transactions > Open Item Clearing > Prepare Automatic Clearing. You may
also use Transaction OB74.
On the ‘Change View “Additional Rules for Automatic Clearing”: Overview’ screen,
you will see the standard settings (for clearing grouping) that includes the account
type (‘AccTy’) and number interval (‘From Account’ and ‘To Account’). In the case of
account types D and K, adding both numeric and alpha-numeric number intervals will
give all the flexibility. If you leave the chart of accounts field as blank, then, the
settings you make here will be valid for all the charts in the system.
You can include five more fields as user-criteria in the fields ‘Criterion 1’ to ‘Criterion
5’. As per BESTM management’s requirements, we need to include ‘Assignment
Number’ (ZUONR), ‘Business Area’ (GSBER), ‘Trading Partner’ (VBUND) and ‘Contract
Number’ (VERTN) as the additional user-criteria for the chart of accounts BEUS, for
the account types D & K. For the account type S (G/L), instead of the contract number,
we need to include ‘Segment’ (SEGMENT). Click on ‘New Entries’, maintain the usercriteria on the next screen, and ‘Save’ the settings (Figure 11.2).
Maintain similar settings for the chart of accounts BEIN as well.
278
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 11.2 Criteria for grouping Clearing Items in Automatic Clearing
With this, we are now ready to discuss the configuration settings under ‘Clearing Differences’.
11.3 Clearing Differences
You need to complete the following steps to configure the system to take care of clearing
differences:
•
•
•
•
•
Define Tolerances for Customers and Suppliers
Define Tolerance Groups for Employees
Assign Users to Tolerance Groups
Define Accounts for Clearing Differences
Residual Item Posting in Invoice Currency
As regards the configuration steps ‘Define Tolerances for Customers and Suppliers’, ‘Define
Tolerance Groups for Employees’ and ‘Assign Users to Tolerance Groups’, recall that we have
discussed them already in Section 6.2.1 of Chapter 6.
Let us, now, look at defining the accounts for clearing differences.
11.3.1 Define Accounts for Clearing Differences
When clearing customer/vendor accounts, the tolerance groups specify limits within which
differences are accepted by the system and posted automatically to the predefined accounts.
You can use this configuration step to define the account(s) to which these differences should
be automatically posted by the system.
Project Dolphin
The project team has suggested to configure G/L account 44000000 to enable posting of
clearing differences.
i.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > G/L Accounts >
Open Item Clearing
ii.
279
Business Transactions > Open Item Clearing > Clearing Differences > Define Accounts
for Clearing Differences. You may also use Transaction OBXL.
On the ensuing pop-up screen, enter the chart of accounts (BEUS), and on the next
screen, enter the appropriate G/L account, and ‘Save’ (Figure 11.3).
Figure 11.3 G/L Accounts for Posting Clearing Differences
iii.
iv.
v.
Repeat and enter the G/L accounts for the India chart of accounts, BEIN, and ‘Save’
the details.
Do not change the default ‘Posting Keys’; 40 for ‘Debit’ and 50 for ‘Credit’.
Click on the ‘Rules’ and you will see that the default setting is that the accounts are
determined based on ‘Debit/ Credit’. Do not make any changes here also.
This completes our discussion on open item clearing.
11.4 Conclusion
You learned that an ‘open item’ is an uncleared transaction that can be cleared and closed,
only when you post an offsetting amount to that account: when the offsetting amount is equal
to the open item, then it is cleared in full; else, it is cleared partially as there is still a residual
amount that is ‘open’.
You understood that the ‘automatic clearing program’ also uses the clearing transactions that
are provided for manual clearing. For automatic clearing, you learned that you need to specify
the criteria for grouping open items, belonging to an account. Besides the two standard
criteria (account type and account number or number interval), you understood that you can
enter fiver more user-criteria. You learned that the program clears the open items that are
grouped together, if their total balance equals zero in local and foreign currency. You then
learned about the settings that you need to make to handle clearing differences, including
defining the accounts for clearing differences.
With this, we are now ready move on to discuss the settings required for handling down
payment received, in the next Chapter.
12 Down Payment Received
T
he ‘down payment received’ denotes the advance amounts that you receive from your
customers, and accounted in FI-A/R. The down payment received is also known as
‘customer down payments’. To manage down payments received, you need to
complete the following configuration steps in the SAP system:
•
•
•
Define Reconciliation Accounts for Customer Down Payments
Define Tax Accounts for Down Payments Received
Define Account for Tax Clearing
Let us start with the configuration of reconciliation accounts for customer down payments.
12.1 Define Reconciliation Accounts for Customer Down Payments
Use this step to define the G/L accounts for managing the customer down payments (or down
payment requests). In this case, the system automatically posts to these accounts instead of
to the normal A/R reconciliation account. Maintain the required G/L account, per account
type (D = customer) and Special G/L indicator (A, F, etc.) combinations. Ensure if a down
payment or down payment request is to be displayed either as gross or net in the alternative
reconciliation account, via appropriate specification in the ‘Tax Category’ field.
To configure, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Down
Payment Received > Define Reconciliation Accounts for Customer Down Payments, or
Transaction OBXR. On the ‘Maintain Accounting Configuration: Special G/L – List’ screen, you
will see the list of Special G/L transactions (Figure 12.1).
Figure 12.1 Special G/L List for Customer
282
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Double-click on the appropriate row (say, Account Type =D, Special G/L Indicator = A, Down
Payment) and maintain the chart of accounts on the resulting pop-up screen. On the next
screen (Figure 12.2):
i.
ii.
iii.
Maintain the reconciliation account(s) for the Special G/L account (s).
You will use the ‘Planning level’ field to control the displays in SAP Cash Management.
The key you enter in the ‘Output tax clearing’ field determines the account to which
the clearing entry is made. If the down payment is to be displayed gross in the
business partner's account (in the case of down payments with taxes on
sales/purchases), then, the system requires a clearing entry (as an offsetting entry)
for the taxes on sales/purchases.
Figure 12.2 Reconciliation / Special G/L Accounts for Customer Down Payments
In the next step, let us define the tax accounts to manage down payments received.
12.2 Define Tax Accounts for Down Payments Received
Using this step, you will define the tax accounts, for down payments received, so that the
system can use these accounts in automatic postings.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Down Payment
Received > Define Tax Accounts for Down Payments Received, or Transaction OB40. On the
resulting screen, double-click on the appropriate procedure, enter the chart of accounts on
the pop-up screen and maintain the required G/L accounts on the next screen.
Down Payment Received
283
With this, let us complete the final configuration step for down payment received namely,
defining the accounts for tax clearing.
12.3 Define Account for Tax Clearing
Here, you define an output tax clearing account that is needed, if you display down payments
(gross) in the customer account. Besides the account, you can also specify a key for the
differentiation which groups the Special G/L indicator, the account type and the reconciliation
account together.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Down Payment
Received > Define Account for Tax Clearing, or Transaction OBXB. On the resulting screen, you
will see several procedures listed for down payments (group = ANZ). Double-click on the
appropriate procedure (‘Output tax clearing on down payments’ - transaction MVA) and
maintain the required G/L account(s) on the next screen (Figure 12.3).
Figure 12.3 Account for Output Tax Clearing on Down Payments
You may click on ‘Rules’ to look at the automatic posting settings (Figure 12.4). You can also
click on ‘Posting Key’ to see the associated keys for debit / credit posting.
Figure 12.4 Automatic Posting Rules for Output Tax Clearing on Down Payments
284
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
This completes our discussion on configuring the automatic posting rules for output tax
clearing on down payments. This also completes our discussion on the settings that are
required for configuring down payment received.
12.4 Conclusion
You learned that the ‘down payment received’ (also known as ‘customer down payments’)
denotes the advance amounts that you receive from your customers, and that they are
accounted in FI-A/R. You learned about the various configuration settings required to process
down payments received. In the process, you learned that you need to define alternate
reconciliation accounts so that the system automatically posts the down payments received
to these accounts, instead of to the normal A/R reconciliation account. You learned that you
also need to define tax accounts and tax clearing accounts for handling down payments
received.
With this, we can now proceed to discuss the settings that you need to make for down
payments made by you, in the next Chapter.
13 Down Payment Made
A
s with the ‘customer down payments’ (or ‘down payments received’), the ‘down
payments made’ represent the advance or down payments you make to your vendors
or suppliers. These are also known as vendor down payments and are managed in FIA/P. As with the customer down payments, you need to make the following settings for
vendor down payments:
•
•
Define Alternative Reconciliation Account for Down Payments
Define Account for Tax Clearing
First, let us define the alternative reconciliation account for down payments.
13.1 Define Alternative Reconciliation Account for Down Payments
Here, you define an account in which you manage the vendor down payments in the G/L. The
system, then, makes the down payment posting to this account automatically instead of to
the normal A/P reconciliation account. The configuration is similar to that of the settings
discussed in Section 12.1 of Chapter 12.
Figure 13.1 Special G/L List for Vendor
Here, you will use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Down
Payments Made > Define Alternative Reconciliation Account for Down Payments, or
Transaction OBYR. On the resulting screen (Figure 13.1), you will see the various Special G/L
transactions for vendor (Account type = K).
Double-click on the appropriate transactions (say, down payment made, current assets) and
maintain the required accounts on the next screen (Figure 13.2), for the selected chart of
accounts (say, BEUS).
286
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 13.2 Reconciliation / Special G/L Accounts for Vendor Down Payments
With this, we can now define the accounts for tax clearing for down payments made.
13.2 Define Account for Tax Clearing
Similar to the one that you defined for customer down payment in Section 12.3 of Chapter
12, you need to define the accounts for tax clearing for down payments made. Use the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Business Transactions > Down Payments Made > Define Account for
Tax Clearing, or Transaction OBXB.
Figure 13.3 Account for Input Tax Clearing on Down Payments
On the resulting screen, double click on transaction VVA ‘Input tax clearing on down
payments’ and maintain the accounts on the next screen (Figure 13.3) for the chart of
accounts (say, BEUS).
This completes our discussion on configuring accounts for input tax clearing on down
payments. This also completes our discussion on the settings required for configuring down
payments made.
Down Payment Made
287
13.3 Conclusion
You learned that as with the ‘customer down payments’ (or ‘down payments received’), the
‘down payments made’ (also known as vendor down payments) represent the advance or
down payments you make to your vendors or suppliers, and that are managed in FI-A/P. You
learned that you need to define, as in the case of customer down payments, an alternate
reconciliation account to manage the vendor down payments in the G/L. By this, you
understood that the system makes the down payment postings automatically to this account,
instead of to the normal A/P reconciliation account. You also learned that you need to define
a G/L account for tax clearing.
We shall discuss adjustment postings / reversals in the next Chapter.
14 Adjustment Posting /
Reversal
S
AP allows you to reverse a document that was entered incorrectly; the system clears
the open items as well. You can reverse a document only when (a) it contains no cleared
items, (b) it contains only customer, vendor, and G/L account items, (c) it was posted
with SAP FI, and (d) all the earlier entered values (such as business area, cost center, and tax
code) are still valid. You, normally, post the reversal document in the same posting period as
that of the corresponding original document. However, if the posting period of the original
document has been closed already, then, you may enter a date of an open posting period
(say, the current period) in the ‘Posting date’ field.
If a line item from a source document has been cleared, you can make a reversal only
after the clearing is reset. You can reverse the documents from SD with a credit memo, and
the documents from MM with functions in that component, because the FI reversal function
does not reverse all the values required.
When reversing a transaction, the system updates the transaction figures in two ways: (a) the
document and the reverse document increases the account’s transaction debit and credit
figures by the same amount or (b) after a document has been reversed, the balance of the
affected account is shown unchanged as if the document had never been posted to which is
also called as ‘negative posting’ (‘true reversal’).
You need to complete the following two tasks, to configure the system for adjustment or
reversal postings:
•
•
Permit Negative Posting
Define Reasons for Reversal
Let us complete the settings for negative postings, first.
14.1 Permit Negative Posting
When you mark the reversal and adjustment posting as ‘negative posting’, the system reduces
the transaction figures in customer, vendor and G/L Accounts. By this, the transaction figures
290
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
(after the reversal) remain unchanged at the original level, as if you had not posted the
reversed document and its subsequent reversal. Such negative postings result in changes in
reconciliation between documents and transaction figures: a debit (Dr) item marked as a
negative posting reduces the Credit (Cr) transaction figures and vice versa.
You can maintain the required settings using the menu path: SAP Customizing
Implementation Guide > Financial Accounting > General Ledger Accounting > Business
Transactions > Adjustment Posting/Reversal > Permit Negative Posting. You may also use
Transaction S_ALR_87004651. On the resulting screen, select the ‘Negative Postings Allowed’
check-box, for all the required company codes, and ‘Save’ the settings.
Figure 14.1 Configuring Negative Postings
When you select the ‘Negative Postings Permitted’ check-box, it signals to the system that the
transaction figures on the original side of the account are reset, rather than being increased
on the other side of the account, when documents are reversed. In other words, the system
makes an entry with an opposite sign for reversals, instead of posting to the opposite side of
the account. Because of this, the account balance of the account in question is represented
as though the document had never been posted after the document is reversed. Otherwise,
the transaction figures of the account would be increased by the same amount on the debit
and on the credit side due to the reversal document. This is also called as 'true reversal'.
However, to enable negative postings, you need to have the appropriate document types
defined in the system so as to allow the line items to be flagged individually as negative
postings. Enabling negative postings is per company code, and you also need to define
reversal reasons in the system (refer next Section 14.2).
If the reversal is posted using a posting date other than the one for the document to be
reversed, the settings you make here does not take effect.
You can also configure negative posting while maintaining the company code global
parameters (Transaction OBY6), for the required company codes (Figure 14.2).
Adjustment Posting / Reversal
291
Figure 14.2 Configuring Negative Postings using Transaction OBY6
Let us now go and define the reasons for reversals.
14.2 Define Reasons for Reversal
When performing a reversal, you must specify the ‘reason for reversal’ for the system to
display that in the reversed document’s header. You can define several reversal reasons in
the system: it could be an incorrect posting in the current period, an incorrect posting in a
closed period, a failed bill of exchange and so on. Specify, for each reversal reason, whether
(a) negative posting is to be created in the reversal document and (b) the reversal date can
differ from the posting date of the document that is to be reversed.
292
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Project Dolphin
In addition to allowing negative postings in all the company codes of BESTM, the project
team has been asked to configure suitable document reversal reasons in the system to
handle the reversal transactions. It has been clarified to the team that:
•
•
If the reversal is happening in the current period, then, the system should allow
negative posting, but not allow to change the posting date (of the document to
be reversed).
If the reversal is to happen in a closed period, then, the following conditions
should be met:
o Negative postings can be allowed but without altering the posting date
(of the document to be reversed).
o Negative postings cannot be allowed but the posting date (of the
document to be reversed) can be altered.
Let us configure this:
i.
ii.
iii.
iv.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Business Transactions > Adjustment Posting/Reversal >
Define Reasons for Reversal. You may also use Transaction S_ALR_87004660.
Click on ‘New Entries’ on the resulting ‘Change View “Reasons for Reverse Posting”:
Overview’ screen.
On the next screen, maintain the required settings:
• Enter a reason code in the ‘Reason’ field and provide an explanation in the
‘Text’ field.
• Select ‘Neg. Pstg’ check-box to allow negative posting to be created in the
reversal document.
• Select ‘Alt.Pos.Dt’ check-box to allow an alternate posting date than that of
the document to be reversed.
‘Save’ the stings (Figure 14.3).
Figure 14.3 Reversal Reasons
Adjustment Posting / Reversal
293
The system will ignore the ‘negative posting allowed’ settings made here, if you have
not configured the company code to permit negative postings.
This completes our discussion on defining the reasons for reversal. This also completes our
discussion on adjustment posting / reversal.
14.3 Conclusion
You learned that you can reverse a document that was entered incorrectly, and that is
possible only when (a) it contains no cleared items, (b) it contains only customer, vendor, and
G/L account items, (c) it was posted with SAP FI, and (d) all the earlier entered values (such as
business area, cost center, and tax code) are still valid. You understood that you normally post
the reversal document in the same posting period as that of the corresponding original
document.
You learned that you can mark the reversal and adjustment posting as ‘negative posting’ (also
known as true reversal), so that the system reduces the transaction figures in customer,
vendor and G/L Accounts. By this, you understood that the transaction figures (after the
reversal) remain unchanged at the original level, as if you had not posted the reversed
document and its subsequent reversal. Such negative postings, you understood, will result in
changes in reconciliation between documents and transaction figures: a debit (Dr) item
marked as a negative posting reduces the Credit (Cr) transaction figures and vice versa.
When performing a reversal, you learned that you must specify the ‘reason for reversal’ for
the system to display that in the reversed document’s header. You also learned that you need
to specify, for each reversal reason, whether (a) negative posting is to be created in the
reversal document and (b) the reversal date can differ from the posting date of the document
that is to be reversed.
We can move on to discuss interest calculation in the next Chapter.
15 Interest Calculation
I
n SAP FI, you will come across two types of interest: balance interest (also known as ‘bank
interest’) and item interest (also known as ‘arrears interest’). You will use the ‘balance
interest calculation’ functionality, to calculate interest on the balance of G/L accounts that
are managed on open item basis. You may use this, for example, to double-check the interest
calculation made by the bank on your accounts. You will use the ‘item interest calculation’ to
calculate interest on you customer / vendor accounts.
Since you have already made the settings for bank account interest calculation as a part of
configuring SAP G/L Accounting, you are aware that the system controls the interest
calculation, for an account, by the settings that you make in the interest indicator that is found
in the master record. This indicator determines, among other things, whether you want to
calculate interest for open or cleared items, whether you want to post the interest, whether
you want to print an interest letter etc. The system always calculates the interest using the
debit interest rate defined for the interest indicator. Of course, you can also make the settings
to use credit interest rates to calculate interest on items that have been paid prior to their
due date.
Before discussing how the system calculates interest, let us first understand the fields (in
customer / vendor master record) that are relevant for interest calculation.
15.1 Fields Relevant for Item Interest Calculation
You will come across two fields, in the company code data area of customer / vendor master
records, that are relevant for the calculation of item interest. They are:
•
•
Interest Indicator
Last Key Date
To calculate item interest for customer / vendor accounts, the ‘interest calculation report’
references the ‘interest indicator’ from the account master record. The most important
specifications (such as, the rules used for interest calculation and the interest rate) for interest
calculation are stored in this indicator. It controls the interest calculation in the system. It
stores (a) the calendar type (say: bank, French, Japanese or Gregorian) that is used for defining
the days due for interest (b) interest rates and the conditions, and (c) the ‘Form’ for the lists.
The interest indicator must belong to the interest calculation type ‘Item interest calculation’
(P). All accounts that you want to be included in the automatic interest calculation run must
296
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
have an entry in this field, in their respective master records; if you want to block an account
from interest calculation, remove the interest indicator entry from this field.
Figure 15.1 Fields Relevant for Interest Calculation (Customer Master Record)
The ‘Last Key Date’ denotes the last time when the interest calculation program processed
this account. This is generally the upper limit of the last interest run. After the interest
calculation program has been run in the background, the system enters the upper limit of the
interest calculation period in this field. This date is, then, used by the system to automatically
determine the interest calculation period for an account.
Generally, this date (Last Key Date) is automatically maintained by the batch input
program. You should make a manual entry, here, only if an error has occurred.
You will see two more fields in Figure 15.1: the ‘Interest Cycle’ (also known as ‘Interest
Calculation Frequency’) and ‘Last Interest Run’ (also known as ‘Date of Last Interest
Calculation’). These fields are relevant only for account balance interest calculation and not
for item interest.
Interest Calculation
297
With this let us now understand how the system handles the interest calculation for item
interest.
15.2 Item Interest Calculation Process
Before getting into the item interest calculation process, let us first understand the
prerequisites that you should have configured, for item interest calculation.
15.2.1 Prerequisites
The following are the prerequisites that should be in place for item interest calculation.
i.
ii.
iii.
You have defined an interest indicator for the item interest calculation (type P) and
made all other relevant specifications. You have also made the required
specifications, for example, whether the interest is to be posted and whether forms
are to be printed. Refer the subsequent Section 15.3.1 wherein we have defined the
interest calculation types, and refer Section 15.3.3 wherein we have completed the
specifications for item interest calculation.
You have entered the interest indicator in the master records of the customers
concerned. Refer the previous Section 15.1 for more details.
You have defined the required conditions for your interest indicators. Refer the
subsequent Section 15.5.2 for more details.
While defining the time-dependent terms, you will not use the ‘Amount from’
field as this is not relevant for item interest calculation, but valid for balance interest
calculation. Specifying an amount, in this field, allows you to specify interest rates
staggered on amounts.
iv.
v.
To send an interest letter, you should have created a Smart Form or PDF form, that is
stored in the system and used for the interest calculation. You may use the default
form F_INTITAR_SF as such, or you can use that as a template to create your own
form. Refer the subsequent Section 15.6 for more details.
You have defined the account determination for posting the interest and defined the
document type to be used. You should have configured the control parameters (for
the posting interface 0002). You should have also completed G/L account assignment
for interest revenue or interest expense). Refer the subsequent Section 15.5.1 for
more details.
With the prerequisites in place, let us understand how to execute the item interest calculation
program.
298
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
15.2.2 Executing Item Interest Calculation Program
Use the SAP Easy Access menu path: SAP Menu > Accounting > Financial Accounting >
Accounts Receivable > Periodic Processing > Interest Calculation > Item Interest Calculation,
or Transaction FINT to start the interest calculation program (RFINTITAR), for item interest
calculation. On the resulting ‘Item Interest Calculation’ screen Figure 15.2:
Figure 15.2 Item Interface Calculation – Initial Screen
i.
ii.
Enter the company code(s), customer (or vendor) accounts, and the interest
calculation indicator(s).
Enter the selection criteria under various data blocks like ‘General Selection’,
‘Posting’, ‘Form’, ‘Performance’ etc. You can also use ‘Dynamic selections’ for
additional select options.
a. To restrict the period of interest calculation, enter the desired date in the
‘Interest Calculation To’ field under’ General Selections’.
Interest Calculation
299
b. You need to select the ‘Also Evaluate Central Accounts’ check-box, under
‘General Selections’, if you work with the head and branch office relationship.
c. For configuring the form for printing interest letters, specify a form name also
specify the information, including the data of issuance of the letter that is to
be printed on the letter in ‘Form’ data block.
If you do not do this, the program uses a default standard form stored
in the system is used.
iii.
Select the ‘Test Run’ under ‘General Selections’ and ‘Execute’. The system brings up
an overview of the items on which interest is to be calculated. The SAP standard ALV
variant is configured in such a way that items for which no interest is due are not
displayed. You can double-click the individual items to see the detailed information
for the interest calculation for the individual items.
From the overview list, you can also post / print a letter.
iv.
When satisfied, deselect ‘Test Run’ check-box and ‘Execute’. The system makes the
update run: posts the interest and prints the interest letters, as per the settings that
you have made earlier.
In the case of FI-A/P, use the SAP Easy Access menu path: SAP Menu > Accounting >
Financial Accounting > Accounts Payable > Periodic Processing > Interest Calculation > Item
Interest Calculation, or Transaction FINTAP. For both FI-A/R and A/P, use Transaction
FINTSHOW to display the interest run.
With the specifications entered and the interest calculation program executed, let us now
understand how the system selects the items and process the item interest calculation.
15.2.3 The Interest Calculation Process
With the prerequisites set in the system (Section 15.2.1) and the select options put in as
described in the previous Section (15.2.2), the system carries out the item interest calculation
as described below:
15.2.3.1 Item Selection
The system identifies the items on which interest is to be calculated, based on the rules that
you have defined in the interest indicator (Section 15.3.3), the settlement date of the interest
run, and the date of the last interest calculation (‘Last Key Date’) in the master record. Besides,
it considers only the (a) items that have been posted to a customer account with a master
300
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
record that contains an interest calculation indicator, (b) items that are not blocked for
interest calculation and (c) items that do not contain a cash discount amount.
In the whole process of identifying the eligible items for item interest calculation, the program
iterates as under:
•
•
•
•
•
•
•
As regards open items, the system calculates interest only on items that are currently
open. The system calculates the interest on these open items up to the upper limit of the
calculation period. It will not calculate interest on open items that are due after the upper
limit of the calculation period.
With regards to the cleared items, the system calculates interest on all cleared items
whose clearing date (posting date of clearing) is before or equal to the upper limit of the
calculation period. The system also calculates interest on items whose clearing date is
after the upper limit of the calculation period, if interest is also calculated on those open
items. The system does not select the items whose clearing date is before or equal to the
key date for the last interest calculation as entered in the account master record (upper
limit of the last interest calculation) as they have already been included the calculation of
the interest. The program does not consider any of the cleared items, irrespective of the
clearing date.
In the case of items cleared by payments, the system considers only the clearing
transactions that contain a payment; that is, it does not consider clearing transactions
that contain only invoices, credit memos, and offsetting items.
The system calculates the interest on open items from their due date for net payment up
to the settlement date. It calculates the interest on cleared items from their due date for
net payment to the due date for net payment of the clearing document. If there is no line
item in the clearing document, then, the system calculates the interest up to the clearing
date.
If an item is overdue and interest is to be calculated, the system compares the number of
days in arrears with the number of tolerance days. If the number of days in arrears is less
than or equal to the number of tolerance days, then, the system does not calculate
interest on that item.
To make allowance for when payments take longer than usual to transfer or when the
relevant accounts are not cleared promptly, you can specify the transfer days for
incoming payments while configuring the interest indicator. The system, then, subtracts
these transfer days from the document date of the payment.
With the factory calendar defining which days are non-working days, if the due date for a
receivable is a non-working day, then, the system moves the due date to the next working
day. If an incoming payment is received on a non-working day as a result of the transfer
days, then, the system moves the incoming payment receipt to the previous working day.
Interest Calculation
•
•
301
If you have selected the ‘Calculate interest on items paid before due date’ (in interest
indicator), then, the system calculates interest also for items that have been paid before
the due date if the items were paid without cash discount being granted. It calculates
credit interest for debit items, and debit interest for credit items. The system also
calculates interest on partial payments made and down payment clearing carried out
before the invoice is due starting from the reference date, if you have selected this checkbox; if not, it calculates from the due date of the invoice.
When you have selected the ‘Only calculate interest on debit items’ check-box (in interest
indicator), the system does not calculate interest on credit items. But, when not selected,
the system treats the credit item of a clearing transaction like an existing debit item, and
calculates interest for it with the same interest rate. This is because if the credit memo is
not cleared right away by the invoice, but cleared later, both the invoice and credit memo
will become overdue and should consequently balance out in terms of interest.
With the understanding of selection of items for the interest calculation, let us now proceed
to discuss how the system calculates the interest.
15.2.3.2 Interest Calculation
If an item qualifies for interest calculation according to the criteria described above, then the
system first calculates the days in arrears depending on the calendar type defined in the
interest indicator. Using the Gregorian or French calendar, the program calculates the exact
number of days. If you have selected the bank calendar or the Japanese calendar, the number
of days is calculated according to the bank calendar that is standard in Germany. Each month
in a bank calendar has 30 days.
Now, the system calculates interest using the reference interest rates that you have defined
(refer Section 15.4.1). The system determines the interest rates valid for a specific item using
conditions. You define these conditions (time-dependent terms) in the system in the key fields
‘Interest Indicator’, ‘Currency Key’, and ‘Eff. from’ (from which the condition is valid) and
‘Sequential Number’ for the valid interest reference (refer Section 15.4.2). The system
determines the final interest rate using a function module (the standard function modules are
DEBIT_INT_RATE_DETERMINE and CREDIT_INT_RATE_DETERMINE). It also adds the discount
or surcharge specified in the interest indicator to the reference interest.
In the standard system, the program calculates the interest on a linear basis. If you want
to use a different formula, you can use method INT_FORMULA of the BAdI FI_INT_CUS01.
In addition to the actual interest, you can also work with fixed amounts. The system
determines these fixed amounts, for each invoice for which interest is calculated. You can
either add the fixed amount fully to the interest, or you can set the fixed amount as a
302
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
minimum. In the second case, only the amount of the difference is added. Refer Section 15.4.4
for more details. The fixed amounts are added to items that are posted as debits (on the credit
side as credits), have a sales-relevant posting key, do not have a reference to an invoice, and
for which interest is due because the items are overdue.
In order to establish whether an interest settlement needs to be created, the system needs
to calculate interest for all items. If the interest amount determined for each interest letter is
less than the amount limit defined for the interest indicator, then, the system creates no
interest debit. If a credit interest amount arises that is at least equal to the amount limit, then,
the system creates no interest settlement when you have selected ‘No interest payment’
check-box while configuring the interest indicator (refer Section 15.3.3).
With this, let us move on to understand how the system carries out posting of the calculated
interest.
15.2.3.3 Interest Posting
While configuring the interest indicator, you can also define the terms of payment and the
tax on sales/purchases code to be used to post the interest (refer Section 15.3.3). If you have
selected the ‘Posting with Invoice Ref’ check-box, then, the system enters a reference, to the
items on which interest has been calculated, in all interest postings. The invoice reference
type here is F. In the calculation of interest on items that themselves refer to an invoice (entry
in field REBZG), the interest documents refer to the original invoice. If you want these interest
documents to have certain characteristics of the documents on which interest has been
calculated, you need to enter the corresponding characteristics in the ‘Transfer Content’ fields
(refer Section 15.3.3).
15.2.3.4 Printout
You can create an interest letter with a list of items for each customer, currency, and one
other grouping criterion. If you start the interest calculation report as a test run (Transaction
FINT), you see an overview of all the items on which interest has been calculated. If errors
occur, you receive an error log.
The system creates an interest intimation letter to your business partners with the
appropriate text, overview of the line items, interest rates and interest. You need to select
the ‘Print Interest per Int. Rate’ check-box (under ‘Form’ data block) to print an overview table
of the interest rates at the end of item list.
15.2.3.5 Others
You can use the report ‘Interest Run Display’ (RFINTITSHOW) to display interest runs that you
have performed, to reverse them, or to print forms again.
Interest Calculation
303
You can also delete entries from the interest tables INTITHE, INTITIT, and INTITPF using report
RFINTITDEL. However, you can only delete entries from the interest tables for items for which
interest has already been completely calculated. The program RFINTITDEL checks this
automatically. For items on which interest has been calculated in full, the program deletes
the detailed information about the interest calculation from table INTITIT without further
checking, based on the entries on the selection screen. For an item, for which the entries in
table INTITIT have been deleted, you can no longer track the interest history or determine the
amount of interest that was due on this item. Even after you have deleted tables INTITIT and
INTITPF for a specific item, table INTITHE still contains the information that interest has been
calculated on this item in full. This information is sufficient for any future calculation of
interest by program RFINTITAR. As long as the entry remains in table INTITHE, duplicate
calculation of interest on the item is not possible.
15.2.3.6 Old and New Interest Calculation Programs
The old interest calculation program RFDUZI00 has since been updated with the new program,
RFINTITAR. The new program contains the following changes and enhancements:
•
•
•
•
•
•
•
•
The selection screen has been simplified; several of the selection criteria have been
moved to Customizing for the interest indicator.
Using report RFINTITUSERXT, you can insert additional selection criteria in the
interest calculation. You can also use this report to define additional fields to be
displayed on the form.
The form is now created with Smart Forms or PDF (previously: SAPscript).
The interest posting is no longer triggered by running a batch input session; the report
posts the interest documents directly using the accounting interface. This means that
the document number for the interest posting can also be displayed on the form.
The results of the interest calculation are created in detail on the database (Tables
INTITHE and INTITIT). As a result, now, you can (a) use report RFINTITSHOW to view
the interest runs that have been carried out, (b) print interest runs and (c) reverse
and repeat individual interest postings or complete interest runs.
If you start the program as a test run instead of an update run, you receive an
overview of the items on which interest is to be calculated in the ABAP List Viewer
(ALV). To display the items on which no interest is to be calculated, delete the ALV
filter. You can double-click the individual items to view the detailed information. You
can display the letters to be created and trigger printing and updating of all letters or
selected letters. It is not possible to select individual items within an interest letter
for processing. It is also not possible to manually change the interest calculated.
You can calculate interest on items from assigned vendors.
The relationships between a branch and the head office are taken into account.
304
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
The interest calculation using numerators is no longer supported.
With this, let us proceed to configure the system for item interest calculation.
We shall discuss the settings under the following four groups:
1.
2.
3.
4.
Interest Calculation Global Settings
Interest Calculation
Interest Posting
Printout
Let us start with the first group of settings, namely the global settings for interest calculation.
15.3 Interest Calculation Global Settings
The global settings for interest calculation include the following configuration steps:
•
•
•
•
Define Interest Calculation Types
Define Number Ranges for Interest Forms
Prepare Item Interest Calculation
Prepare Account Balance Interest Calculation
Let us get started with the first activity of defining the interest calculation types.
15.3.1 Define Interest Calculation Types
We have already completed this step vide Section 10.2.3.1 of Chapter 10, wherein we have
defined two interest indicators (1I and 1U) for item (or arrears) interest calculation (type P),
and two (2I and 2U) more for balance interest calculation (type S). In case you want to revise
or check, you may use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Interest
Calculation > Interest Calculation Global Settings > Define Interest Calculation Types.
The next step is to define the number ranges for the interest forms.
15.3.2 Define Number Ranges for Interest Forms
You can define the number ranges for the interest forms, per company code, following the
menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Interest Calculation > Interest
Calculation Global Settings > Define Number Ranges for Interest Forms, or Transaction FBN1.
On the resulting screen, enter the company code and maintain a number range with internal
number assignment (Figure 15.3). If you are calculating interest on accounts from various
company codes, then, you need to define the same number range for each company code.
The system stores the number, in the ‘Reference’ field, while posting the interest.
Interest Calculation
305
Figure 15.3 Number Range for Interest Forms
The system does not use the umber ranges defined for interest calculation for any other
purposes (for example, for document types).
You do not need to configure this step, if you have already defined a separate number range
for interest forms, while configuring the FI global settings - menu path: SAP Customizing
Implementation Guide > Financial Accounting > Financial Accounting Global Settings >
Document > Document Number Ranges > Define Document Number Ranges.
The next step is to prepare the system for item interest calculation.
15.3.3 Prepare Item Interest Calculation
This is similar to the one that you have configured for balance interest calculation in SAP
General Ledger Accounting, wherein completed the settings for preparing for account balance
interest calculation. As in that, here also, you will make the general settings (like, item
selection, interest determination, post-processing, output control, posting etc) for the
individual interest indicators (say, 1U and 1I) for the item (or arrears) interest calculation. All
these settings relate to the standard SAP program RFINTITAR.
Project Dolphin
BESTM has suggested to the project team to configure the item interest calculation in such a
way that (a) the system should calculate the interest as and when it becomes due but on the
due date for net payment, (b) the value date should be the baseline date for net payment, (c)
there would be a grace period of 5 days for payment without interest after the receivable
payments become due, (d) the system should calculate interest both on debit and credit items
using the respective interest rates and (e) there should not be any interest calculated on items
that have been paid before the due date. In case of interest settlement, it has been directed
that there should not be any interest settlement if the interest amount is less than $10 for all
US-based company codes, and INR 100 for India-based company codes. It was also suggested
that the interest receivables should be created and posted with reference to the invoice for
which interest was calculated.
306
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Let us make the settings using the menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions >
Interest Calculation > Interest Calculation Global Settings > Prepare Item Interest Calculation.
On the resulting screen, click on ‘New Entries’ and make the appropriate settings on the next
screen (Figure 15.4):
i.
ii.
iii.
Enter the interest indicator (say, 1U) for item interest calculation (‘Interest Ind.’).
Under ‘Item Selection’, select the ‘Open Items’ check-box, and also select the ‘All
Cleared Items’ radio-button.
On the ‘Interest Determination’ block:
• Do not select ‘Always Calculate Int. from Net Dte’ check-box. Else, the system
will calculate interest only as of the due date for net payment.
• Enter the value date in the ‘Ref Date’ field. Enter 1, here, as you want the
system to refer to the baseline date for net payment as the value date. The
other options include document date (2), posting date (3) and payment
baseline date (4).
• Enter the ‘Calendar Type’. Let this be ‘G’. Dependent on the calendar type, a
year has a different number of days: The bank calendar and French calendar
have 360 days, whereas, the Gregorian and Japanese calendars have either
365 or 366 days (leap years). If the interest period goes over the boundary
into a leap year, the length of the year is between 365 and 366, based on the
proportion of the interest period that falls in the leap year.
• Leave the ‘Transfer Days’ field as blank. The system recognizes the ‘transfer
days’ are only for incoming payments, and these days have no meaning for
open items.
• Enter ‘Tolerance Days’, if any. When entered, the system does not calculate
the interest, for these many grace days, on customer receivable even after
they become due. It will be 5 for BESTM.
• Select the ‘Calculate interest on items paid before date’ check-box if you want
the system to calculate the credit interest (using credit interest rates) for
items that are paid before their due date, subject to the condition that the
paid items were not subject to cash discount. We shall not select this for 1U.
• You have to select ‘Only calculate interest on debit items’ check-box, if you
want the system to calculate interest only on debit items ignoring the credit
ones.
Interest Calculation
Figure 15.4 Configuring Item Interest Indicator (1U)
307
308
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
When ‘Only calculate interest on debit items’ check-box is not selected,
the system calculates interest on credit items as well, by treating them as
debit items by applying the same (debit) interest. This is because, if the credit
memo is not cleared immediately by the invoice, but cleared later, both the
invoice and credit memo will become overdue and will eventually balance out
in terms of interest.
iv.
In the ‘Amount Limit’ field, under ‘Interest Postprocessing’, enter the amount limit
and the respective ‘Currency’ in the adjacent field. If the system-calculated interest is
below this threshold per currency per account, then the system does not generate an
interest settlement. Select the ‘No Interest Payment’ check-box, if you do not want
the system to create an interest settlement when an interest payment is produced.
The system produces an interest payment when the credit interest (on items
paid before the due date) is greater than the debit interest.
v.
vi.
vii.
Under ‘Output Control’, do not select the ‘Print Form’ check-box if you want only an
account-level overview; else, select the flag. Enter the ‘Number Range’ for the
interest forms.
Under ‘Posting’, select the ‘Post interest’ check-box enabling the system to post the
interest.
Under ‘Posting Conditions’ you may also maintain the ‘Payment terms’ and ‘Tax
Code’. Select the ‘Posting with Invoice Ref.’ check-box, so that, the system creates the
interest receivable and posts the same with reference to each of the invoices for
which interest is calculated; the system creates a separate line item that contains the
corresponding invoice reference.
In the case of account balance interest calculation, the system posts the interest
by a batch input session, only when you ‘run’ the session. On the other hand, in the
item interest calculation, the system posts the interest when you start the program
as an ‘update’ run.
viii.
‘Save’ the settings, and create the other item interest indicator 1I for BESTM.
The next step is to make the settings for account balance interest calculation
Interest Calculation
309
15.3.4 Prepare Account Balance Interest Calculation
Define the general interest calculation specifications per interest indicator, in this step. The
specifications include the period determination, the interest determination, the interest
processing, the output controls, and the payment terms.
Project Dolphin
BESTM management wants the project team to configure the two new interest indicators
with the details as under:
The interest calculation frequency is to be set at six months for the staff loans, for both India
and USA, in the interest indicators. The Gregorian calendar needs to be used for interest
calculations. The interest settlement should be configured to be on the last day of the month.
The interest needs to be charged on a graduated scale for all the staff loan accounts, for USbased company codes, at 2% interest up to $10,000; 3% up to $25,000; and 4% in excess of
$25,000; for India, the corresponding figures will be: 8% for loans up to INR 200,000, 9% up
to INR 500,000 and 10.5% for above INR 500,000. The interest will have to be settled when
the interest amount calculated is in excess of $10 and INR 100 respectively for US and Indiabased company codes. The interest needs to be paid within 10 days of interest posting to the
respective accounts. The interest posting is to be made to the appropriate G/L accounts, one
for interest paid (71100000) and another for interest received (70100000). The system should
use the document type SA for interest posting.
To configure the global interest calculation specifications for the two new interest indicators
(2I and 2U), for account balance calculation, that we have created earlier:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Interest
Calculation > Interest Calculation Global Settings > Prepare Account Balance Interest
Calculation. You may also use Transaction OBAA.
On the resulting screen, click on ‘New Entries’ and maintain the details (Figure 15.5):
• Enter the ‘Interest Indicator’.
• In the ‘Period determination block’, enter the interest calculation frequency
(‘Interest calc. freq.’). This will be 6 for BESTM. An entry in this field
determines the interval (in months) for interest calculation for the accounts.
The system adds the interest calculation frequency entered here, to the date
of the last interest calculation to arrive at the upper limit for selecting the
accounts for the interest run. You can maintain the interest calculation
frequency, either here in the interest indicator or in the G/L account master
record. The entry in the master record has the precedence.
310
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
For example, if you enter 06 (as in our case) here in the interest
indicator, with the last interest calculation date being 6/30, the system
arrives at the upper limit as 12/31 for the next interest calculation. Also
consider the other example wherein you have specified the interest
calculation date (say, 15/12/2019) as a report parameter to determine
whether an account is included in a particular interest run. Then, the system
compares this new upper limit with the upper limit already calculated (using
the interest calculation frequency and last interest calculation date); if the
calculated upper limit (say, 12/31/2019) is after the new calculation period
based on the date entered in the report parameter (15/12/31), then, that
account is not included in the current interest run.
•
Along with the interest calculation frequency and the key date of the last
interest calculation, the ‘Settlement day’ determines the upper limit of the
interest calculation period to be included in a program run. You can specify a
value between 01 and 31.
Consider the example where in the last interest calculation was on
6/30/2019, and the interest calculation frequency at 3 months. The system,
now, calculates the upper limit month as 9 from the upper limit date
9/31/2019. If the settlement day is mentioned as 25, then the upper limit is
arrived to be 9/25. In case this calculation results in an invalid date such as
6/31, for example, then the system sets this as to the end of that month, that
is 6/30. It also takes care of the year issues by automatically registering a
change to the next year when the month of the key date (say, 09) plus interest
calculation frequency (say, 06) exceeds 12; the upper limit will, then, be
arrived at 03.
•
The ‘Calendar Type’ determines how many days per month and year are to
be used as the basis for calculating interest. The number of days in the year
is used as the divisor for the interest rate to calculate the daily interest rate
from the annual interest rate. You have the options like, bank calendar (B)
which is 30/360 (30 days in a month and 360 days in a year), French calendar
(F) which is made up of calendar months (30,28, 31 days) but 360 days in a
year, Gregorian calendar (G) which is the regular calendar (28, 30, 31/365)
and Japanese calendar (30 days in a month and 365 days in a year). Select G
for 2U.
Interest Calculation
311
Figure 15.5 Configuring Interest Indictor
•
•
•
•
Together with the calendar type B or J, this ‘Month-end indicator’ decides
how, for example, February 28 or July 31 needs to be treated. When this is
selected and the calendar type is set to be B, then, the month-end is
considered to be 30 (not 28 or 31). The system, then, will arrive at the number
of days, for example, between January 31 and February 28, as not 28 but 30.
You should not select this check-box for the interest indicator 2U as we will
be using the calendar type G.
Under ‘Interest determination’ block, select the ‘Calendar Type’. It
If you select ‘Int calc. numerators’ check-box, then, the program calculates
interest using numerators; else, the interest is calculated directly.
The ‘Round IC numerators’ is used along with the ‘Int calc. numerators’ flag.
When this is selected, it rounds off the numerators.
312
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Select 'Interest rate depend on total amount' check-box if you want to use
the graduated (amount-dependent) interest rates for the total amount.
When unselected, the interest rates refer to each difference between the
amount (slabs) for which interest is calculated and the amount from which
the interest rate is valid.
Consider an example where the outstanding in the account is $15,000.
The interest rate is to be calculated as: 0% of amounts up to $5,000, 6% for
amounts up to $10,000, 10% on amounts above $10,000. when 'Interest rate
depend on total amount' check-box is selected: the interest is calculated at
the total outstanding of $15,000 @ 10% which will be $1,500 (=15000*0.10).
When 'Interest rate depend on total amount' check-box is not selected: the
interest is calculated for the first slab of $10,000 @ 6% and for the next
$5,000 @10%, and the interest will be $1,100 (=600+500).
•
iii.
iv.
If you want the interest rate to be determined through a function module
instead of the standard method (via, transaction and business types), enter
the name of the function module here in this ‘Function Module’ field.
• Under ‘Interest processing’, enter the ‘Amount Limit’ beyond which only the
system will create an interest settlement; that is, if the calculated interest is
less than the amount entered here, then, there will be no interest settlement
made. This way, you can avoid interest settlements being created for small
amounts that will be meaningless if, for example, the cost of
settling/delivering that interest is higher than the interest amount calculated.
Along with the amount limit, you can also maintain the currency here.
• If you select ‘No interest payment’ flag, then, the system will not make an
interest payment even if there is an interest settlement.
• Under ‘Output control’, enter a ‘Number range’ to enable numbering of the
interest forms; when you post an interest document, then, the system uses a
number from this number range and stores the form number in the
‘Reference’ field. You may enter a range that has not been used earlier, but,
in that case you need to create that number range using Transaction FBN1.
• If you select ‘Balance plus int’ flag, then the system prints the balance plus
interest.
• Under ‘Posting’ select the appropriate ‘Payment terms’, if required.
‘Save’ the details. This completes the settings required for the interest indicator 2U.
You may copy this and make the necessary changes to create the other account
balance interest indicator, 2I.
Interest Calculation
313
This completes our discussion on the global settings for interest calculation. Let us move on
to the settings required for interest calculation.
15.4 Interest Calculation
The configuration steps under this group, include the following:
•
•
•
•
Define Reference Interest Rates
Define Time-Based Terms
Enter Interest Values
Define Fixed Amounts for Interest Calculation
Let us start with the definition of reference interest rates.
15.4.1 Define Reference Interest Rates
Let us define the reference interest rates for item interest calculation, here. Use the menu
path: SAP Customizing Implementation Guide > Financial Accounting > Accounts Receivable
and Accounts Payable > Business Transactions > Interest Calculation > Interest Calculation >
Define Reference Interest Rates, or Transaction OBAC. Click on ‘New Entries’ and create the
required reference interest rates: one for credit and another for debit, on the next screen
(Figure 15.6).
Figure 15.6 Reference Interest Rate – Item Interest Calculation – Credit
The next step is to define the time dependent terms for each of the reference interest rates
that we have defined in the previous step.
15.4.2 Define Time-Dependent Terms
Here, you specify how the interest rate is to be determined for each of the item interest
indicators per currency and per validity date. Use the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
314
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Business Transactions > Interest Calculation > Interest Calculation > Define Time-Dependent
Terms. You may also use Transaction OB81.
Figure 15.7 Time Dependent Interest Terms of Interest Indicator 1U
On the resulting screen, click on ‘New Entries’ and make the required settings for the item
interest indicator 1U, for both credit and debit reference interest rates (Figure 15.7). Note
that you need to select the appropriate ‘Term’ (for example, ‘Debit interest: arrears interest
calc’) corresponding to the ‘Ref. interest rate’ (for example, 1U-D). In the ‘Premium’ field,
enter the percentage rate that needs to be added to the reference interest rate. If you do not
make an entry in the ‘Ref. interest rate’ field, then, the system uses the value entered in the
‘Premium’ field as the interest rate, provided this value is positive.
Repeat and complete the configuration for the other item interest indicator 1I as well.
When fully configured, you have all the settings defined for both item and balance interest
indicators as shown in Figure 15.8.
Figure 15.8 Time Dependent Interest Terms for BESTM
Interest Calculation
315
The next step is to maintain the interest values per validity for the reference interest rates
that we have defined in the earlier step.
15.4.3 Enter Interest Values
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Interest Calculation >
Interest Calculation > Enter Interest Values or Transaction OB83, and maintain the interest
rates (both debit and credit) for the various item interest reference interest rates.
Figure 15.9 Interest Rate Values for Reference Interest Rates for Item Interest
On the resulting screen, click on ‘New Entries’ and enter the percentage of interest associated
with each of the reference interest rates (like 1U-C, 1U-D, 1I-C and 1I-D) for the item interest
calculation (Figure 15.9).
With this, let us complete the last step in making the settings for interest calculation, that is
defining the fixed amounts for interest calculation.
15.4.4 Define Fixed Amounts for Interest Calculation
Using this configuration step, you can specify a fixed amount as a surcharge or minimum
amount for the interest calculation. The fixed amount entered here will depend on the
country of the company code, the interest indicator, and a validity date. The system applies
this minimum amount, once for each invoice, for which interest has been calculated. You also
make this applicable for each of the installments amounts that is due.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Interest Calculation >
Interest Calculation > Define Fixed Amounts for Interest Calculation. On the resulting screen,
click on ‘New Entries’ and maintain the details (Figure 15.10) on the next screen:
316
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 15.10 Fixed Amounts for Interest Calculation
i.
ii.
iii.
iv.
v.
vi.
Enter the interest indicator (Int.Ind.’), select the country (‘Ctr’) and fill in the effective
date (‘Eff.from’).
Enter the fixed interest amount (‘Fixed Interest Amt’) and select the currency (‘Crcy’).
Select the ‘At Least’ check-box to make this as the minimum amount. If you do not
select this check-box, then, this is considered as a surcharge and added to the interest
calculated by the interest program.
When you select the ‘PerInstlmt’ check-box, the settings are applied for each of the
instalments from the business partner.
Specify the exchange rate type (‘ExRt’) and the ‘Conversion Date’ to be used for
currency translation, in case of items posted in a foreign currency.
Repeat the settings for the other item interest indicator, 1I, and ‘Save’ the details.
Consider that you have entered $50 in the ‘Fixed Interest Amt’ field.
Scenario 1: You have not selected ‘At Least’ check-box. Supposing that the system
calculates the overdue interest as $9.97, the system adds $50 as the surcharge and
customer has to pay a total interest of $59.97.
Scenario 2: You have selected ‘At Least’ check-box. Supposing that the system
calculates the overdue interest as $9.97, the system makes the minimum interest as
$50 to be paid by the customer. However, if the overdue interest arrived at is (say,
$55.67) more than the minimum amount (say, $50) the system does not add extra
charge and the customer will be paying only $55.67.
This completes our settings for interest calculation in the system. Let us move on to see the
settings that you will have to make for interest posting.
Interest Calculation
317
15.5 Interest Posting
You need to complete the following configuration steps, under this category:
•
•
•
•
A/R: Calculation of Interest on Arrears
Interest on Arrears Calculation (Vendors)
A/R: Balance Interest Calculation
A/P: Balance Interest Calculation
Let us get started with the first step: A/R: Calculation of Interest on Arrears.
15.5.1 A/R: Calculation of Interest on Arrears
Here, you will define the settings for posting the interest calculated as interest on arrears. The
system carries out the account determination via the posting interface 0002 (interest on
arrears). Make the required specifications for (a) account determination & posting keys, (b)
G/L accounts and (c) document type.
In the case of account determination & posting keys, decide which account determination
keys you need to use for the two business transactions: interest earned (1000) and interest
paid (2000). The other account determination keys like company code, interest indicator and
business area are all optional. Then, per account determination key, you also need to maintain
the debit / credit posting key and the posting details (account symbols). Use the account
symbol 1000 for customer posting. For each of the G/L accounts, you will have to specify the
account allocation for interest received and interest paid; if required, you can make separate
entries for different currencies. You can use the document type DA as recommended in the
standard system.
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Interest
Calculation > Interest Posting > A/R: Calculation of Interest on Arrears. You may also
use Transaction OBV1.
On the resulting screen, you will see the default specifications from SAP; do not make
any changes to the standard account determination settings (Figure 15.11).
318
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 15.11 A/R: Calculation of Interest on Arrears – Account Determination Settings
iii.
Choose ‘Goto > Control’ on the menu bar to view the posting interface (0002) and the
associated control parameters. You will see the various account determination keys
and their controls settings (Figure 15.12).
Interest Calculation
319
Figure 15.12 A/R: Calculation of Interest on Arrears – Control Parameters
iv.
Click on ‘Symbols’ to see the account symbols and their descriptions (Figure 15.13).
Figure 15.13 A/R: Calculation of Interest on Arrears – Account Symbols
v.
Now, you may click on ‘Accounts’ on the ‘Maintain Account Determination: Posting
Specifications’ screen, to maintain the required G/L accounts on the next screen
(Figure 15.14) for your chart of accounts (say, BEUS).
Figure 15.14 A/R: Calculation of Interest on Arrears – G/L Account Assignment
320
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
A ‘+’ in ‘Currency’ field indicates, that the settings are valid for all the currencies. A
masking entry of ++++++++, in the ‘G/L Acct’ field establishes (assuming that you want
to replace the G/L account) the actual G/L account which is to be posted to, after
possible modifications.
vi.
Click on ‘Go To > Document type’ on the menu bar and specify the appropriate
document type in ‘Document type’ field (DV) for interest posting interest on arrears
(Figure 15.15).
Figure 15.15 A/R: Calculation of Interest on Arrears – Document Type Specification
The next step is to understand the settings relating to arrears interest calculation for vendors.
15.5.2 Interest on Arrears Calculation (Vendors)
This is similar to the previous step, except that the settings relate to vendors. Here, you will
use the menu path: SAP Customizing Implementation Guide > Financial Accounting > Accounts
Receivable and Accounts Payable > Business Transactions > Interest Calculation > Interest
Posting > Interest on Arrears Calculation (Vendors). You may also use Transaction OBV9.
Here, the system carries out the account determination via the posting interface 0009
(interest on A/P arrears).
The next step is to look at the settings for A/R balance interest calculation.
15.5.3 A/R: Balance Interest Calculation
This is also similar to the previous step discussed in Section 15.5.1, except that the posting
interface will be 0005 (customer interest scale). You will use the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Business Transactions > Interest Calculation > Interest Posting > A/R: Balance Interest
Calculation. You may also use Transaction OBV3.
As in the previous step, you can click on ‘Accounts’ from the main posting specifications
screen to maintain the required G/L accounts for each of the account symbols (Figure 15.16).
Interest Calculation
321
Figure 15.16 A/R Balance Interest Calculation – G/L Accounts
The various ‘Account symbols’ are as shown in the Figure 15.17.
Figure 15.17 A/R Balance Interest Calculation – Account Symbols
With this, we can see the settings required for A/P balance interest calculation, next.
15.5.4 A/P: Balance Interest Calculation
This is similar to the previous step, except that the posting interface will be 0006 (vendor
interest scale). The menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Interest
Calculation > Interest Posting > A/P: Balance Interest Calculation or Transaction OBV4, will
take you to the main posting specifications screen with the default standard settings from
SAP which need not be changed. As in previous steps, you just to need to maintain the
required G/L accounts by clicking on ‘Accounts’.
With this, we are, now, ready to see the last set of settings for configuring interest calculation:
interest printout.
322
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
15.6 Printout
There are two configuration activities relating to the printout settings for interest notices:
•
•
Assign Forms for Interest Indicators
Define Sender Details for Interest Forms
Let us start with the first activity of assigning appropriate forms for interest notices/printouts.
15.6.1 Assign Forms for Interest Indicators
Specify which form you want the system to use, for printing the letter on interest on arrears
or account balance interest, for each of the interest indicators. The system uses the forms
configured, here, if no other form has been specified when calculating interest.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Interest Calculation >
Printout > Assign Forms for Interest Indicators. You may also use Transaction OB84.
On the resulting screen, click on ‘New Entries’ and maintain the appropriate form per interest
indicator per company code; the form can be ‘SAPScript Form’ or a ‘Smart Form’. Repeat the
entries to cover all the company codes and all the interest indicators (Figure 15.18).
Figure 15.18 Forms for Interest Calculation
The next activity is to define the sender details for the interest forms.
15.6.2 Define Sender Details for Interest Forms
This step is the same as what we have already discussed in Section 10.3.4 of Chapter 10, when
we talked about the printout settings for dunning / interest notices. You will define the
standard texts for the header, the footer, and the sender address in the letter window for
each company code. You may use the menu path: SAP Customizing Implementation Guide >
Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions >
Interest Calculation > Printout > Define Sender Details for Interest Forms.
This completes our discussion on interest calculation.
Interest Calculation
323
15.7 Conclusion
You learned that you will come across two types of interest, in SAP: balance interest (also
known as ‘bank interest’) and item interest (also known as ‘arrears interest’). You understood
that will use the ‘balance interest calculation’ functionality, to calculate interest on the
balance of G/L accounts that are managed on open item basis, and you will use the ‘item
interest calculation’ to calculate interest on you customer / vendor accounts.
You learned that there are two fields, namely the ‘Interest Indicator’ and the ‘Last Key Date’
in the company code data area of customer / vendor master records, that are relevant for the
calculation of item interest.
You learned about the item interest calculation process in detail: you learned the
prerequisites, the execution of item interest calculation and the actual interest calculation.
You learned that the system identifies the items on which interest is to be calculated, based
on the rules that you have defined in the interest indicator, the settlement date of the interest
run, and the date of the last interest calculation as in the master record.
While configuring the global settings for interest calculation, you defined the interest
calculation types, number ranges for interest forms and prepared the system for item /
account balance interest calculation. You learned that there are two interest calculation types
balance interest calculation (type S) and item (or arrears)interest calculation (type P). Towards
preparing for item interest calculation, you made the required general settings (like, item
selection, interest determination, post-processing, output control, posting etc) for the
individual interest indicators. You learned that the most important specifications (such as, the
rules used for interest calculation and the interest rate) for interest calculation are stored in
the interest indicator, which controls the interest calculation in the system. You learned that
it stores the calendar type that is used for defining the days due for interest, the interest rates
and the conditions, and also the ‘form’ for the interest lists. You learned that all accounts that
you want to be included in the automatic interest calculation run must have an entry in the
‘Interest Indicator’ field, in their respective master records. You also learned that if you want
to block an account from interest calculation, then, you need to remove the interest indicator
entry from this field.
Towards configuring the interest calculation in the system, you maintained the reference
interest rates, time-dependent terms, interest values and also the fixed amounts, if any, for
interest calculation. You understood that you need to specify how the interest rate is to be
determined for each of the item interest indicators, per currency and per validity date, using
the time-dependent terms. You also learned that you can specify a fixed amount as a
surcharge or minimum amount for the interest calculation, and the fixed amount entered will
depend on the country of the company code, the interest indicator, and a validity date. You
324
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
learned that the system applies this minimum amount, once for each invoice, for which
interest has been calculated. For interest posting, via the appropriate posting interface, you
made the required specifications for account determination & posting keys, the G/L accounts
and) the document type.
You also completed configuration activities relating to the printout settings for interest
notices.
Let us, next, see the settings associated with closing operations, in the next Chapter.
16 Closing
Y
ou can group the configuration settings for various closing activities, for FI-A/R and FIA/P, under the following three categories:
1.
Count
2. Valuate
3. Reclassify
Let us start with the first category of settings.
16.1 Count
The program ‘Reconciliation of Receivables/Payables in Group (Cross-System)’ helps you to
reconcile customer documents and vendor documents of the affiliated companies in the
group. It reads the open items of selected companies for the key date specified, thereby
helping you to identify documents that cause a difference. The overall process is as shown in
Figure 16.1.
The intercompany reconciliation program supports the following processes:
•
•
•
Process 001 (Reconciliation of Open Items in G/L Accounts)
Process 002 (Reconciliation of G/L Account Line Items)
Process 003 (Reconciliation of Open Items in A/R and A/P)
Figure 16.1 Reconciliation of Group Receivables / Payables – Process Flow
The processes 001 and 003 usually relate to the reconciliation of group payables / receivables.
You can process 001 and 003 separately or integrate the open items of one process into the
other and process the same simultaneously; SAP supports both the options as variants. You
can use process 002 to reconcile accounts that are not managed on an open-item basis;
usually, postings to revenue and expense accounts are reconciled in this process.
326
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
The pre-requisites are:
•
•
On the master record side, ensure that (a) you have defined the number of the trading
partner in the customer / vendor master data, and (b) a trading partner was assigned
for relevant G/L items during posting, or the number of the trading partner is stored
in the G/L accounts.
On the configuration side, ensure that you have made the required settings under
‘Cross-System Intercompany Reconciliation’ in the IMG.
There are several configuration settings that you need to make under ‘Cross-System
Intercompany Reconciliation’ for preparing the sender as well as the reconciliation systems.
The configuration settings that we discuss, here, in this Section relate mostly to the IMG node
‘Preparations in the Reconciliation System’.
For preparing the reconciliation system for cross-system intercompany reconciliation, you
need to complete the following configuration activities:
•
•
•
•
•
Generate Default Customizing
General Settings
Data Selection and Storage
Data Assignment
Data Reconciliation
Let us, first, look at generating the default customizing.
16.1.1 Generate Default Customizing
When you execute this step, the program generates default settings for most of the activities
under the IMG node ‘Preparations in the Reconciliation System’. It will produce a log listing
out what has been completed. It generates the settings for all companies, for which you have
already maintained the master data when setting up the FI enterprise structure. You just need
to review the generated settings and adjust them, if required.
Before executing the program, however, you need to decide which reconciliation processes
(001 and 003, or 002) you want use for your company.
•
Reconciliation Processes 001 and 003
Typically used to reconcile payables and receivables within the corporate group, both
the processes are for reconciling the open items.
o
Though originally designed to support reconciliation of documents posted to
G/L accounts, you can include customer / vendor open items as well in the
‘Reconciliation Process 001’. Use the process 001 if most of your
Closing
•
327
intercompany documents are posted to G/L accounts or if you need to
reconcile G/L intercompany documents separately from customer / vendor
intercompany documents.
o Though meant for reconciling documents posted to customer / vendor
accounts, you can use the ‘Reconciliation Process 003’ to include G/L open
items as well. Use the process 003 if most of your intercompany documents
are posted to customer / vendor accounts or if you want reconciliation of
customer / vendor intercompany documents separately from G/L open items.
Reconciliation Process 002
This process supports reconciliation of accounts without open item management, and
is typically used to reconcile revenues and expenses resulting from business
transactions within the corporate group.
Due to large volume of data relevant for reconciliation, you may need to create a Special
Purpose Ledger in operative SAP systems from which data is supposed to be extracted for
reconciliation.
Project Dolphin
BESTM Corporate wants to reconcile the payables and receivables within the corporate group.
Accordingly, the project team has suggested to configure the system appropriately. Though
most of the intercompany documents are posted to customer and vendor accounts, BESTM
also wants to include reconciliation of G/L open items.
To generate the default setting for most of the activities under the IMG node ‘Preparations in
the Reconciliation System’:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count
> Cross-System Intercompany Reconciliation > Preparations in the Reconciliation
System > Generate Default Customizing. You may also use Transaction FBICC.
On the resulting ‘Intercompany Reconciliation: Create Default Customizing’ screen,
maintain the required details (Figure 16.2):
• Under ‘General Selection’, enter the value for the ‘Reconciliation Process’
field. Since BESTM primarily wants to reconcile customer / vendor open items
but also wants to include G/L account open items, enter 003 here in this field.
• Under ‘Options for Process 003’ select ‘Include GL Open Items’ check-box;
select a suitable ‘Default Transfer Type’ for data selection. Leave this as blank
to activate the default data transfer type (‘Asynchronous via Direct RFC
Connection’).
328
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 16.2 Creating Default Customizing for Intercompany Reconciliation
The data transfer type ‘Asynchronous via Direct RFC Connection’ is the
default transfer type for data selection. Though it enables a maximum
parallelization within the data selection process, it requires direct RFC
connections to the individual sender systems. Also, this type gives you the
option of scheduling data selections and automatic assignments as two steps
of the same job, which makes sense in an organization with a central
approach where data selection and automatic assignment are run centrally,
and the users only perform the manual reconciliation themselves.
The other data transfer type ‘Synchronous via XI’ was developed to enable
data selection using XI, while keeping the control with the data selection
program. This data transfer type uses transactional RFCs because
asynchronous RFCs are not possible through XI. In order to allow for some
parallelization, the data selection program will start several tasks within the
reconciliation system, each of which then performs a transactional RFC to the
sender system through XI. All of the data is collected and processed further
by the data selection program. Therefore, all information regarding the data
transfer is available in the log of the data selection program. This data
transfer type also gives you the option of scheduling data selections and
automatic assignments as two steps of the same job.
Closing
329
The third data transfer type ‘Asynchronous Triggered from Reconciliation
System’ enables a maximum of parallelization, whether you use direct RFC
connections or XI. However, you will not know when the data transfer is
actually finished, and hence this transfer type is intended to be used only if
you can determine the appropriate start time for automatic assignment and
schedule a separate job accordingly, or if the users start automatic
assignment by themselves.
iii.
iv.
v.
• Select the ‘Test Run’ check-box, and ‘Execute’ the program.
The program brings out the default customizing settings that will be carried out
eventually, during the production run.
View the details, and when satisfied that all the required default settings will be
created by the program for intercompany reconciliation for process 003, go back to
the previous screen, de-select the ‘Test Run’ check-box, and ‘Execute’ again.
The program generates the default customizing settings as shown in Figure 16.3. Pay
attention to the messages with a Yellow triangle:
Figure 16.3 Generate Default Customizing for Intercompany Reconciliation – Results
330
•
•
•
•
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
As you can see, the system lets you know that though the default settings
were created, you need to review them to make sure that the settings are
correct.
There are couple of activities like ‘Create Additional Fields’ and ‘Define
Ledger’ for which the program has not generated the settings, and you may
need to manually complete that, if required.
Also, it notifies that you can take up ‘Enhancements’, if required.
And, when you check and complete the left out customizing activities, you
are informed to ‘Activate the Process’ and ‘Activate Transaction Data Tables’.
With the default Customizing generated, let us move to discuss the configuration activities
under ‘General Settings’.
16.1.2 General Settings
Under general settings, you need to complete the configuration ‘Communication Support’
and a host of other activities including:
•
•
•
•
•
Define Reconciliation Process Attributes
Create Additional Fields
Activate Processes
Activate Transaction Data Tables
Maintain Field Catalogs
Let us first start with the settings for communication support.
16.1.2.1 Communication Support
Under this, you need to configure the following activities:
•
•
•
•
Define Application ID
Define Contact Person Database
Maintain Placeholders for Messages
Maintain Message Templates
In most of the cases, we shall be going ahead with the standard settings. Let us understand
the settings, one by one:
16.1.2.1.1 Define Application ID
Here, you need to define an application ID for intercompany reconciliation. The
communication support components of the system make use of these application IDs to
distinguish between data from different application IDs. SAP’s standard settings is ‘FBRC’ as
Closing
331
the application ID for intercompany reconciliation (Figure 16.4). You will not be able to define
anything new here.
Figure 16.4 Application ID for Intercompany Reconciliation
The next step is to define the contact person database.
16.1.2.1.2 Define Contact Person Database
You need to define at least one ‘contact person database’ for intercompany reconciliation. If
you use separate contact persons, for each individual reconciliation process, then, you have
to define one contact person database, per reconciliation process, and specify the
appropriate contact person database in the Customizing activity ‘Define Reconciliation
Process Attributes’ which we will discuss later in Section 16.1.2.2. The contact information
provided in the ‘contact person database’ helps in the communication between the
accountants involved in the reconciliation process.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Communication Support > Define Contact Person Database, or Transaction
FBRC010.
You will see, on the next screen (Figure 16.5), the default contact person database 003
(‘Contacts’) provided by SAP. If you need more than one, you can define the same here by
clicking on ‘New Entries’. You may click on ‘Maintain Contacts’ button under ‘Navigation’ to
specify the contact persons’ (accountants) communication details.
Figure 16.5 Contact Person Database
In the next step, you will define the placeholders for messages that you will use in the message
templates.
332
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.1.2.1.3 Maintain Placeholders for Messages
There are several placeholders for messages that are delivered by SAP. You can maintain
additional placeholders, if necessary, to be used in ‘message templates’. If you set up
additional placeholders, you have to replace them with the appropriate information.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Communication Support > Maintain Placeholders for Messages. You may also use
Transaction FBRC002.
On the resulting screen, select the ‘Application ID’ (FBRC) and double-click on ‘Placeholders’
on the left-hand side ‘Dialog Structure’. The system brings up the default placeholders, on the
next screen (Figure 16.6). Review them, and define new placeholders, if you need more.
Figure 16.6 Placeholders for Messages
The final step under ‘Communication Support’ is to maintain the message templates.
16.1.2.1.4 Maintain Message Templates
You can use the ‘message templates’ to support communication between the accountants
involved in the reconciliation process. The users can use these templates for interactive
reconciliation. Per message template, you should provide a description and also specify under
which circumstances the template should be used. You should also define a title, for the
template, in order to minimize the effort for the users using the templates. You can import
the existing templates, so that you do not have to start with an empty template. All these
message templates are grouped into ‘Message Template Groups’ that you will be using while
configuring the ‘Reconciliation Process Attributes’, later, in Section 16.1.2.2.
It is possible that you can also use ‘Message Placeholders’ (defined in the previous Section
16.1.2.1.3) within the title of each template. When editing the text of the individual messages,
you can insert / delete the message placeholders using the corresponding functions.
Closing
333
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Communication Support > Maintain Message Templates. You may also use
Transaction FBRC001.
On the resulting screen, select the row containing the ‘Application ID’ (FBRC) and ‘Message
Template Group’ (003) and double-click on ‘Message Template’ on the left-hand side ‘Dialog
Structure’. You will see the ‘Message Template’ overview on the next screen (Figure 16.7),
with the standard templates supplied by SAP. Per template, you can notice that the message
placeholders have been inserted in the ‘Title’ of the message template.
Figure 16.7 Message Template
Now, select a ‘Template’ and click on ‘Text Line’ on the left-hand side ‘Dialog Structure’, to
view the text associated with that template (Figure 16.8). You can edit the text as required.
Figure 16.8 Text Lines for Message Template SAP0000010
This completes our discussion on ‘Communication Settings’. Let us, now, start with the activity
of defining reconciliation process attributes.
334
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.1.2.2 Define Reconciliation Process Attributes
This step is essentially to review the detail attributes of the available reconciliation processes.
As a part of the configuration activity, you may specify which ‘Message Template Group’ and
‘Contact Person Database’ you would like to use for the individual processes. You can either
set up separate templates and contacts for each process or use the same template groups
and contact persons for all processes.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Define Reconciliation Process Attributes. You may also use Transaction FBRC007.
On the resulting screen (Figure 16.9), you can see the attributes for the ‘Reconciliation
Process’ 003. Go with the standard settings with regard to the structure for unassigned /
assigned items, and also for the ‘Message Template Group’ and ‘Contact Person Database’.
Figure 16.9 Attributes for Reconciliation Process 003
The next step is to define the additional fields.
16.1.2.3 Create Additional Fields
You may add the desired additional fields (up to 13) to the tables for the intercompany
reconciliation of G/L accounts. You can use these fields for displaying additional document
information, definition of object groups (Section 16.1.5.3), or as secondary organizational
units (Section 16.1.5.1). Whether a field is added to the line item table and/or the totals table
depends on the level of availability you choose for the new field. The additional fields are
generated into different database tables as shown in Table 16.1.
Closing
Process ID
001
002
003
Line Item Table
FBICRC001A
FBICRC002A
FBICRC003A
335
Totals Table
FBICRC001T
FBICRC002T
FBICRC003T
Table 16:1 Database Tables for Additional Fields in Intercompany Reconciliation
To add additional fields:
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count
> Cross-System Intercompany Reconciliation > Preparations in the Reconciliation
System > General Settings > Create Additional Fields. You may also use Transaction
FBIC006.
On the ‘Display View “Reconciliation Processes”: Overview’ screen, select the
‘Reconciliation Process’ ID (003) and double-click on ‘Customer Defined Fields’ on the
left-hand side ‘Dialog Structure’.
On the resulting screen, click on ‘New Entries’ and maintain the required fields, and
‘Save’ the settings.
We will not be including any additional fields for the intercompany reconciliation for BESTM.
Let us, now, move on to activate the reconciliation processes.
16.1.2.4 Activate Processes
Using this configuration step, you can activate the individual reconciliation processes. It is
important that you have created the Special Purpose Ledger in the system. For intercompany
reconciliation processes 001 and 003, you need to activate tables FBICRC001A and
FBICRC003A respectively, depending on which processes you are using. This step is only
mandatory in the reconciliation system for these processes.
Figure 16.10 Activating Processes for Intercompany Reconciliation
336
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Activate Processes, or Transaction FBIC031, to make the required changes in the
reconciliation system, if it has not been done earlier. If the processes are already active, as
shown in Figure 16.10, you do not need to do anything.
The next step is activating the transaction data tables.
16.1.2.5 Activate Transaction Data Tables
Here, you need to activate the transaction data tables and generate the posting modules to
enable the intercompany reconciliation programs to post data. If you have created any
additional fields, they are not visible in the ‘Field Catalog’ until you have performed this
activity. To activate:
i.
ii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count
> Cross-System Intercompany Reconciliation > Preparations in the Reconciliation
System > General Settings > Activate Transaction Data Tables, or Transaction FBIC004.
On the resulting ‘Activate Transaction Data Tables’ screen, select the ‘Test Run’ checkbox and ‘Execute’ to see the results of this activation on the next screen (Figure
16.11).
Figure 16.11 Activating Data Transaction Tables – Test Run
iii.
If everything is Green, go back to the previous screen, deselect the ‘Test Run’ checkbox and ‘Execute’ again. The system brings up, on the next screen, the ‘Log’ with
Closing
337
details of changes made. You will notice that everything has been generated
successfully (Figure 16.12).
Figure 16.12 Activating Data Transaction Tables – Log from Productive Run
You should execute this function while no postings are being made in any client
of the system.
With this, let us move on to maintain the field catalogs.
338
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.1.2.6 Maintain Field Catalogs
Use this step to assign predefined roles to the single fields of the data tables. Note that the
roles for the standard fields are predefined in the system and you cannot change them.
However, if you have created additional fields (Section 16.1.2.3), you can assign the roles
depending on your requirements.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > General
Settings > Maintain Field Catalogs, or Transaction FBRC008.
On the resulting screen, select the ‘Reconciliation Process’ (003) and double-click on ‘Field
Catalog’ on the left-hand side ‘Dialog Structure’. On the next screen, you will see the default
settings for the standard fields (Figure 16.13). Click on ‘New Entries’ to add any new field that
you would have defined and select the appropriate ‘Role’ for that.
Figure 16.13 Maintaining Field Catalogs
The default role for all the fields is ‘Subassignment’. There is no special logic connected with
this role, and hence the information, contained in a field with ‘Subassignment’ as the role, is
simply forwarded and displayed.
For each reconciliation process, you must assign the following roles to exactly one field:
•
•
•
•
•
Leading Organizational Unit
Leading Partner Unit
Primary Currency Key
Primary Amount
Reference Number
Closing
339
You can also assign the following roles to one field:
•
•
Secondary Organizational Unit
Secondary Partner Unit
However, you can also assign the role ‘Status Field’ to as many fields as required. But the fields
with ‘Status Role’ must of type NUMC3. You should assign the ‘Reference Number’ role to a
field of type CHAR18, as the reconciliation services determine reference numbers
automatically for data records that are assigned to each other.
Since we have not defined any additional fields, we are not adding anything here for BESTM.
This completes our configuration of ‘General Settings’. Let us move on to discuss the settings
relating to ‘Data Selection and Storage’.
16.1.3 Data Selection and Storage
The following are the configuration steps under this group of settings:
•
•
•
•
Define Reconciliation Process Detail Attributes
Define Ledger
Define Enhancements
Companies to be Reconciled
The first configuration step is to define the reconciliation process detail attributes.
16.1.3.1 Define Reconciliation Process Detail Attributes
We have already, vide Section 16.1.2.2, defined some of the attributes for reconciliation
process 003. Here, you can define some detail attributes for the reconciliation process.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Selection and Storage > Define Reconciliation Process Detail Attributes, or Transaction
FBICO10.
On the resulting screen (Figure 16.9), you will see the reconciliation process detail attributes,
for the reconciliation process 003. You may review the default settings, and change, if
required (for example, the ‘Fiscal Year Variant’). You will notice that the ‘Group chrt/acts’ field
is not editable, because the data selection process tries to determine the group account
number in the sender system. What you are looking at Figure 16.14 is the reconciliation
system. You need to specify which group chart of accounts should be assigned to the
operative charts of accounts in the sender systems.
340
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 16.14 Reconciliation Process Detail Attributes
The ‘Selection Strategy’ field under ‘Data Selection’ data block controls the number of parallel
RFC calls to sender systems, during data selection. If you choose ‘Minimize number of RFC
calls’ as the selection strategy, then, the data selection program will select all relevant
documents from the sender systems using one RFC call per sender system. When you select
Closing
341
the ‘Selection Strategy Is Default Only’ check-box, you can specify (for each company)
whether the data of that company should be selected in the collective RFC call or in a separate
one.
The next step is to define ledger.
16.1.3.2 Define Ledger
The ‘intercompany reconciliation’ uses Special Purpose Ledger functionality for storing data
that is to be reconciled. Though, from a technical point of view, it is not necessary to actually
create a Special Purpose Ledger only for data storage, specify a ledger name to make use of
the additional functions of Special Purpose Ledger (like, reporting or extraction of data to
BW), at a later point in time.
You can create and maintain a Special Purpose Ledger for facilitating inter-company
reconciliation in the system by following the menu path: SAP Customizing Implementation
Guide > Financial Accounting > Accounts Receivable and Accounts Payable > Business
Transactions > Closing > Count > Cross-System Intercompany Reconciliation > Preparations in
the Reconciliation System > Data Selection and Storage > Define Ledger.
On the ‘Select Activity’ pop-up screen, double-click on ‘Create Ledger’ and maintain the
required details, and ‘Save’ when completed. The ledger must have the property settings as
in Table 16.2. All other configuration switches should be set to ‘No’.
Property
Summary table
Ledger postings allowed
Write lines items
Transaction currency
Value
FBICRC003T
Yes
Yes
Yes
Table 16:2 Properties for Special Purpose Ledger used in Intercompany Reconciliation
Do not assign any companies / activities to this ledger.
With this, let us move on to the next activity of defining enhancements
16.1.3.3 Define Enhancements
You can use Business Add-In (BAdI) for intercompany reconciliation of customer/vendor open
Items. This BAdI provides for adding fields to be selected from database tables, add
information to data records selected from database tables, add or delete data records,
provide mapping for company IDs and supply data using non-standard logic, in document
selection.
342
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Selection and Storage > Define Enhancements.
The next step is to set up the companies that need to be reconciled.
16.1.3.4 Companies to be Reconciled
Here, specify for each company to be reconciled which data is supposed to be selected for
intercompany reconciliation and where from the data is supposed to be selected. You can set
up multiple data sources for each company, using a sequential number.
Figure 16.15 Company Attributes for Reconciliation
Closing
343
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Selection and Storage > Companies to be Reconciled, or Transaction FBIC032.
On the resulting screen click on ‘New Entries’ to set up the settings, if you do not see your
company already set up with the standard settings. You can also change the defaults (Figure
16.15): enter the RFC destination for interactive functions and data selection of the ‘Source
System’, and make the appropriate settings for data transfer. Configure the settings for other
companies (B2000 and B3000) of BESTM as well.
With this, let us now look at the settings under ‘data assignment’.
16.1.4 Data Assignment
Under this configuration group, you need to complete the following steps:
•
•
Maintain Number Range for Group Reference Numbers
Define Rules for Document Assignments
Let us start with the first configuration step of configuring the number ranges.
16.1.4.1 Maintain Number Range for Group Reference Numbers
Set up the number range ‘10’ for the ‘Group Reference Numbers’. It is recommended to define
a large number range with long validity (say, 9999 years).
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Assignment > Maintain Number Range for Group Reference Numbers, or Transaction
FBICRC_SNRO.
On the resulting screen, select 003 for ‘Reconciliation’ and create a new number range by
clicking on ‘Intervals’. The system brings up the default settings on the next screen, with the
number range number (‘No’) as 10 and ‘Year’ as 9999 as shown in Figure 16.16.
Figure 16.16 Number Range for Group Reference Numbers
The next activity is to define the rules for document assignments.
344
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.1.4.2 Define Rules for Document Assignments
Here, you can define the rules for document assignments, and can specify that the rules are
to be executed automatically: that is, the system assigns the data records automatically,
based on these rules, when the appropriate program is started:
•
•
If you set up several rules for automatic assignment, the system processes these rules
sequentially in the same order as they are shown in the Customizing view. For
example, if you have two rules 100 and 200 with the sequence number 100 in each
case, then, the system processes the data records first by using rule 100. The system
excludes the data records assigned to a document group, as a result of processing
using this rule 100, for further processing and therefore these records will not be
analysed by rule 200.
If you have multiple conditions within one rule, these conditions are linked with a
logical AND; that is, all conditions must be met to have documents assigned to each
other.
You can use the rules that are not to be used automatically, for manual reconciliation of
data records
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Assignment > Define Rules for Document Assignments:
i.
ii.
On the resulting screen, select 003 as the ‘Reconciliation Process’ and double-click on
‘Rules’ on the left-hand side ‘Dialog Structure’.
The system brings up the ‘Change View “Rules”: Overview’ screen (Figure 16.17). You
will see the default rules with their description and also the settings as to whether
that rule is to be used for assignment program run etc.
Figure 16.17 Rules for Document Assignment – Overview Screen
Closing
iii.
345
Now, select a ‘Rule’ and double-click on the ‘Rule Definition’ on the left-hand side
‘Dialog Structure’. The system brings up the rule definition overview on the next
screen (Figure 16.18).
Figure 16.18 Rules for Document Assignment – Rule Definition
With this, we are ready to discuss the settings that you need to make under the IMG node,
‘Data Reconciliation’.
16.1.5 Data Reconciliation
There are a couple of configuration steps that you need to complete, for configuring the
settings for data reconciliation. They are:
•
•
•
•
•
Set Up Reconciliation Display
Define Sets
Set Up Object Groups and Subgroups
Define Possible Status for Documents
Define Enhancements
Let us start with the first step of setting up the reconciliation display.
16.1.5.1 Set Up Reconciliation Display
Here, in this step, you can specify - for each reconciliation process - whether you want to use
secondary organizational units in the hierarchy display. However, to use secondary
hierarchical units in reconciliation display, you should have defined the additional fields,
activated the data tables and maintained the field catalog including those additional fields.
Since we have not defined any additional field, we will not be able to set up the secondary
organizational units for hierarchy display, and we need to go ahead with the standard settings.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Reconciliation > Set Up Reconciliation Display, or Transaction FBRC003.
346
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On the resulting screen, select 003 as the ‘Reconciliation Process’ and double-click on
‘Hierarchy Setup’ on the left-hand side ‘Dialog Structure’. The system brings up the hierarchy
setup overview screen, for the ‘Reconciliation Process’ 003 (Figure 16.19). You will notice that
you will not be able to choose the second option of ‘Use Primary and Secondary OrgUnits and
Partner Units in Hierarchy Display’ as there has not been any additional field defined for
BESTM (refer Section 16.1.2.3).
Figure 16.19 Setting up of Reconciliation Display
With this, we are now ready to define the sets.
16.1.5.2 Define Sets
Here, you can define the Sets that are to be used in setting up of the reconciliation display. As
the ‘Sets’ are just a technical definition for characteristic values, it is sufficient to specify a set
ID, a data element, and the values which are supposed to be contained in the Set. The
additional information like text table and text field is only necessary, if you want to see
account descriptions during Set maintenance. The standard settings include three Set IDs:
1000, 2000 and 3000.
The standard Sets are normally sufficient for reconciliation processes 001 and 003.
However, to use reconciliation process 002, you may need to create more specific sets.
To view the standard Sets / create new Sets, Use the menu path: SAP Customizing
Implementation Guide > Financial Accounting > Accounts Receivable and Accounts Payable >
Business Transactions > Closing > Count > Cross-System Intercompany Reconciliation >
Preparations in the Reconciliation System > Data Reconciliation > Define Sets, or Transaction
FBRC004:
i.
ii.
On the resulting screen, select FBRC as the ‘Application ID’ and double-click on ‘Sets’
on the left-hand side ‘Dialog Structure’.
The system brings up the ‘Change View “Sets”: Overview’ screen (Figure 16.20). You
will see the default Sets with their description and also the standard settings.
Closing
347
Figure 16.20 Sets Overview
Now, select a ‘Set ID’ and double-click on ‘Sets: Single Entries’ on the left-hand-side ‘Dialog
Structure’ to view the overview of settings for that selected Set (2000), as shown in Figure
16.21. Here in this step, you can specify the actual values that are supposed to be contained
in a Set. Each Set can have several entries. You can combine individual entries with each other
with a logical operator ‘OR’.
Figure 16.21 Sets: Single Entries – Overview
With this, let us move on to set up the object groups for subgroups.
16.1.5.3 Set Up Object Groups and Subgroups
Set up the object groups and subgroups that are to be used for interactive reconciliation for
each process. The object groups are the third level of the navigation hierarchy. When you set
up several object groups (each identified by an ID), the system displays them in the order of
the object group ID. The system also brings up the description in the navigation hierarchy in
the reconciliation screen. In the object subgroups, specify the Sets that are to be included in
the display. This determines the documents that are shown when you choose an object group
in the navigation tree. For each subgroup entry, specify a Set both for the company and for
the partner data records. The object groups act like a filter for the data to be reconciled.
348
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Reconciliation > Set Up Object Groups and Subgroups, or Transaction FBRC009:
i.
ii.
On the resulting screen, select 003 as the ‘Reconciliation Process’ and double-click on
‘Object Groups’ on the left-hand side ‘Dialog Structure’.
The system brings up the ‘Change View “Object Groups”: Overview’ screen (Figure
16.22). You will see the default ‘Object Groups’ with their description.
Figure 16.22 Overview of Object Groups
Now, select an ‘Object Group’ and double-click on ‘Object Subgroup’ on the left-hand side
‘Dialog Structure’. The system brings up the object subgroup overview with the associated
standard settings, for each of the subgroups. You can notice the ‘Set’ ID, for each of the
subgroups in the ‘Company Set’ and ‘Partner Set’ fields (Figure 16.23).
Figure 16.23 Overview of Object Subgroups
The next step is to define the possible status for documents.
Closing
349
16.1.5.4 Define Possible Status for Documents
Here, you define possible status for documents. SAP delivers the fields ‘Communication
Status’ and ‘Processing Status’ as the standard functionality. These fields help users to
remember which actions have already been taken regarding the individual documents.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Reconciliation > Define Possible Status for Documents, or Transaction FBRC006:
i.
ii.
On the resulting screen, select 003 as the ‘Reconciliation Process’ and double-click on
‘Status Fields’ on the left-hand side ‘Dialog Structure’.
The system brings up the ‘Change View “Status Fields”: Overview’ screen (Figure
16.24). You will see the default ‘Status Fields’ with their description.
Figure 16.24 Overview of Status Fields
iii.
Now, select a ‘Status Field’ and double-click on ‘Status Icons and Values’ on the lefthand side ‘Dialog Structure’. You will see the status icons and the values for the
selected ‘Status Field’ (PSAT, for example) in Figure 16.25.
Figure 16.25 Status Icons and Values
350
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
You can go ahead with the standard settings. Or, if required, you may define the new status
values you would like to use within ‘Intercompany Reconciliation’ and assign a description
and an icon to each value. The icon will be displayed during interactive reconciliation and the
description is available as a tooltip, for the displayed icon.
You will not be able to define the possible status for documents unless you have set the
role ‘Status Field’ to at least one of the fields, while maintaining the field catalog.
The last configuration step under ‘Data Reconciliation’ is to define the enhancements.
16.1.5.5 Define Enhancements
You can use the BAdI ‘FB_RC_PRESENTATION’ for changing template-based messages,
checking whether assignment is correct, checking whether assignment may be deleted,
deactivating standard functions of user interface, adding functions to the user interface and
processing for added functions, in manual document reconciliation.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count > CrossSystem Intercompany Reconciliation > Preparations in the Reconciliation System > Data
Reconciliation > Define Enhancements, or Transaction FBRC006:
The system brings up the BAdI ‘FB_RC_PRESENTATION’ which you need to activate (Figure
16.26).
Figure 16.26 Activate BAdI ‘FB_RC_PRESENTATION’
This completes our discussion on settings relating to data reconciliation. This also completes
our discussion on preparing the reconciliation system in configuring intercompany
reconciliation. Let us, now, look at the settings that you need to make for balance
confirmation.
Closing
351
16.1.6 Balance Confirmation Correspondence
You can make settings relating to the reply address for balance confirmation besides
specifying the selection criteria for balance confirmation, here. Let us start with the definition
of reply address, per company code, for handling balance confirmations.
16.1.6.1 Define Reply Addresses for Balance Confirmation
Define the address to which you want your customers or vendors to send their balance
confirmation reply. Normally, this address will be different from the company code address.
You can define several addresses, for every company code. Once defined, you can specify the
required ID, for every run of the balance confirmation.
You may use the menu path: SAP Customizing Implementation Guide > Financial Accounting
> Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count >
Balance Confirmation Correspondence > Define Reply Addresses for Balance Confirmation.
On the resulting screen, click on ‘New Entries’ and enter the company code (‘CoCd’) and
‘Address ID’ on the next screen (Figure 16.27). When you ‘save’, the system will prompt you
to provide the address details for the new address ID. You can define more than one such
address ID, per company code.
Figure 16.27 Address Data for Reply Addresses for Balance Confirmation
The next step is to add more selection criteria fields, for balance confirmation.
16.1.6.2 Specify Selection Criteria for Balance Confirmation
Here, you can choose the additional selection criteria which you may need for the balance
confirmation (for the report SAPF130D), besides the standard ones.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Count >
Balance Confirmation Correspondence > Specify Selection Criteria for Balance Confirmation
or Transaction FSSP:
i.
ii.
On the resulting screen, enter the ‘Account Type’ and press ‘Enter’ to continue.
On the next ‘Change Selection Criteria for Balance Confirmation’ screen, the system
brings up the list of fields from which you can select the additional fields, to add to
the existing selection criteria for the report.
352
iii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
On this screen, place the cursor on the field which you want to add and click on
‘Select’ button or press F9 to add. Repeat to add more fields, and ‘Save’ when
completed (Figure 16.28).
Figure 16.28 Additional Selection Criterial Fields for Balance Confirmation
When you run the report SAPF130D (Transaction F.17), you can see that the two fields
(Customer Account Group - NA1KTOKD, and Customer Classification - NA1KUKLA), which we
just included, have now been added to the selection criteria screen (Figure 16.29).
Figure 16.29 Additional Selection Criteria Fields for Balance Confirmation (Transaction F.17)
This completes our discussion on ‘Count’ as a part of closing. We are, now, ready to discuss
the settings for the next closing operation, ‘Valuate’.
Closing
353
16.2 Valuate
Under valuate, you need to make settings for the following:
•
•
•
Foreign Currency Valuation
Reserve for Bad Debt
Valuations
Let us start with the foreign currency valuation.
16.2.1 Foreign Currency Valuation
To complete creation of financial statements, you need to perform foreign currency valuation.
For valuating in foreign currency, you have the option of (a) valuating in local currency
(company code currency) or a parallel currency (say, group currency), (b) using
different valuation methods like ‘lowest value principle’ and (c) automatic currency
translation (in accordance with FASB 52 of US GAAP) when translating additional currencies
from local currency.
The Financial Accounting Standards Board (FASB) issued Statement 52, Foreign Currency
Solution, in December 1981. Also known as Accounting Standard Codification 830, FAS 52
provides guidance on handling transactions and reporting that involves foreign currencies.
FAS 52 covers a lot of ground, including guidance on implementing currency rates under
ambiguous conditions.
More specifically, this Statement replaces FASB Statement No. 8 ('Accounting for the
Translation of Foreign Currency Transactions and Foreign Currency Financial Statements'),
and revises the existing accounting and reporting requirements for translation of foreign
currency transactions and foreign currency financial statements. It presents standards for
foreign currency translation that are designed to (1) provide information that is generally
compatible with the expected economic effects of a rate change on an enterprise's cash flows
and equity and (2) reflect in consolidated statements of the financial results and relationships,
as measured in the primary currency in which each entity conducts its business.
The standard SAP supports the following functions towards foreign currency valuation
(program FAGL_FCV):
1) Valuating Foreign Currency Balance Sheet Accounts: The foreign currency B/S
accounts are the G/L accounts that you manage in foreign currency. The balances of
G/L accounts that are not managed on an open item basis are valuated in foreign
currency.
354
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
2) Valuation of Open Items in Foreign Currencies: The items that are open on a key date
are valuated in foreign currency.
3) Saving the exchange rate differences determined from the valuation per document.
4) Posting account assignments in valuation documents: In case you are using document
splitting functionality in SAP G/L Accounting, then, the valuation documents are
posted with the account assignments that you have defined as the document splitting
characteristics. In the case of balance valuation, you can define additional account
assignment characteristics which get always updated (even if you do not use
document splitting). You can define the additional account assignment
characteristics, for foreign currency valuation, using the menu path SAP Customizing
Implementation Guide > Financial Accounting > General Ledger Accounting > Periodic
Processing > Valuate > Foreign Currency Valuation > Activate Additional Fields for
Foreign Currency Valuation or Transaction FINS_FCT. Refer the subsequent Section
16.2.1.7, for more details.
5) Performing the required adjustment postings.
You need to carry out the following configuration activities for performing foreign currency
valuation. You will find these IMG activities for the foreign currency valuation in Customizing
for General Ledger Accounting:
•
•
•
•
•
•
•
•
Define Valuation Methods
Define Valuation Areas
Check Assignment of Accounting Principle to Ledger Group
Assign Valuation Areas and Accounting Principles
Activate Delta Logic
Prepare Automatic Postings for Foreign Currency Valuation
Activate Additional Fields for Foreign Currency Valuation
Define Account Determination for Currency Translation
Project Dolphin
BESTM Corporate wants to have a single valuation method that will be used worldwide.
However, there needs to be different valuation areas to take care of the different valuation
needs and requirements of each of the accounting principles. Besides, the corporate also
wants to make use of the ‘delta logic’ functionality in foreign currency valuation to ensure
that the system does not execute any reversal postings for the valuation postings in the
subsequent period. Besides the default account assignment fields for foreign currency
valuation, BESTM wants to include ‘Functional Area’ and ‘Cost Center’ as the additional
account assignments to have more flexibility.
Let us start with the definition of valuation methods.
Closing
355
16.2.1.1 Define Valuation Methods
The ‘valuation method’ determines how foreign currency valuation is performed, grouping
specifications that you need for the balance valuation and line item valuation, during closing.
You will be able to use the valuation method across multiple charts of accounts.
Per valuation method, you specify (a) the valuation procedure to be used (for example, lowest
value principle), (b) how the exchange rate differences determined should be posted (for
example, which document type should be used) and (c) the basis on which the exchange rate
should be determined (for example, which exchange rate type should be used).
To define a valuation method:
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Valuate > Define Valuation
Methods.
On the resulting screen, click on ‘New Entries’ to define a new valuation method
(Figure 16.30):
Figure 16.30 Valuation Method
•
•
Enter an identifier for the new valuation method (say, BEV1).
Under the ‘Valuation Procedure’, select the appropriate valuation principle
(say, ‘Always Valuate’).
356
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
•
iii.
Usually, the valuation results are posted in a summarized form. However,
select ‘Post per Line Item’ check-box, if required, to generate a line item for
each valuated item in the valuation posting as well as in the adjustment
account, such as the expense or revenue account.
• To evaluate a group of accounts, you need to select the appropriate checkboxes. This has the effect that balances are created for several accounts.
Customer and vendor accounts are balanced and grouped according to the
group to which they belong. G/L accounts are balanced according to the
valuation group. During further processing, the group is then viewed as a
whole; for example, during foreign currency valuation the group balance is
used to determine the exchange rate type. You need to enter the group key
in the respective master record under ‘Group’.
• If you select ‘Extract’ check-box, then, you need provide a file name for the
valuation run. The system stores a series of information in this file for every
valuated line item. The format is determined by the F100FILE structure. You
can use this extract for downstream non-SAP applications.
• Enter a ‘Document Type’.
• Under ‘Exchange Rate Determination’, maintain the exchange rate type (say,
M) for both debit and credit balance, and select ‘Determine Exch. Rate Type
from Acct Bal.’ radio-button.
‘Save’ the settings and maintain the ‘Time-Dependent Attributes’ for the newly
created valuation method BEV1 (Figure 16.30).
With the definition of valuation method completed, the next step is to define the valuation
areas.
16.2.1.2 Valuation Areas
You can use the ‘valuation areas’ to report different valuation approaches and post to
different accounts. You can save the valuation result, separately for each document item and
use it for other closing operations (such as sorted lists).
To define valuation areas for your closing operations:
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Valuate > Define Valuation Areas.
On the resulting screen, click on ‘New Entries’, and:
Closing
357
Figure 16.31 Valuation Areas
•
iii.
Enter a 2-character identifier for the new valuation area in the ‘Valuation’
field (say, B1)
• Enter the ‘Valuation Method’ (BEV1).
• You can select up to three currency types in the ‘Crcy type’ fields.
• Enter the appropriate financial statement version (‘FS vers’) and enter a
suitable explanation in the ‘Long Txt’.
• ‘Save’, when completed
Repeat the steps and define all the other valuation areas for BESTM group (Figure
16.31).
The next step is to check the assignment of accounting principle to ledger group.
16.2.1.3 Check Assignment of Accounting Principle to Ledger Group
Using this step, you can check the assignment of accounting principle to ledger group which
you would have already completed, while configuring parallel accounting. If the assignment
was not done earlier, you can use this step to completed the assignment, now.
Assuming that you have already created the required ledger groups (G1) earlier while
configuring the activity ‘Define Settings for Ledgers and Currency Types’, let us now assign the
appropriate accounting principle to this ledger group:
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > General
Ledger Accounting > Periodic Processing > Valuate > Check Assignment of Accounting
Principle to Ledger Group to check or define the assignments.
i.
ii.
iii.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Financial Accounting Global Settings > Ledgers > Parallel Accounting > Assign
Accounting Principle to Ledger Groups.
On the ‘Change View “Assignment of Accounting Principle to Target Ledger Group”:
Overview, click on ‘New Entries’ and maintain the details on the next screen: Enter
the ‘Accounting Principle’ (IAUS), select the ‘Target Ledger Group’ (G1).
‘Save’ and you have now created the required accounting principles (Figure 16.32).
358
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 16.32 Assigning Accounting Principle to Ledger Group
Let us move on to assign the valuation areas to the accounting principles, in the next step.
16.2.1.4 Assign Valuation Areas and Accounting Principles
Assign the desired accounting principles to your valuation areas. As you can use the valuation
area for the reclassification or sorted list of payables and receivables and for foreign currency
valuation, you can use the valuation area to apply in these reports for the different valuation
requirements of the accounting principles.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > General
Ledger Accounting > Periodic Processing > Valuate > Assign Valuation Areas and Accounting
Principles. On the resulting screen, make the required assignments (Figure 16.33).
Figure 16.33 Assigning Valuation Areas to Accounting Principle
The next step is to activate the delta logic.
16.2.1.5 Activate Delta Logic
The ‘delta logic’ ensures that the system does not execute any reversal postings, for the
valuation postings in the following (or subsequent) period. You can activate the delta logic
separately, per valuation area. When activating, you can determine whether you want to use
the clearing date as the date for the reversal, by setting that indicator in the configuration.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > General
Ledger Accounting > Periodic Processing > Valuate > Activate Delta Logic (Figure 16.34):
Closing
359
Figure 16.34 Activating Delta Logic for Valuation Areas
•
Select ‘Delta Logic’ check-box to make sure that the system does not execute any
reversal postings for the valuation postings in the following period.
The ‘delta logic’ is a posting logic for consolidation group-dependent entries. In
the business consolidation, all documents and totals records that are posted at a
lower level in the hierarchy of consolidation groups also apply to the higher levels of
the hierarchy. At the higher levels, the system merely posts delta entries. The ‘delta’
is the difference between (a) the (hypothetical) total document that would normally
be posted for the given consolidation group, if no lower-level groups existed, and (b)
the (actual) documents posted for the lower-level groups.
•
•
If you select ‘Reversal Date After Settlement Date’ check-box, the system uses the
clearing date of the valuated item for the reversal postings. This may, at time, pose
problems since the program cannot ensure that the period is open. If the period is
closed, an error message will be output and the posting will not be made; it will be
stored in a batch-input session, which will, then, need to be to be corrected before
you can make the postings again.
When you select the ‘Monthly reversal’ check-box, you will be able to specify whether
the reversal of valuation postings is possible in the ‘Foreign Currency Valuation’
report in conjunction with the delta logic.
With this, we are now ready to prepare the system for automatic postings of foreign currency
valuation.
16.2.1.6 Prepare Automatic Postings for Foreign Currency Valuation
Here, in this step, you define the G/L accounts to which you want the system to automatically
post the exchange rate differences, when valuating open items and foreign currency balances.
You can use the currency type to control account determination during open item valuation
and exchange rate difference posting. You can, for example, post gains in local currency and
gains in group currency, to separate accounts. When valuating open items, the system posts
360
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
to a B/S adjustment account and to an account for exchange rate differences (gain/loss) that
occur during the valuation. Do not change the SAP-defined posting keys for the automatic
postings.
The valuation of foreign currency balances requires a special key that is assigned to the
gain and loss G/L accounts for posting any exchange rate differences that occur during
valuation. You can freely define this key. You then enter that in the master records of the
accounts that you want to valuate. To post the differences that are determined from a group
of G/L accounts to the same gain or loss accounts, enter the same key for all these G/L
accounts.
To configure the settings for automatic postings:
i.
ii.
iii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Valuate > Foreign Currency
Valuation > Prepare Automatic Postings for Foreign Currency Valuation. You may also
use Transaction OBA1.
You will see a list of automatic posting procedures for posting exchange rate
differences, on the resulting screen. We have already defined the required G/L
accounts to take care of exchange rate differences arising out of open item clearing
(procedure KDF), in an earlier Section 6.1.5 of Chapter 6. Let us, now, configure the
accounts for the other required procedures (like KDB and KDW).
Double-click the appropriate row (say, KDB); maintain the chart of accounts (say,
BEUS), and ‘Continue’.
Figure 16.35 Accounts for Automatic Postings of Foreign Currency Revaluation
iv.
Enter the appropriate G/L accounts in ‘Expense account’ and ‘E/R gains acct’. The
‘Expense account’ is for posting the exchange rate losses; any loss resulting from
changes in exchange rates is posted to this account. Similarly, ‘E/R gains acct’ will be
used to record the gains from changes in exchange rates (Figure 16.35).
Closing
v.
vi.
vii.
361
For the valuation of foreign currency balances, the system uses the ‘Exchange rate
difference key’ to find the accounts for gains and losses from the valuation. You
specify which G/L accounts are to be posted to under which exchange rate difference
key in the system. If you do not want to differentiate the accounts per key, leave the
‘Exchange rate difference key’ field as blank.
To view the associated posting keys, click on ‘Posting Key’; the standard keys are, 40
for debit and 50 for credit; and, do not change these default keys.
Repeat defining the G/L accounts for the other procedures (or transactions) as well,
and ‘Save’ the settings when completed.
Let us, now, look at activating the additional field for foreign currency valuation.
16.2.1.7 Activate Additional Fields for Foreign Currency Valuation
Using this configuration step, you can deactivate some of the existing account assignment
fields or activate additional account assignment fields that you want the system to include in
the foreign currency valuation. The additional fields that you activate will be included, in all
the advanced closing activities and will also be posted to. In the case of deactivation, you
cannot deactivate all the active fields as some of them are needed for internal valuation.
Figure 16.36 Activating Additional Fields for Foreign Currency Valuation
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > General
Ledger Accounting > Periodic Processing > Valuate > Foreign Currency Valuation > Activate
Additional Fields for Foreign Currency Valuation. You may also use Transaction FINS_FCT. On
the ensuing screen, change ‘Display’ to ‘Change’ and select ‘Functional Area’ and ‘Cost Center’
as additional account assignments for BESTM (Figure 16.36).
A high number of activated fields may negatively impact the speed of (currency
valuation) processes in the system.
The next step is to define G/L accounts for currency translation.
362
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.2.1.8 Define Account Determination for Currency Translation
Per financial statement version and valuation area, you can define appropriate account
determination for currency translation for the various financial statement items, in this step.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting > General
Ledger Accounting > Periodic Processing > Valuate > Foreign Currency Valuation > Define
Account Determination for Currency Translation.
Enter the chart of accounts, valuation area and financial statement version on the pop-up
screen, when you enter the Transaction. On continuing, on the next screen, click on ‘New
Entries’ and maintain the financial statement item, (say, 09) in ‘FS item field, enter the
exchange rate type (say, M) for debit/credit exchange rate type, enter the B/S adjustment
account and G/L accounts for value loss and value gain in the appropriate fields, and ‘Save’
the details.
This completes our discussion on configuring the system for foreign currency valuation. Let
us discuss the preparations that you need to make for posting of provisions for doubtful
receivables.
16.2.2 Reserve for Bad Debt / Writing Off of Bad Debt
You can create a bad debt reserve, or write the debt off, using ‘individual value adjustment’,
if you feel that a particular receivable is doubtful or if it is unlikely you will ever recover it. You
can also post a flat-rate value adjustment, using ‘flat-rate value adjustment’, on the balance
sheet key date, for the general risk of not recovering receivables.
Let us first understand the individual value adjustment.
16.2.2.1 Individual Value Adjustment
You can post an individual value adjustment for doubtful receivables, using a special G/L
transaction. You do this by posting the doubtful receivable to the customer account and to an
expense account.
The use of a special G/L transaction helps you as under:
•
•
The A/R remains on the customer account and on the receivables account. You
manage the individual value adjustment, separately from the receivables themselves
on the customer account. This way, you can identify the individual value adjustments
posted to any customer account at any time.
In the G/L, you post the doubtful receivable to a separate reconciliation account. You
do not need to transfer the doubtful receivable when creating the financial
statements.
Closing
363
However, for you to be able to post individual value adjustments as a special G/L transaction,
you should meet the following prerequisites:
•
•
The transaction that needs to be adjusted should contain the special G/L indicator.
For this, enter the indicator (E) when posting the individual value adjustment. The
system, now, determines (using this indicator) the alternative reconciliation account.
The special G/L indicator E is the standard default defined in the system.
To be able to post the individual value adjustment to an alternative reconciliation
account, you must first create this account and the account number in the system, as
shown in Figure 16.37. To define the account number, use the menu path: SAP
Customizing Implementation Guide > Financial Accounting > Accounts Receivable and
Accounts Payable > Business Transactions > Postings with Alternative Reconciliation
Account > Other Special G/L Transactions > Define Alternative Reconciliation Account
for Customers (Transaction OBXY).
Figure 16.37 Alternative Reconciliation Account for Individual Value Adjustment
•
You also need to define an account to which you can post the expenses from the
individual value adjustment. This account must be tax-relevant, if you want to post
the expense and revenue for the individual value adjustment, as well as sales tax to
this account.
With this, let us move on to discuss the flat-rate value adjustment.
16.2.2.2 Flat-Rate Valuation Adjustment
You can carry out flat-rate value adjustments using a simple and direct G/L account posting:
post the amount to an appropriate expense account and to a balance sheet account. You can,
then, display this specific balance sheet account under the same balance sheet item as your
normal accounts receivable.
364
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
To carry out the G/L account posting, use the SAP Easy Access Menu: SAP Menu > Accounting
> Financial Accounting > General Ledger > Document Entry > Enter G/L Account Document, or
Transaction FB50.
The system valuates the open customer items, during financial statement preparation.
Besides the foreign currency valuation (refer Section 16.2.1), you can also calculate a discount
for long-term receivables and a flat-rate individual value adjustment for unsecured or overdue
receivables. You can then use the adjusted receivables at a later time as the basis for the
sorted list and regrouping of outstanding receivables. After the valuation processing, you can
either reject the values created in the proposal run or transfer them to G/L accounting. During
the transfer, the system creates the posting in SAP G/L Accounting and saves the valuations
for each line item. You can, therefore, also display the valuation in the document display.
Valuations are only possible for customer items. You cannot valuate vendor and G/L
accounts.
You will see the necessary settings for Customizing the flat-rate individual value adjustments
and discounts, in the next Section.
16.2.3 Valuations
Here, you make the settings for flat-rate individual value adjustment and for discounting of
receivables. The following are the settings that you need to make, as a part of ‘valuate’ closing
operation:
•
•
•
•
•
Define Value Adjustment Key
Define Interest Calculation Types
Define Accounts
Determine Base Value
Determine Values for Line Item Display
Let us start with the first step of defining value adjustment key.
16.2.3.1 Define Value Adjustment Key
The value adjustment key determines (a) whether you want to execute a valuation for a
different valuation area, (b) the percentage of the provision for the value adjustment
calculation and (c) whether the calculation is to be based on country and due date. Using this
configuration step, you can define a value adjustment key based on country or due date. Once
defined, you then enter the value adjustment key in the customer master record.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Valuate >
Closing
365
Valuations > Define Value Adjustment Key. On the resulting screen, click on ‘New Entries’ and
maintain the required settings on the next screen (Figure 16.38):
Figure 16.38 Value Adjustment Keys
i.
ii.
iii.
iv.
v.
Enter the value adjustment key (‘Value Adj. Key’), and the type of valuation
(‘Valuation’). If you leave the ‘Valuation’ field as blank, then it is valid for all the
valuations; if you fill in a particular valuation (say, B2 – For IAS/US GAAP) that you
have defined earlier, then, the valuation adjustment entry is valid only for that GAAP.
Enter the country (‘Ctr’), and the ‘Days’ of overdue which is the difference between
key date and the due date for net payment. Based on the overdue days, you may have
a graduated scale of debit interest which you will enter in ‘Debit Int. Rate’ field.
Select ‘Valuate Manually’ check-box, if you want to determine the provision for
unsecured receivables manually; in that case, you do not need to enter the
percentage interest rate. Though the system selects the open item during valuation,
the interest is not calculated automatically.
If you do not want a standard valuation adjustment, but want to use some external
valuation, then enter that detail in ‘Ext. Valuation’. Select the appropriate posting
type (‘PT’) for the adjustment posting. Let this be ‘Net amount’.
Repeat and define all the value adjustment keys for different overdue duration and
‘Save’ the settings.
With this, we are ready to discuss the next step of defining interest calculation types.
16.2.3.2 Define Interest Calculation Types
We have already defined the interest calculation types both for item (arrears) interest and
account balance interest calculation, vide Section 15.3.1 of Chapter 15.
We can now move on to define the accounts for valuation adjustments.
366
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.2.3.3 Define Accounts
Here, in this step, you will define an adjustment account and a target account, per
reconciliation account, for the transactions ‘Receivables discounting’ (B02) and ‘Flat-rate
individual value adjustment’ (B03). The system makes the postings, per business area, and the
documents are reversed in the following period.
Use ‘Transaction’ B98 (User-defined valuation I) and B99 (User-defined valuation II) if you
want to use your own algorithms. In the case of posting procedure ‘Flat-rate individual value
adjustment’ (B03), you define a write-off account for the value adjustment (correction
account) and an account for writing off receivables and payables (target account). In the case
of ‘Receivables discounting’ (B02) posting procedure, define a write-off account for
discounting (correction account) and an account for expenses from value adjustment on
receivables (target account).
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Valuate >
Valuations > Define Accounts. You may also use Transaction OBB0. On the resulting screen,
you will see the different valuation procedures for the value adjustment group HWA (Figure
16.39).
Figure 16.39 Value Adjustment Procedures
Double-click on a selected ‘Procedure’ and enter the chart of accounts (say, BEUS). On the
next screen (Figure 16.40), enter the adjustment G/L account and target G/L account, for each
of the reconciliation accounts and ‘Save’ the details.
Closing
367
Figure 16.40 Account Assignment for a Value Adjustment Procedure
You may click on ‘Posting Key’ to look at the default posting keys in the standard system for
the automatic postings. The next step is to determine the base value amount for the valuation
methods.
16.2.3.4 Determine Base Value
Here, in this step, you will define the base amount for valuation per value adjustment method.
For example, for the valuation method 3 ‘Flat-rate individual value adjustment (B03)’, the
discounted local currency amount (basis = 2) will be used as the base amount. Similarly, for
the valuation method 2 ‘Receivables discounting (B02)’, the system will use the foreign
currency valuation (basis = 1). If you do not enter a value in ‘Base Amt’ field, then, the system
uses the local currency.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Valuate >
Valuations > Determine Base Value. On the resulting screen (Figure 16.41), click on ‘New
Entries’ and maintain the basis (‘BaseAmt’) per valuation ‘Method’.
Figure 16.41 Base Value Determination per Valuation Method
The final configuration step, in valuations, is to determine the values for line item display.
368
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.2.3.5 Determine Values for Line Item Display
Here, in this step, you can determine which values you want the system to display in the
‘Valuation Difference’ field in the line item display. Per ‘valuation area, currency type and
valuation method’ combination, you can display up to six values in the line item display.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Business Transactions > Closing > Valuate >
Valuations > Determine Values for Line Item Display. On the resulting screen, click on ‘New
Entries’, enter the ‘Table’ (say, BSBV), select the ‘Field Name’ and maintain the other details
like currency type, ‘Valuation’ (local GAAP or IAS etc) and the valuation ‘Method’ (for example,
‘Flat-rate individual value adjustment’). ‘Save’ the details and repeat to maintain other values
(up to a maximum of six).
This completes our discussion on the settings required for ‘valuate’ closing operation. Let us
see the next item in closing, namely ‘reclassify’.
16.3 Reclassify
The system makes use of the GR / IR clearing account to make required postings, whenever
you receive goods that are yet to be invoiced or invoices for goods that are yet to be delivered.
The system needs G/L account numbers for such adjustments and the target accounts. The
system makes use of the ‘Reclassify’ program in analysing the GR/IR clearing account and
thereby making the required adjustments, by posting any outstanding amounts to an
adjustment account. In the process, the system creates an offsetting entry to the account for
(a) goods received but not invoiced (adjustment account) or (b) goods invoiced but not
delivered (target account).
You will see the IMG activities for transferring and sorting receivables and payables in
Customizing for General Ledger Accounting.
Let us define the adjustment accounts for GR/IR clearing for BESTM company codes.
16.3.1 Define Adjustment Accounts for GR/IR Clearing
Using this activity, you can define the G/L account numbers of the adjustment and target
accounts for the automatic postings for the GR/IR clearing account.
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Reclassify > Define Adjustment
Accounts for GR/IR Clearing or Transaction OBYP.
On the ensuing screen, you will see the two procedures, BNG and GNB, for which you
need to maintain the required accounts (Figure 16.42).
Closing
369
Figure 16.42 Automatic Posting Procedures for GR/IR
iii.
iv.
Double-click on a procedure, enter the chart of accounts and maintain the required
‘Adjustment Account’ and ‘Targ.acct.’ for each of the reconciliation accounts (Figure
16.43).
Repeat for the other procedure, GNB. You can look at the posting keys, by clicking on
‘Posting Key’ (do not change the default settings for posting keys).
Figure 16.43 Adjustment / Target Account for GR/IR Account
You may also define accounts for subsequent adjustments, if required.
Project Dolphin
BESTM management has indicated to the project team that they want to set up appropriate
adjustment accounts to post the results of P&L and B/S adjustments, so as to assign line items
to specific account assignment objects like ‘Business Area’, ‘Profit Center’ etc. This is to avoid
posting the adjustment line items to the original accounts.
16.3.2 Define Accounts for Subsequent Adjustment
Though setting up of separate adjustment accounts is optional, use this configuration step to
define the G/L account numbers to which the system posts the results of P&L and B/S
adjustments, if the business wants to set up such separate accounts as in the case of BESTM.
Here, you can also maintain G/L accounts for clearing reconciliation postings made in CO, for
370
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
allocations across business area / functional areas, in the transaction key GAO. Use
transaction key GA5, only if you want a user exit for processing the B/S adjustment accounts
which are not processed in the standard system.
An adjustment, retroactively, assigns line items to particular account assignment objects
(business areas, cost center, profit center, etc). The system, automatically, generates clearing
entries and adjustment postings while assigning these line items. If you do not set up an
adjustment account, the system posts the items to the original account. To separate the
adjustment postings from other postings, you should create separate adjustment accounts in
this activity and have the system post the items to them.
You have to set up a clearing account for the adjustment process so that the postings made,
per business area, do not affect the balances. You also have to set up adjustment accounts
for reconciliation accounts, tax accounts and any other accounts which cannot be directly
posted to. Note that you cannot make these adjustment accounts as relevant to tax; do not
enter a ‘Tax category’ in the G/L account master record for these accounts, and you should
select the ‘Posting without tax allowed’ check-box for all these accounts.
To configure the G/L accounts for subsequent adjustment:
i.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Reclassify > Define Adjustment
Accounts for GR/IR Clearing or Transaction OBXM.
Figure 16.44 Procedures for defining G/L Accounts for Subsequent Adjustments
ii.
iii.
On the resulting screen, you will see all the procedures (GA0 to GA5) relating to
financial statement readjustments (Figure 16.44)
Double-click on each of the procedures, and define the appropriate G/L accounts on
the next screen to define the accounts for subsequent adjustments.
Closing
371
With this, we are, now, ready to discuss the settings that are required for transferring / sorting
receivables and payables in the system, as a part of closing process.
Project Dolphin
In closing, for regrouping receivables and payables, BESM wants the configuration team to
stick to the SAP’s standard sort method. The team has been tasked to assign the suitable G/L
accounts, as adjustment accounts, for this default sort method.
There are a couple of configuration steps in making the system ready to transfer / sort
receivables and payables during closing. The first activity is to define a sort method and then
assigning suitable adjustment accounts for regrouping.
16.3.3 Define Sort Method and Adjustment Accts for Regrouping Receivables /
Payables
To define the sort method and adjustment accounts for regrouping receivables and payables:
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Reclassify > Transfer and Sort
Receivables and Payables > Define Sort Method and Adjustment Accts for Regrouping
Receivables/Payables or Transaction OBBU.
On the resulting screen (Figure 16.45), you will see the default sort method (named
as SAP).
Figure 16.45 Overview Screen for Sort Methods and their Associated Settings
iii.
Select that row, and double-click on ‘Receivables’ on the left-hand side ‘Dialog
Structure’, and make the required classifications (like, less than 1year, more than 1
year etc) on the next screen (Figure 16.46).
372
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 16.46 Classification Intervals for Sorting
iv.
Click on ‘Account’ on a row, and maintain the required G/L accounts, for adjustment
and target for each of the reconciliation accounts on the next screen (Figure 16.47).
Figure 16.47 Adjustment Accounts for Receivables Regrouping
v.
vi.
Repeat assigning the accounts for other intervals say, ‘Receivables > 1 year’.
Repeat the steps for ‘Payables’ and ‘Save’ the configuration settings.
The next step is to define the G/L accounts for the adjustment postings for sorting receivables
/ payables according to their maturity (remaining term).
16.3.4 Define Adjustment Accounts for Receivables/Payables by Maturity
Here, you define the G/L account numbers required for the adjustment postings that sort the
receivables / payables according to their maturity (remaining term). The system makes
postings to these accounts to sort the open items which is necessary so that receivables /
payables can be displayed according to the legal requirements for creating balance sheets.
The customers (with a credit balance) and vendors (with a debit balance) are included in the
account determination for sorting.
Closing
373
For setting up the required G/L accounts:
i.
ii.
Use the menu path SAP Customizing Implementation Guide > Financial Accounting >
General Ledger Accounting > Periodic Processing > Reclassify > Transfer and Sort
Receivables and Payables > Define Adjustment Accounts for Receivables/Payables by
Maturity, for each of the charts of accounts. You may also use Transaction OBBV.
On the resulting screen, you will see the various procedures that group the
receivables and payables like, V01 – Receivables > 1 year, V04 – Liabilities >5 years
and so on. For each of the procedures, per chart of accounts, maintain the required
G/L accounts (adjustment and target) on the next screen (Figure 16.48).
Figure 16.48 Adjustment Accounts for Payables by Maturity
Similar to the above, you can define the adjustment accounts, for changed reconciliation
accounts as well as for investment accounts, as detailed below in Table 16.3:
IMG Activity
Define Adjustment
Accounts for
Changed
Reconciliation
Accounts
Define Adjustment
Accounts for
Investments
IMG Menu Path
SAP Customizing Implementation Guide > Financial
Accounting > General Ledger Accounting > Periodic
Processing > Reclassify > Transfer and Sort
Receivables and Payables > Define Adjustment
Accounts for Changed Reconciliation Accounts
SAP Customizing Implementation Guide > Financial
Accounting > General Ledger Accounting > Periodic
Processing > Reclassify > Transfer and Sort
Receivables and Payables > Define Adjustment
Accounts for Investments
Transaction
OBBW
OBBX
Table 16:3 Adjustment Accounts for Changed Reconciliation Accounts and Investment Accounts
This completes our discussion on configuring reclassification. This also completes our
discussion on the configuration settings for closing operations.
374
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
16.4 Conclusion
In this Chapter, you learned about the configuration settings that you need to make for some
of the closing operations like count, valuate and reclassify.
While discussing about ‘count’, you learned that the program ‘Reconciliation of
Receivables/Payables in Group (Cross-System)’ helps you to reconcile customer documents
and vendor documents of the affiliated companies in the group. You learned that the program
reads the open items of selected companies for the key date specified, thereby helping you
to identify documents that cause a difference.
You learned that there are several configuration settings that you need to make under ‘CrossSystem Intercompany Reconciliation’ for preparing the sender as well as the reconciliation
systems. Towards preparing the reconciliation system, you learned how to generate the
default customizing and maintain the various general settings in the system. You learned that
you need to define an application ID for intercompany reconciliation (FBRC being the SAP
supplied standard ID) and that the communication support components of the system make
use of these application IDs to distinguish between data from different application IDs. Then,
you learned about defining contact person database, placeholders for messages and message
templates. Later, you defined the reconciliation process attributes, added the desired
additional fields (up to 13) to the tables for the intercompany reconciliation of G/L accounts,
activated the individual reconciliation processes, activated the transaction data tables &
generated the posting modules to enable the intercompany reconciliation programs to post
data, and assigned the predefined roles to the single fields of the data tables. Then, you
learned about the settings that you need to maintain for data selection & storage, data
assignment and data reconciliation.
Then, for configuring balance confirmation correspondence, you learned that you need to
make settings relating to the reply address besides specifying the selection criteria. You
learned to define the address (using an ‘Address ID’) to which you want your customers or
vendors to send their balance confirmation reply. While doing so, you understood that,
normally, this address will be different from the company code address. You also learned that
you can define several such addresses, for every company code, and that once defined, you
need to specify the required ID, for every run of the balance confirmation.
For ‘valuate’, you learned that you need to make the appropriate configuration for foreign
currency valuation, reserve for bad debt and valuations.
You learned that to complete creation of financial statements, you need to perform foreign
currency valuation and for valuating in foreign currency, you have the option of (a) valuating
in local currency (company code currency) or a parallel currency, (b) using different valuation
methods like ‘lowest value principle’ and (c) automatic currency translation (in accordance
Closing
375
with FASB 52 of US GAAP, for example) when translating additional currencies from local
currency. In foreign currency valuation, you learned about the ‘valuation method’ that
determines how foreign currency valuation is performed, the grouping specifications that you
need for the balance valuation and the line item valuation. You understood that you will be
able to use the valuation method across multiple charts of accounts. You also learned that
you can use the ‘valuation areas’ to report different valuation approaches and post to
different accounts. By this, you understood that you can save the valuation result, separately
for each document item and use it for other closing operations (such as sorted lists). Then,
you learned about the ‘delta logic’ which ensures that the system does not execute any
reversal postings, for the valuation postings in the following (or subsequent) period. You
learned that you can activate the delta logic separately, per valuation area, and while
activating, that you can determine whether you want to use the clearing date as the date for
the reversal, by setting that indicator in the configuration. Then, you defined the G/L accounts
to which you want the system to automatically post the exchange rate differences, when
valuating open items and foreign currency balances. You learned that you can deactivate
some of the existing account assignment fields or activate additional account assignment
fields, that you want the system to include in the foreign currency valuation. Finally, you
defined the appropriate account determination for currency translation, per financial
statement version and valuation area, for the various financial statement items.
You learned that you can create a bad debt reserve, or write the bad debt off, using ‘individual
value adjustment’, if you feel that a particular receivable is doubtful or if it is unlikely you will
ever recover it. You learned that you can also post a flat-rate value adjustment, using ‘flatrate value adjustment’, on the balance sheet key date, for the general risk of not recovering
receivables. You learned that you can post an individual value adjustment for doubtful
receivables, using a special G/L transaction, by posting the doubtful receivable to the
customer account and to an expense account. You also learned that you can carry out flatrate value adjustments using a simple and direct G/L account posting: post the amount to an
appropriate expense account and to a balance sheet account. You understood that you can,
then, display this specific balance sheet account under the same balance sheet item as your
normal accounts receivable. You learned that to make the settings for flat-rate individual
value adjustment and for discounting of receivables, you need the ‘value adjustment key’
which determines (a) whether you want to execute a valuation for a different valuation area,
(b) the percentage of the provision for the value adjustment calculation and (c) whether the
calculation is to be based on country and due date. You, then, defined an adjustment account
and a target account, per reconciliation account, for the ‘Receivables discounting’ and ‘Flatrate individual value adjustment’ transactions, enabling the system to make the postings, per
business area, and to reverse the documents in the following period.
376
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
In ‘reclassify’ closing operation, you learned that the system makes use of the GR / IR clearing
account to make required postings, whenever you receive goods that are yet to be invoiced
or invoices for goods that are yet to be delivered. You understood that the system needs G/L
account numbers for such adjustments and the target accounts, and that the system makes
use of the ‘Reclassify’ program in analysing the GR/IR clearing account for making the required
adjustments, by posting any outstanding amounts to an adjustment account. In the process,
you learned that the system creates an offsetting entry to the account for (a) goods received
but not invoiced (adjustment account) or (b) goods invoiced but not delivered (target
account). For configuring reclassify, you first defined the G/L account numbers for the
adjustment and target accounts for the automatic postings for the GR/IR clearing account.
Then, though setting up of separate adjustment accounts is optional, you understood that
this configuration (of defining the G/L account numbers to which the system posts the results
of P&L and B/S adjustments) comes handy, if the business wants to set up such separate
accounts for subsequent adjustments. Then, you defined the sort method and, finally, defined
the adjustment accounts for regrouping receivables and payables. You understood that these
adjustment G/L account numbers are required for the adjustment postings that sort the
receivables / payables according to their maturity (remaining term).
In the next Chapter, let us discuss the information system for FI-A/R and FI-A/P.
17 Information System
Y
ou will come across several evaluations that are defined for customers and vendors, in
the standard SAP system. You can make a selection from the standard evaluations to
suit your needs, and you can enhance the same by including additional characteristics.
However, you cannot define new evaluations, here. Use the drilldown reports to define new
reports.
You need to complete the configuration settings discussed in the following Section to make
use of the standard evaluations. Let us first discuss the standard evaluations.
17.1 Standard Evaluations
Maintain the appropriate configuration by completing the following steps:
•
•
•
Copy Standard Evaluations
Select Standard Evaluations
Enhance Standard Evaluations
Let us start with the copying of standard evaluations.
17.1.1 Copy Standard Evaluations
You need to copy the standard evaluations from the source system (client 000) to your
productive system. Use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Information System > Accounts
Receivable > Standard Evaluations > Valuations > Copy Standard Evaluations. You can also use
Transaction FY01.
On the resulting screen, click ‘Yes’ on the ‘Customizing Transfer’ pop-up screen, to copy the
standard evaluations to your productive SAP client. The system carries out the copying and
brings up a log on the next screen. Use Transaction SCC3, and double-click on the log entry on
the resulting screen to view the details (Figure 17.1) of what has been copied.
378
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Figure 17.1 Copying Standard Evaluations
Now that we have copied and made available the standard evaluations in the target client,
we can continue to set up the system for standard evaluations. The next step will be selecting
the standard evaluation views that you may require for your business.
17.1.2 Select Standard Evaluations
To complete selection of standard evaluations to meet your reporting needs of A/R and A/P
information system, you need to complete a 3-step procedure that includes (1) evaluation
views, (2) evaluation types and (3) evaluations.
You will use the ‘evaluation view’ to determine what volume of data is to be evaluated. For
this, you have to create a selection variant for the relevant account types (D and K) for the
specified data retrieval program (RFDRRSEL for customer standard evaluations, and RFKRRSEL
for vendor standard evaluations).
Using the evaluation view, you can make an organizational distinction between the
evaluations. For example, you may need two subgroups for meeting the requirements as in
the case of BESTM. One subgroup will be for use by company codes in USA, and the other for
use by the company codes in India. For both the subgroups, you can define separate selection
variants (specifying the appropriate company codes), for each of the data retrieval reports,
covering customer and vendor evaluations.
Information System
379
Once you have maintained the evaluation views, you can then define which ‘evaluation types’
you want to use per evaluation view. The standard SAP system provides you with the
following evaluation types:
•
•
•
•
•
•
Currency risk
DSO analysis (for customers)
Due date structure
Overdue items
Payment history (for customers)
Terms offered/terms taken (for customers)
Finally, under ‘evaluations’, you determine the characteristics (say, country, industry, or
accounting clerk), for each evaluation type, the system should use to format the evaluations.
For this, you need to enter a ‘Selection variant’ for the program for ‘Selection’ under ‘Reports’
for the given ‘Evaluation Version’ (Figure 10.150). Using the variant, you specify (a) the
grouping field, which groups together the selected data and (b) the maximum number of
accounts (or documents) that are to be displayed in the ranking lists of the evaluation. In the
standard system, for example, selection variants are provided for the company code, business
area and country fields.
Let us configure the settings for the selection of standard evaluations.
Use the menu path: SAP Customizing Implementation Guide > Financial Accounting >
Accounts Receivable and Accounts Payable > Information System > Accounts Receivable >
Standard Evaluations > Valuations > Select Standard Evaluations. You may also use
Transaction OBDF.
i.
On the resulting screen, you will see two standard evaluation views (for customer and
vendor) defined already by SAP. Copy these to create two new customer evaluation
views (one for US and another for India) and two new vendor evaluation views (one
for US and another for India). When you copy the system creates all the associated
evaluation types and evaluations for each evaluation views (Figure 17.2).
Figure 17.2 Evalution Views for BESTM
380
ii.
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
Now, select a specific row and double-click on ‘Evaluation types’ on the left hand side
‘Dialog Structure’. You will see the various evaluation types on the ‘Change View
“Evaluation types”: Overview’ screen (Figure 17.3). You can decide which are all the
evaluation types you need, and delete the ones which you may not need. For BESTM,
we are not deleting anyone but retain all the six evaluation types, as required by the
management of BESTM.
Figure 17.3 Customer Evalution Types for BESTM
iii.
You may highlight any of the rows and double-click on ‘Evaluations’ on the left hand
side ‘Dialog Structure’ to see the evaluations that are associated with that evaluation
type. On the next screen (Figure 17.4), you will see the different evaluations (known
as ‘Version’) for the evaluation type (it is being called as evaluation category ‘EvalCat’
here) 02 – Payment history, for example.
Figure 17.4 Customer Evaluations for BESTM
iv.
Select a row and click on ‘Details’ to view the settings associated with that evaluation
on the next screen (Figure 17.5):
• Under ‘General specifications’, you will see the ‘Evaluation’ name. You will
also notice the ‘Create Evaluatn’ check-box, which when selected instructs
the system to generate the evaluation during next evaluation run.
• You will see the name of the reports (for data retrieval, selections and display)
and the associated ‘Selection variants’ under the ‘Reports’ data block. Note
that we have created a new variant ZBD01A-US, with all the company codes
of BESTM in USA, for the ‘Selection’ report RFDRRE02. You can customize the
Information System
381
‘Selection variant’ to include all or select company codes or credit control
areas, for example.
Figure 17.5 Customer Evaluation ‘Payment History’ – Details
•
We have not selected any of the flags like ‘Bank data’, ‘Tax date’, ‘Credit
control data’ or ‘Dunn.data’ under ‘Evaluation requires’ data block, as reading
the data of these respective areas may have a negative effect on the system
performance when creating evaluations.
You can also enhance the standard evaluations. Let us look at that, now.
17.1.3 Enhance Standard Evaluations
You may use SAP enhancement RFDRRANZ for enhancing the standard evaluations. For
example, you may want to group the evaluations from the A/R information system, according
to the ‘Customer classification’ field (KNA1-KUKLA). You can use the enhancement route to
achieve this. Similarly, for A/P, you have to use the enhancement RFKRRANZ. For example,
you may want to group the evaluations from the A/P information system according to the
‘Industry’ field (LFA1-BRSCH). Again, you can use the enhancement route to achieve this.
In either case, use the menu path: SAP Customizing Implementation Guide > Financial
Accounting > Accounts Receivable and Accounts Payable > Information System > Accounts
Receivable > Standard Evaluations > Valuations > Enhance Standard Evaluations, or
Transaction CMOD. On the resulting screen, create a new ‘Project’ or use an existing one, use
382
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
SAP enhancement RFDRRANZ, activate and modify the source code EXIT_ RFDRRANZ_0001 to
enhance the standard evaluation to suit your exact business needs (Figure 17.6)
Figure 17.6 Enhancement of Standard Evaluation – Customer
What we have discussed in Section 17.1, is common for both A/R and A/P though you
will see two different entries in IMG as ‘Accounts Receivable > Standard Evaluations’ and
‘Accounts Payable > Standard Evaluations’.
This completes our discussion on standard evaluations of both customers and vendors, and
also completes our discussion on information system for A/R and A/P.
17.2 Conclusion
You learned that there are several evaluations that are defined for customers and vendors, in
the information system in standard SAP. You understood that you can make a selection from
these standard evaluations to suit your needs, and you can enhance the same by including
additional characteristics. However, you learned that you cannot define new evaluations,
here. You learned that you can use the drilldown reports to define new reports, to meet your
exact business needs.
You learned that to make use of the standard evaluations, you first need to copy the standard
evaluations from the source system (client 000) to your productive system, and then complete
adapting the standard evaluations to meet your reporting needs of A/R and A/P, by
completing a 3-step procedure that includes maintaining the evaluation views, evaluation
types and evaluations. You learned that you will use the ‘evaluation view’ to determine what
volume of data is to be evaluated, by creating selection variant(s) for the relevant account
types (D and K) for the specified data retrieval program. Then, you understood that you need
to define which ‘evaluation types’ that you want to use per evaluation view. Finally, under
‘evaluations’, you learned that you need to determine the characteristics (say, country,
industry, or accounting clerk) the system should use to format the evaluations, per evaluation
type.
Let us now discuss the apps for FI-A/P and FI-A/R in the next Chapter.
18 Apps for FI-A/R & A/P
B
esides the overall SAP S/4HANA installation tasks described in the ‘UI Technology
Guide for SAP S/4HANA’ and the implementation tasks specific to each App explained
in the SAP Fiori Apps Reference Library, you also need to perform the following
implementation tasks specific to Apps for Finance:
•
•
•
Install Required Software Component Version for Job Scheduling Apps
Create a System Alias for Design Studio Apps
Activate Additional OData Services and ICF Nodes
However, if you use ‘SAP Fiori Cloud for SAP S/4HANA, you do not need to carry out the above
tasks. You just connect your back-end system to the SAP Cloud Platform.
We can broadly classify the Apps under FI-A/P and FI-A/R, into the following categories:
•
•
•
•
•
Apps for Accounts Payable Accountants
Apps for Accounts Payable Managers
Apps for Accounts Receivable Accountants
Apps for Accounts Receivable Managers
Apps for Credit Controllers
Let us, first, look at the Apps that are available to accounts payable accountants.
18.1 Apps for Accounts Payable Accountants
The following are the important Apps that are available for accounts payable accountants:
1. Create Single Payment
With this App, you can make a direct payment to a supplier when no invoice exists
and you can also pay open supplier line items. When you make such a direct payment
to a supplier (without an invoice), you specify the supplier details, the bank details,
and the amount to be paid and, then, create the payment. The system posts the
payment as a down payment request, and uses that document to initiate the payment
run. When paying open supplier line items, select the open items that you want to
pay through the Manage Supplier Line Items App and create the payment to initiate
the payment run.
384
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
2. Display Process Flow - Accounts Payable
Use this App, to display the relationships between FI-A/P documents, including
purchase orders, goods movements, incoming invoices, journal entries, and clearing
entries.
3. Display Supplier Balances
You can use this App to see debits, credits, and balances by company code, fiscal year,
and supplier. It allows you to further analyze the amounts by drilling down to the
related line items. You can also compare the purchases between two fiscal years.
4. Display Supplier List
With this App, you can display and download a list of suppliers. You can use the search
filters to create custom lists of suppliers to provide to stakeholders and auditors.
5. My Free Form Payments
With this App, you can display a list of payment requests that you have created. You
can create, edit, or reverse your payment requests.
6. Create Free Form Payment
The digital assistant, SAP CoPilot, allows you to create a free form payment from the
context of your current Fiori screen, using the ‘Create Free Form Payment’ App. For
example, while working in an App, you need to create a new free form payment. You
can easily access SAP CoPilot and create a new free form payment without leaving
your current screen.
7. Process Free Form Payments
With this App, you can display a list of payment requests and view the details of
individual requests. Depending on your role, you can also release or reverse payment
requests
8. Manage Checkbooks
Available both for accounts payable accountants and managers, with this App you can
monitor and manage checkbook usage in your organization. It provides an overview
of the status of different checkbooks, including an alert status for checkbooks nearing
depletion, and allows you to act on this information immediately.
Apps for FI-A/R & A/P
385
9. Manage Outgoing Checks
Available both for accounts payable accountants and managers, you can use this App
to monitor and manage outgoing checks in your organization. It provides an overview
of the status of different outgoing checks, indicating whether an outgoing check is
new, voided or cashed, and allows you to act on this information immediately.
10. Manage Payment Blocks
You can use this App to set and remove payment blocks on invoices or supplier
accounts. You can use various search and sorting functions to select and display
invoices and view their status.
11. Manage Supplier Line Items
Use this App for ad-hoc requests or recurring reports to easily find vendor line items
using a wide range of search criteria. To make your work more efficient, you can
personalize the layout of the table, predefine recurring queries, and save your
settings as variants. Besides displaying data, you can also take various actions such as
setting a payment block or creating a manual payment.
12. Post Outgoing Payments
With this App, you can post and clear a single outgoing payment in one step. You
usually perform outgoing payments automatically based on payment proposals.
However, if you want to perform a payment immediately, you need to enter the
payment data manually. You can clear outgoing payments with open items. You can
also post an outgoing payment on account or to a G/L account.
13. Clear Outgoing Payments
With this App, you can clear a payable payment manually, such as an open outgoing
payment for a supplier invoice. The system usually clears these payments
automatically. However, if you have paid your supplier manually without reference
to an open item, you can use this App to find the matching items and clear the
payment manually.
14. Revise Payment Proposals
With this App, you can check and revise payment proposals and the details of open
items. It allows you to make sure that all the payments are made correctly and on
time, and are compliant with company policies.
386
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
15. Manage Automatic Payments
Use this App, to schedule payment proposals or schedule payments directly and get
an overview of the proposal or payment status. The App identifies the overdue
invoices and checks whether all the required payment information is complete.
16. Manage Payment Media
With this App, you can transfer the data required for electronic payment transactions
to banks, via a data medium. A payment medium is created with each successful
payment run. When you download a payment medium, the App automatically saves
it as a .txt or .xml file, according to its type.
17. Schedule Accounts Payable Jobs
Use this App to schedule accounts payable jobs.
18. Monitor Payments
With this App, you can display an overview of your payment batches. You can view
the statuses of batches and individual payments at different processing stages.
19. Import Supplier Invoices
With this App, you can import multiple supplier invoices into the system, all at once.
You download a template file, enter the invoice information, and upload the
completed file back to the App. You can, then, post the invoices from the App.
20. Manage Supplier Down Payment Requests
With this App, you can create down payment requests manually. In most cases, the
system automatically creates down payment requests from suppliers based on the
supplier’s purchase order. However, if a supplier requests a down payment, that was
not specified in the purchase order, for example by sending an email or a fax, you can
create it manually. Once the payment run has made the down payment, the payment
run also automatically clears the corresponding down payment request. In some
cases, you might need to clear the down payment request manually, for example if
differences occur because you paid less, split the payment, or made the payment
manually.
Let us look the Apps that are available to accounts payable managers.
Apps for FI-A/R & A/P
387
18.2 Apps for Accounts Payable Managers
The following are the important Apps that are available for your accounts payable managers:
1. Accounts Payable Overview
With this (analytical overview) App, you can monitor important accounts payable
indicators and access the relevant accounts payable Apps. You can use the filters to
limit the data behind the indicators to the information most relevant for you.
2. Aging Analysis
With this App, you can see the aging information across your organization so that you
can identify negative trends in the total payable amount, the net due amount, and
the overdue amount. This App allows you to timely react by having your team taking
appropriate actions to reverse these trends.
3. Approve Bank Payments
With this App, you can review and process payment batches. You can check the
payments within a batch and approve, reject, or defer individual payments or entire
batches.
4. Cash Discount Forecast
With this App, you can forecast the available cash discounts in the short term. You
can get a prediction over the discounted value of blocked invoices on the next
payment days.
5. Cash Discount Utilization
With this App, you can monitor, in real time, the cash discount utilization in your
responsibility area. You can find out which company code or location needs to make
better use of cash discounts. You can, also, find out about the reasons for cash
discount loss so that it can be avoided in the future.
6. Days Payable Outstanding
With this App, you can drill down to check the top 10 suppliers with the highest or
the lowest days payable outstanding (DPO). You can view the result in a chart or a
table according to company code, supplier, country of the supplier, and timeline.
388
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
7. Days Payable Outstanding - Detailed Analysis
With this (analytical) App, you can conduct a detailed analysis of your DPO. You can
use the predefined analysis steps to view your DPO by company code, supplier, and
country of supplier. You can look at those trends, over time, and focus your analysis
by using the filters to drill down.
8. Future Payables
With this App, you can drill down to check on the top 10 amounts payable, and the
numbers of open items for the relevant suppliers. In addition, you can view the future
amounts payable in a chart or a table according to company code, supplier, country
and region of the supplier, account group of the supplier, and payment blocking
reason.
9. Invoice Processing Analysis
With this App, you can view the total amount of posted invoices and the total number
of posted line items.
10. Overdue Payables
With this App, you can check the overdue payable amount to your suppliers by
supplier company code, supplier group, supplier, and reason for payment block. You
can monitor the status of the overdue payments for critical suppliers in your area of
responsibility. You can also find out about the potential risks and notify the
responsible persons to take action.
11. Supplier Payment Analysis (Open Payments)
With this App, you can get an overview of the open payments. You can view the
payment data by different dimensions, including company code, supplier, currency,
and user.
12. Supplier Payment Analysis (Manual and Automatic Payments)
With this App, you can view the payment data by different dimensions, including
company code, supplier, currency, and user.
Let us look the Apps that are available to accounts receivable accountants.
Apps for FI-A/R & A/P
389
18.3 Apps for Accounts Receivable Accountants
The following are some of the important Apps for account receivable accountants:
1. Accounts Receivable Overview
With this (analytical overview) App, you can monitor important A/R indicators and
access the relevant A/R Apps. Use the filters to limit the data.
2. Cash Collection Tracker - Accounts Receivable
With this (analytical) App, you can track your collection progress against due
receivables, for a selected period. You select a period or date and the App displays
the sums of all open invoices due in previous periods, invoices posted in previous
periods that are due in the selected period, and new invoices that are both posted
and due in the selected period.
3. Display Customer Balances
You can use this App to display customer balances and compare sales. You can display
debits, credits, and balances by company code, fiscal year, and customer, and further
analyze the amounts by displaying all related line items. You can also compare sales
figures between two fiscal years.
4. Manage Customer Line Items
Use this App for ad-hoc requests or recurring reports to easily find customer line
items using a wide range of search criteria. You can personalize the layout of the
table, predefine recurring queries, and save your settings as variants. Besides
displaying data, you can also take various actions such as setting a payment, export
the data to a file and collaborate with colleagues. The App also serves as a navigation
target from other apps, allowing users to drill down into the customer line items.
5. Manage Customer Down Payment Requests
You use this App to display down payment requests that have been created
automatically, based on a sales order. For example, if a customer wants to negotiate
the due date of the requested payment, you have to find the correct down payment
request to clarify the issue. In this case, you can use this App to find and change the
relevant down payment request. If an appropriate down payment request does not
exist, you can use this App to create one. If the sales order does not exist and
therefore the down payment request cannot be created automatically, you can use
this App to create the down payment request for this amount manually. Once the
customer has paid the down payment, the corresponding down payment request is
390
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
cleared automatically. In some cases, you might need to clear the down payment
request manually, for example if differences occur or the payment was split.
6. Post Incoming Payments
With this App, you can post and clear a single incoming payment, in one step. You
usually check for incoming payments using online banking. However, if payments are
not received using electronic bank statements, you need to enter the payment data
manually, and trigger a search for the matching open items. Ideally, the system
proposes a list of matching items for which you can post and clear the payment in one
step. If it’s not possible to clear the payment, you can post it on account or to a G/L
account.
7. Clear Incoming Payments
Use this App, to clear a receivable payment manually, such as an open incoming
payment for a customer invoice. The system usually clears these payments
automatically. However, sometimes customer information is missing and the system
cannot find appropriate open items that match the payment. In this case, you have
to clarify this payment, match it to the correct open invoices and credit memos as
aligned with your customer, and clear the payment manually.
8. Manage Bank Statements
You can use this App to manage manual and electronic bank statements. It provides
an overview of all bank statements for all house bank accounts. You can also view
detailed information, per bank statement.
9. Reprocess Bank Statement Items
You can use this App to reprocess bank statement items that were not processed
automatically. As you know, you can enter bank statements into the system
automatically (electronic bank statement) or manually. In both cases, rule-based
processing assigns and clears the payments automatically. If the automatic processing
is not successful, manual reprocessing is required. In this App, you can reprocess a
bank statement item, mark it as reprocessed, and enter a reason for reprocessing.
You can also add attachments to bank statement items.
10. Manage Bank Statement Reprocessing Rules
With this App, you can create and manage bank statement reprocessing rules. This
allows you to automate the reprocessing of bank statement items, which enables you
to spend more time on critical tasks.
Apps for FI-A/R & A/P
391
11. Manage Lockbox Batches - United States
You can use this App to manage your lockbox batches.
12. Reset Cleared Items
With this App, you can reset the clearing of line items as well as reverse the clearing
entry if required. You can use this function for line items of customer accounts or
supplier accounts as well as for line items of G/L accounts that are managed on an
open item basis.
13. Manage Incoming Payment Files
With this App you can manually import bank statements and lockbox batches, using
electronic payment files. After the bank statements and lockbox batches are imported
and posted, you can process them further using the ‘Manage Bank Statements’ and
‘Manage Lockbox Batches’ Apps, if needed.
14. Create Correspondence
With this App, you can preview, email, print, and download correspondence related
to your customers and suppliers. You can launch the App from the SAP Fiori
Launchpad or open from other Fiori Apps, including ‘Display Customer Balances’,
‘Display Supplier Balances’, ‘Manage Customer Line Items’, and ‘Manage Supplier Line
Items’.
15. Manage Payment Advices
With this App, you can create payment advices manually. You can also view, edit, and
delete existing payment advices.
16. Create Payment Advice
You can create a new payment advice using the ‘Create Payment Advice’ button or
using the ‘SAP CoPilot’ digital assistant if you have enabled SAP CoPilot.
17. Display Payment Card Data
With this App, you can display a list of card payments and related information,
including details of the card used, the payment authorization, and settlement.
18. Assign Open Items
With this App, you can view open items related to a customer, assign credit items to
matching debit items, and clear open items based on this assignment.
392
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
19. Process Collections Worklist
With this App, you can process your prioritized collections worklist. The worklist
enables you to focus on the most urgent customers, for example, those with the
highest overdue amount or where the amount has been overdue for a long time.
20. Process Receivables
With this App, you can access a list of A/R by an individual customer. You can then
create promises to pay and dispute cases. You start the App either by entering a
customer number directly, or by searching for a customer, or by drilling down to an
individual customer from the ‘Process Collections Worklist’ App.
21. Supervise Collections Worklist
With this App, you can display an overview of all open receivables for collection. You
can supervise the progress of your collection specialists on a daily basis, manage their
workloads, and redirect their efforts as required.
22. My Dunning Proposals
With this App, you can create dunning proposals, and then review the dunning notices
before they are sent to customers. If, for business reasons, you do not want to send
a dunning notice to a particular customer, you can choose to set a dunning block on
that notice. It will then not be included when the remaining dunning notices are sent.
23. Display Dunning History
Intended for collection specialists whose main task is to contact customers to request
payment of overdue receivables, you can use this App to see an overview of dunned
customers and view their individual dunning history.
24. Manage Dispute Cases
With this App, you can analyze and process receivables-related dispute cases. This
App helps you to structure your investigations and to distribute and manage the
results for all involved parties in your
25. Display Process Flow - Accounts Receivable
With this App, you can display the relationships between A/R documents, including
quotations, sales documents, delivery documents, billing documents, journal entries,
and clearing entries.
Apps for FI-A/R & A/P
393
26. Display Customer List
With this App, you can see master data for all your customers in one place.
27. Schedule Accounts Receivable Jobs
With this App, you can schedule A/R jobs using the templates and scheduling options.
With this, let us, now, proceed to discuss the Apps for account receivable managers.
18.1 Apps for Accounts Receivable Managers
The following are some of the important Apps for account receivable managers:
1. Overdue Receivables
Use this App, to view the Key Performance Indicator (KPI), ‘Overdue Receivables’. The
App helps you to drill down to analyze the 10 highest overdue receivables by
customer, enabling you to take quick action for reducing the high overdues. Besides
analysing the overdue receivables by company code or by accounting clerk, you can
view the overdue receivables in a chart or a table according to company code,
customer, country and region of the customer, and accounting clerk.
2. Overdue Receivables in Dispute
With this App, you can display the value of overdue receivables in dispute. Using this,
you can prioritize the open disputes that are delaying the payment of overdue
invoices.
3. Overdue Receivables by Risk Class
With this App, you can display overdue receivables by risk class. It can help you
analyze if your risk is appropriately diversified and provides you with insights to
support segmentation, credit, and payment term decision making.
4. Allowance for Doubtful Accounts
Use this App, to gain insight into allowance for doubtful accounts management, and
you can assess the adequacy of current allowance levels. The App gives you a clear
view of overdue receivables and their associated allowances, and you can drill down
for details of individual customer accounts at journal entry level.
5. Cash Collection Tracker - Collections Management
With this (analytical) App, you can track your collection progress against due
receivables for a given period. For the selected period or date, the App displays the
394
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
sums of all open invoices due in previous periods, invoices posted in previous periods
that are due in the selected period, and new invoices that are both posted and due in
the selected period. The sum of these due receivables forms the total target.
6. Doubtful Accounts Valuation
With this App, you gain insight into allowance for doubtful accounts management,
and you can assess the adequacy of current allowance levels. This refers to provisions
made to allow for expected credit losses, as required by IFRS 9. The App gives you a
clear view of overdue receivables and their associated allowances, and you can drill
down for details of individual customer accounts at journal entry level.
7. Dunning Level Distribution
The App displays the ‘Dunning Level Distribution’ KPI, which is open dunning
amounts, per customer and dunning level. Besides viewing the open dunning
amounts in a chart or a table according to dunning level and by the 10 customers with
the highest open dunning amounts, you can also drill down to analyze your dunning
level distribution according to account group, accounting clerk, company code,
country key, customer, customer classification, display currency, exchange rate type,
reconciliation account, or region.
8. Future Receivables
This (analytical) App displays ‘Future Receivables’ KPI. Using this, you can view the
results in a chart or table according to due period, company code, or the top 10
customers who have the highest amounts receivable. You can also drill down to see
the numbers of open items for the relevant customers. In addition, you can analyze
your future amounts receivable according to account group, accounting clerk,
company code, country key, customer, customer classification, display currency,
exchange rate type, G/L account, net due interval, region, or special G/L.
9. Manage Collection Strategies
You use this App to manage your collection strategies that are used to prioritize items
in a collection worklist, specify the currency in which items in the worklist are
displayed, and to determine the aging intervals into which open receivables should
be sorted. It allows you to copy the base SAP collection strategy and edit your copied
version to fit the collection needs of your business.
10. Total Receivables
This (analytical) App displays the ‘Total Receivables’ KPI. It helps to view the
receivables amount in total, by various dimensions and filter the results according to
Apps for FI-A/R & A/P
395
different criteria. You can also drill down to analyze your total receivables by account
group, company code, company code currency, country key, customer, customer
classification, display currency, exchange rate type, G/L account, reconciliation
account, region, or special G/L.
11. Days Sales Outstanding
This (analytical) App displays the ‘Days Sales Outstanding (DSO)’ KPI, which is the
number of days it takes, on an average, for your company to collect receivables. The
App displays the average number of days it takes for your company to collect
receivables. A high DSO figure can indicate that your company is taking too long to
collect money, and that your company is extending too lenient credit terms to
customers. The App clearly indicates when predefined thresholds have been
exceeded. You can view DSO figures in a chart or a table according to account group,
accounting clerk, calendar month, calendar year, company code, country key,
customer, customer classification, display currency, exchange rate type, G/L account,
reconciliation account, region, or special G/L. If your company has been in business
for a longer period of time, you may find the ‘Days Beyond Terms’ KPI more helpful.
12. Days Sales Outstanding - Detailed Analysis
With this (analytical) App, you can conduct a detailed analysis of your DSO. You can
use the predefined analysis steps to view your DSO by company code, due period,
and country of customer. You can look at your revenue and overdue receivables over
time and focus your analysis by using the filters to drill down.
13. Days Beyond Terms
This (analytical) App displays the ‘Days Beyond Terms (DBT)’ KPI, which shows how
effectively you collect your receivable payments. It provides you with an insight into
the payment history of your customers and indicates how effectively your company
collects payments. A high DBT figure indicates that your company is taking too long
to collect payments. The App clearly indicates when predefined thresholds have been
exceeded. You can view DBT figures in a chart or a table according to account group,
accounting clerk, calendar month or year, company code, country key, customer,
customer classification, display currency, exchange rate type, reconciliation account,
or region. If you have just started a new business, you may find the DSO more helpful.
14. Display Item Change Log
With this App, you can see details of changes made to all journal entries relevant to
your role. It displays changes to all log-enabled fields in the relevant documents, and
you can easily see what was changed, by whom, and when. This gives you a
396
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
demonstrable oversight of all changes made to journal entries within your area, which
can be useful in relation to auditing.
15. Reprocessing Rate of Incoming Payments
You can use this App, to display and analyze how many incoming payments (bank
statement items) have been manually reprocessed after automatic payment clearing
was unsuccessful. As manual reprocessing of incoming payments is expensive and
time-consuming, this App helps you to improve the automation of receivables
management by giving you detailed information on how often and under what
circumstances manual reprocessing is required. You can run analyses according to
reason, company, customer, or bank. In addition, you can initiate further steps to save
processing costs, such as sending an e-mail to a customer or informing management,
if settings are missing or wrong.
16. Credit Limit Utilization
The (analytical) App displays the ‘Credit Limit Utilization’ KPI, that is, the utilization of
a business partner’s credit limit as a percentage value and an absolute amount. You
can check which business partners are beyond the threshold value you defined. You
can view credit limit utilization and credit exposure according to business partner,
credit segment, country, and region. You can drill down by the top 10 business
partners with the highest credit limit utilization and by the top 10 business partners
with the highest credit exposure.
17. Supervise Collections Worklist
With this App, you can display an overview of all open receivables for collection. You
can supervise the progress of your collection specialists on a daily basis, manage their
workloads, and redirect their efforts as required.
18. Collection Progress
The (analytical) App displays the ‘Collection Progress’ KPI. You can view the overall
progress in collecting payments from the customers and the collection progress for
different collection specialists and collection groups.
19. Promises to Pay
The (analytical) App displays the ‘Promises to Pay’ KPI, that is, open promises to pay
as of today. You can view promised amounts in different periods as well as overdue
payment promises and broken promises according to company code, customer,
country and region of the customer, and collection specialist. You can view promises
Apps for FI-A/R & A/P
397
to pay in a chart or a table, and you can drill down by days, the top 10 customers with
the highest promised amounts, collection specialist, and broken promises.
20. Open Disputes
The (analytical) App displays the ‘Open Disputes’ KPI. The ‘open disputes’ refer to
dispute cases that are not closed, not confirmed, and not voided/deleted/cancelled.
You can view the open disputes in a chart or a table according to company code,
customer, processor, and dispute reason. You can drill down by dispute reason,
processor, and the top 10 customers with the highest disputed amounts.
With this let us now look at the important Apps that are available for account receivable credit
controllers.
18.2 Apps for Credit Controllers
Let us now understand the salient features of the two important Apps for credit controllers:
1. Display Credit Management Log
With this App, you can display credit management logs. This App gives you a clearly
structured overview, when you need to check (at a glance) if a credit check has failed
or if you want to view the details of a failed credit check.
2. Analyze Credit Exposure
With this App, you can analyze your credit exposure by several dimensions and
measures. It allows you to see your total credit exposure and provides you with
insights to support risk diversification, segmentation, credit, and payment term
decision making.
This completes our discussion on Apps for FI-A/R and FI-A/P.
18.3 Conclusion
In this Chapter, we understood what you need to do in terms of system configuration to make
use of the financial Apps, if you are not on ‘SAP Fiori Cloud for SAP S/4HANA’. Later, we
discussed the salient features of important Apps that are available for your accountants &
managers handling FI-A/R and FI-A/P. We also discussed the important Apps for credit
controllers.
***
398
Configuring SAP Accounts Receivable & Accounts Payable (SAP S/4HANA Finance)
We started this book with the case study (Project Dolphin) that paved the way for all the
discussions in the various Chapters. The case study provided you with the requirements that
need to be configured for setting up of FI-A/R and FI-A/P for a business enterprise.
You understood that accounts receivable (FI-A/R) and accounts payable (FI-A/P) components
of SAP, integrated fully with the SAP General Ledger Accounting (SAP G/L), help you in dealing
with the customers and vendors, respectively, for managing the amounts that your business
would receive from (customers) and pay to (vendors).
We discussed both the customer and vendor accounts, and you understood the preparations
in terms of account groups, screen layout, message control, number ranges etc., for creating
the master records of the business partners. You understood that a typical customer master
record is made up of four data segments namely the general data, the company code area
data, the sales & distribution area data and the ETM (Equipment and Tools Management)
data. You, further, understood that you can create the customer master record, in SAP, in
three different ways: central maintenance (for all the areas), FI maintenance (for FI area or
company code area alone) and sales data maintenance (for SD area alone). Similar to the
customer master data, you saw that a vendor master record is made up of three distinct data
segments: general data, company code area data and purchasing organization data. And, you
saw that you can create the vendor data also in three ways, as in the case of customer master
records: centralised creation (for all the three area), FI maintenance (company code area data
alone) and purchasing organization data maintenance (for MM area alone). You learned how
the account groups play a major role in maintenance of these master data, both for customer
and vendor. You also saw how to change or delete a customer / vendor master.
In the case of customers, besides the general specifications, you understood what are the
sensitive fields and the need for dual control of these fields. You learned about the settings
that are required, for both customers and vendors, for displaying line items, for open item
processing and for correspondence.
Under business transactions, you have been exposed to the various configuration settings
that you have to make for handling incoming / outgoing invoices, incoming / outgoing
payments, processing down payments (received / made), open item clearing, adjustment
posting / reversal, dunning, interest calculation and closing activities. You also learned about
the settings that are required for document parking, and its subsequent release using
approval groups, approval path and approval procedure.
You learned the details about the global settings that are required for outgoing / incoming
payments, during which you understood defining of various accounts for handling discount
(taken / given), overpayments / underpayments, exchange rate differences, rounding off
differences, translation settings, payment block reasons, payment terms and so on. You also
learned about the settings required for both manual and automatic payments. While
discussing manual outgoing payments, you learned about the vendor tolerances, reason
codes and also on how to prepare the system for handling cross-company code manual
Apps for FI-A/R & A/P
399
payments. In configuring the automatic payment program, which can handle both incoming
and outgoing payments, you saw how to set up: the house banks, all / payment company
codes for payment transactions, the different payment methods etc. You understood how the
system determines a suitable bank for a given payment transactions, besides understanding
the value date rules, payment groupings, automatic payment posting etc. You did understand
how the automatic payment program works from selecting the open item payables, to
selecting the appropriate payment method, house bank, account and finally making and
posting the payments, besides creating the payment media for electronic data transfer.
You learned about SEPA mandates and the associated configuration. You also learned about
the payments through payment cards and the settings that you may need to make on the FI
side, for payment card integration with SAP SD.
You learned dunning in detail. You saw the basic settings, including dunning areas, dunning
keys, dunning block reasons and dunning forms. You understood when you need to configure
dunning, per dunning area. While discussing the dunning procedure, you saw that this is at
the heart of the dunning program controlling how the program duns the business partners.
You, further, saw that the dunning procedure contains specifications like dunning frequency
/ dunning interval, grace days, minimum number of days for open items to be dunned, the
number of dunning levels (with the level determining the form and text of the dunning notice)
and also the specifications as to whether to dun standard and/or special G/L transactions. For
the dunning notice printouts, you understood defining the dunning forms and maintaining
the sender details for those forms.
In interest calculation, you learned about the item (or arrears) interest calculation, the
settings associated with that in terms of interest calculation types, reference interest rates,
time-dependent terms, interest values etc. You also learned about the automatic account
determination settings for item and balance interest calculation for both A/R and A/P. You
did learn about the forms for interest printout and the associated settings.
While discussing the configuration settings for closing operations, you learned about settings
for count, balance confirmation, valuate and reclassify. You also learned about the settings
for valuation in terms of valuation adjustment keys and determination of base value for
valuation.
Towards the end of the Chapter, you learned about the settings you will require to make use
of SAP’s standard evaluations, for customers and vendors, as a part of A/R and A/P
information system. You learned how to copy the standard evaluations to your productive
system, how to select and enhance the required standard evaluations to meet your business
reporting. At the end, in the last Chapter, you learned about the important Fiori Apps that are
available to your accountants, managers and credit controllers.
This completes our discussion on accounts receivable (FI-A/R) and accounts payable (FI-A/P).
About the Author
Narayanan Veeriah is a Chartered Financial Analyst (CFA), a PMP
(from Project Management Institute), and IBM Certified Executive
Project Management Professional, having more than 35 years of
work experience, in finance, project management and information
technology (IT), including 20+ years of experience in SAP
implementation and consulting. A member of Certified Associate of
Indian Institute of Bankers (CAIIB), he brings along with him a strong
domain expertise in Banking and Finance with core competencies in
retail banking and credit management, along with SAP.
Narayanan has worked with several multi-national clients for consulting, implementing and
supporting SAP, across industries including automotive, banking & finance, electronics,
manufacturing, multimedia, pharmaceuticals etc. He has worked with several versions of SAP
right from SAP R/3 3.1H to the latest SAP S/4HANA, in new implementations, upgrades and
support.
Till recently, he was leading SAP practice, for a couple of industry verticals in a leading
multinational IT consulting company. He has authored several books on SAP Finance, besides
being a regular guest faculty at management institutions for ERP, SAP, banking & finance and
project management.
He is currently a freelance SAP consultant.
You can reach him at vdotn@yahoo.com.
Index
A
ABAP List View, 37, 75, 94, 95
ABAP List Viewer, 276, 303
Account Assignment Model, 106
Account Blance Display, 77, 80
Account Determination Key, 317
Accounting Principles, 354, 357, 358
Accounts Payable, 45, 46; See: FI-A/P
Accounts Receivable, 45, 46; See: FI-A/R
Accounts Receivable Pledging Indicator, 63
ACH, 201, 209
ACH-CCD, 209
ACH-CTX, 209
ACH-PPD, 209
Additional Checks for Accounting Documents, 111,
153
Additional Fields, 64, 75, 95, 123, 330, 334, 335,
336, 354, 361, 374
Adjustment Accounts for GR/IR Clearing, 368
Application ID for Intercompany Reconciliation,
330, 374
Apps for Accounts Payable Accountants, 383
Clear Outgoing Payments, 385
Create Free Form Payment, 384
Create Single Payment, 383
Display Process Flow - Accounts Payable, 384
Display Supplier Balances, 384
Display Supplier List, 384
Import Supplier Invoices, 386
Manage Automatic Payments, 386
Manage Checkbooks, 384
Manage Outgoing Checks, 385
Manage Payment Blocks, 385
Manage Payment Media, 386
Manage Supplier Down Payment Requests, 386
Manage Supplier Line Items, 385
Monitor Payments, 386
My Free Form Payments, 384
Post Outgoing Payments, 385
Process Free Form Payments, 384
Revise Payment Proposals, 385
Schedule Accounts Payable Jobs, 386
Apps for Accounts Payable Managers, 383, 387
Accounts Payable Overview, 387
Aging Analysis, 387
Approve Bank Payments, 387
Cash Discount Forecast, 387
Cash Discount Utilization, 387
Days Payable Outstanding, 387
Days Payable Outstanding - Detailed Analysis,
388
Future Payables, 388
Invoice Processing Analysis, 388
Overdue Payables, 388
Supplier Payment Analysis (Manual and
Automatic Payments), 388
Supplier Payment Analysis (Open Payments),
388
Apps for Accounts Receivable Accountants, 383,
389
Accounts Receivable Overview, 389
Assign Open Items, 391
Cash Collection Tracker - Accounts Receivable,
389
Clear Incoming Payments, 390
Create Correspondence, 391
Create Payment Advice, 391
Display Customer Balances, 389
Display Customer List, 393
Display Dunning History, 392
Display Payment Card Data, 391
Display Process Flow - Accounts Receivable, 392
Manage Bank Statement Reprocessing Rules,
390
Manage Bank Statements, 390
Manage Customer Down Payment Requests,
389
Manage Customer Line Items, 389
Manage Dispute Cases, 392
Manage Incoming Payment Files, 391
Manage Lockbox Batches - United States, 391
Manage Payment Advices, 391
My Dunning Proposals, 392
Post Incoming Payments, 390
Process Collections Worklist, 392
Process Receivables, 392
404
Index
Reprocess Bank Statement Items, 390
Reset Cleared Items, 391
Schedule Accounts Receivable Jobs, 393
Supervise Collections Worklist, 392
Apps for Accounts Receivable Managers, 383, 393
Allowance for Doubtful Accounts, 393
Cash Collection Tracker - Collections
Management, 393
Collection Progress, 396
Credit Limit Utilization, 396
Days Beyond Terms, 395
Days Sales Outstanding, 395
Days Sales Outstanding - Detailed Analysis, 395
Display Item Change, 395
Doubtful Accounts Valuation, 394
Dunning Level Distribution, 394
Future Receivables, 394
Manage Collection Strategies, 394
Open Disputes, 397
Overdue Receivables, 393
Overdue Receivables by Risk Class, 393
Overdue Receivables in Dispute, 393
Promises to Pay, 396
Reprocessing Rate of Incoming Payments, 396
Supervise Collections Worklist, 396
Total Receivables, 394
Apps for Credit Controllers, 383, 397
Analyze Credit Exposure, 397
Display Credit Management Log, 397
Apps for Finance, 383
AR Pledging Indicator, 56, 64, 65, 66
Arrears Interest Calculation. See Item Interest
Calculation
Authorizations, 70
Automated Clearing House, 209
Automatic Clearing Program, 276, 279
Automatic Incoming Payments, 230
Automatic Outgoing Payments, 187
Automatic Postings for Foreign Currency Valuation,
359
Automatic Worklists, 77
B
Bad Debt Reserve. See: Reserve for Bad Debt
BAdI, 301, 341, 350
Balance Confirmation, 351
Balance Interest, 35, 261, 295, 296, 297, 304, 305,
308, 313, 314, 320, 321, 322, 323, 365, 399
Balance Interest Calculation, 261, 295, 296, 297,
304, 305, 308, 317, 320, 321, 323, 365, 399, See
Bank Account Interest Calculation, See: Balance
Account Interest Calculation
Bank Account Interest Calculation, 295, 323
Bank Chain, 190
Bank Directory, 189
Bank Identifier Code. See BIC
Bank Interest. See: Balance Interest
BIC, 190, 191
Bill of Exchange, 40, 46, 47, 187, 197, 199, 200, 213
Block Indicator, 155, 156
Business Add-In, 341; See: BAdI
Business Area, 135, 277, 289, 293, 370
C
Cash Clearing Account, 237, 239
Check Cashing Time, 217
Classic Bank Account Determination, 212
Classic Withholding Tax, 125
Clearing Differences, 278
Client, 100, 117, 123, 337
Coding Block, 123, 124, 125
Collection Strategies, 394
Company Code Currency, 353, 374
Company Code Global Parameters, 123, 125, 290
Contact Person Database, 330, 331, 334
Controlling, 170
Controlling Area, 26
Count, 325
Credit Interest Rates, 295
Critically Overdue, 96
Cross-company Code Postings, 182
Cross-System Intercompany Reconciliation, 326
Currency Type, 359
Customer Accounts, 48, 49
Customer Down Payments, 281
D
Data Medium Exchange, 46, 187; See: DME
Days Payable Outstanding, 47; See: DPO
Days Receivable Outstanding, 46; See: DSO
Debit Interest Rates, 295
Default Values, 99, 116, 117, 166
Index
Deletion Block, 74
Deletion Flag, 74
Delta Logic, 354, 358, 359, 375
Disputed Items, 181
DME, 46, 187, 192, 209, 211
Document
Document Change Rules, 135
Document Currency, 273
Document Header, 100, 104, 118, 127, 129, 135,
136, 154
Document Number, 100, 131, 273, 275
Document Parking, 99, 137, 146, 398
Document Release, 38, 142, 145, 146, 155
Document Splitting, 354
Document Type, 100, 101, 102, 104, 290
Down Payment, 40, 46, 47, 187, 194, 197, 279, 281,
282, 283, 284, 285, 286, 287
Down Payment Received, 281, 284
Down Payment Request, 40, 187, 194, 197, 281,
386, 389
Down Payments Made, 285, 287
DPO, 47
Drilldown Reports, 377, 382
DSO, 46, 47, 379
Dual Control, 37, 66, 67, 70, 80, 88, 89, 90, 91, 142,
398
Dunning, 243
Dunning Area, 244, 245, 246, 265, 270, 399
Dunning Block Reasons, 42, 247, 248, 270, 399
Dunning Blocks. See Dunning Block Reasons
Dunning Keys, 246, 247, 270, 399
Dunning Level, 42, 43, 179, 243, 244, 245, 247, 249,
251, 252, 253, 256, 257, 258, 259, 260, 268, 269,
270
Dunning Notice, 46, 59, 243, 244, 245, 255, 256,
259, 260, 262, 265, 267, 269, 270
Dunning Procedure, 42, 43, 244, 245, 246, 249,
250, 251, 252, 253, 254, 255, 256, 257, 259, 260,
263, 264, 266, 267, 268, 269, 270, 399
Dunning Proposal, 244, 245, 256, 258, 267, 269
E
EDI, 46, 192, 197
Electronic Bank Statement, 390
Electronic Data Interchange, 46; See: EDI
Enterprise Structure, 326
Entry Screens for Parking Documents, 138
405
Equipment and Tools Management Data, 50; See:
ETM
ETM Data, 50
EU Internal Transfer, 203
Evaluation Type, 380
Evaluation Version, 379
Evaluation View, 378
Exceptional Threshold, 96
Exchange Rate, 160, 161, 274, 276, 354, 355, 356,
359, 360, 361, 362, 375
Exchange Rate Type, 355, 356, 362
Extended Individual Payment, 208
F
Factoring, 54, 63
Factory Calendar, 218, 300
FASB, 353, 375
Fast Entry Screens for G/L Account Items, 136
FI-A/P, 45, 46, 47, 48, 81, 97, 285, 287, 325, 397,
398, 399
FI-A/R, 45, 46, 48, 49, 281, 284, 325, 398, 399
Field Catalogs, 330, 338
Field Status, 104, 108, 110, 111, 118, 119, 122, 153
Field Status Group, 118, 153
Field Status Variant, 118, 119, 153
Financial Accounting Internet Services, 79
Financial Statement Version, 28
Fiori, 424
Flat-rate Value Adjustment, 362, 363, 375
Functional Area, 120, 122, 354, 361
G
Generic Threshold, 96
Group Currency, 353, 359, 374
H
House Bank, 40, 189, 190, 192, 193, 210, 211, 212,
213, 214, 215, 217, 222, 223, 399
I
IBAN, 190, 191, 192
Incoming Payments, 229
Individual Value Adjustment, 362, 363, 364, 366,
367, 368, 375
406
Index
Input Tax, 152, 226
Interactive Reconciliation, 347, 350
Intercompany Reconciliation, 325, 326, 329, 330,
331, 334, 335, 336, 341, 342, 350, 374
Interest Calculation, 295
Interest Calculation Frequency, 309, 310
Interest Calculation Period, 296, 310
Interest Calculation Report, 295
Interest Calculation Types, 261, 304
Interest Forms, 322
Interest Indicator, 261, 295, 296, 309, 310, 312,
313, 323
Interest Letter, 295, 297, 302, 303
Interest Rates, 295, 312, 323
Interest Values, 315
International Bank Account Number. See IBAN
Item Interest, 43, 254, 261, 295, 296, 297, 298,
299, 300, 304, 305, 306, 308, 313, 314, 315, 316,
323
Item Interest Calculation, 43, 254, 261, 295, 297,
298, 299, 300, 304, 305, 306, 308, 313, 315, 323,
399
Item Interest Calculation Process, 297
K
Key Performance Indicator, 393; See: KPI
KPI, 393, 394, 395, 396, 397, See: Key Performance
Indicator
L
Ledger Group, 357
Line Item, 100, 104, 128, 129, 130, 153, 168, 169,
170, 173, 289, 334, 355, 356, 375
Line Layout for Document Change/Display, 133
Line Layout for Document Posting Overview, 133
Link Rules, 58, 86, 119, 153
Local Currency, 273, 353, 359, 374
M
Manual Incoming Payments, 230
Manual Outgoing Payments, 166
Manual Worklists, 77
Message Template Group, 332, 334
Message Templates, 332
N
NAICS. See North American Industry Classification
System
Negative Posting, 289, 290, 291, 292, 293
North American Industry Classification System, 61
Null Tolerance Group, 167, 168, 171
O
Object Groups, 334, 347
Object Subgroups, 347
Open Disputes, 393, 397
Open Item, 273, 279
Open Item Clearing, 158, 271, 398
Open Item Management, 273, 327
Overview for Experts, 7
P
Partial Payment, 173
Payment Block Reason, 155
Payment Cards, 237, 238, 240
Payment Grouping, 218
Payment Method, 41, 149, 187, 194, 195, 196, 200,
201, 202, 203, 204, 205, 206, 207, 209, 210, 211,
212, 213, 214, 215, 216, 217, 218, 223, 399
Payment Method Supplement, 196
Payment Program, 40, 41, 46, 81, 184, 186, 187,
189, 193, 194, 195, 197, 204, 205, 207, 211, 215,
216, 217, 218, 219, 220, 221, 222, 223, 237, 241,
399
Payment Release, 140, 142, 143, 154, 155
Payment Request, 197, 220
Payment Terms, 146, 151, 154
Placeholders for Messages, 330, 332, 333
Posting Key, 104, 106, 107, 108, 109, 116, 117, 118,
153
Posting Period, 289, 293
Profit Center, 135, 369, 370
Program
RFDRRSEL, 378
RFDUZI00, 303
RFINTITAR, 298, 303, 305
RFINTITDEL, 303
RFKCON00, 90
RFKRRSEL, 378
SAPF019, 73, 94
Index
SAPF020, 74
SAPMSSY0, 266
Purchasing Organization Data, 81, 97
R
Reason Codes, 39, 180, 222, 234, 398
Reason for Reversal, 291, 293
Receivables Discounting, 366, 367, 375
Reclassify, 368
Reconciliation of Receivables/Payables in Group,
325, 374
Reconciliation Process Attributes, 330, 331, 332,
334
Reference Interest Rates, 313
Report
RFDABL00, 70, 71
RFDRRE02, 380
RFINTITDEL, 303
RFINTITSHOW, 302, 303
RFINTITUSERXT, 303
RFKABL00, 91
SAPF130D, 351
Reserve for Bad Debt, 353, 362, 374
Residual Item, 173
Reversal Document, 102
Reversal Reason, 291, 293
Risk Class, 393
Rreference Interest Rates, 301, 313, 314, 315, 399
S
SAP Assurance and Compliance Software, 48
SAP Cash Management, 46, 282
SAP Cloud, 383
SAP Cloud Platform, 383
SAP CoPilot, 384, 391
SAP Enhancement, 381
SAP Financial Supply Chain Management, 46
SAP Fiori Apps, 383
SAP Fiori Apps Reference Library, 383
SAP Fiori Cloud for SAP S/4HANA, 383
SAP Fiori Launchpad, 391
SAP Fraud Management, 47, 48
SAP G/L, 45, 48, 239, 398
SAP G/L Accounting, 174, 275, 354, 373
SAP General Ledger Accounting, 45, 48, 398
SAP HANA, 23
407
SAP MM, 4, 45, 46, 48, 101
SAP PM, 4
SAP PP, 4
SAP PS, 4
SAP S/4HANA, 1, 3, 4, 23, 24, 28, 47, 48, 401, 421,
422, 423
SAP Fiori Cloud, 383
UI Technology Guide for SAP S/4HANA, 383
SAP S/4HANA Enterprise Management, 48
SAP S/4HANA Finance, 4
SAP Sales and Distribution, 49, 50, 51, 52, 60, 61,
237; See: SAP SD
SAP SD, 4, 45, 48, 49, 73, 399
SAP Smart Forms, 249, 262, 263, 270
SAPScript, 42, 74, 249, 250, 262, 263, 264, 265,
270, 322
Screen Layout, 53, 54, 57, 58, 84, 85, 86
Screen Variant, 125, 126
Security Deposit, 197
Sensitive Fields, 37, 66, 67, 69, 70, 73, 80, 88, 89,
90, 91, 94, 398
SEPA, 230, 231, 232, 233, 234, 235, 399
SEPA Mandates, 230; See: SEPA
Sets, 345, 346, 347
SIC. See Standard Industrial Classification
Single Euro Payments Area. See: SEPA
Society for Worldwide Interbank Financial
Telecommunication. See: SWIFT
Special Purpose Ledger, 327, 335, 341, See: Special
Ledger
Standard Evaluations, 377
Standard Fields, 221
Standard Industrial Classification, 61; See: SIC
Standard Line Layout for Document
Change/Display, 134
Subgroups, 347, 348, 378
Subscreen, 123, 124
Substitution, 126, 154
Substitution in Accounting Documents, 126
Subworkflow, 140, 142, 154
SWIFT, 190, 191, 200
T
Table
BSID, 218, 267
BSIK, 218, 267
FBICRC001A, 335
408
Index
FBICRC003A, 335
INTITHE, 303
INTITIT, 303
INTITPF, 303
KNA1, 267
KNB1, 267
KNB5, 267
LFA1, 267
LFB1, 267
LFB5, 267
Tax Code, 289, 293
Terms of Payment, 50, 81, 146, 147, 149, 151, 154,
166, 176, See Payment Terms
Text ID, 127, 128, 129, 130, 154
Text Lines for Message Template, 333
Texts for Line Items, 130
Thresholds for Vendor Account Groups, 96
Time-dependent Terms, 297, 301, 399
Tolerance, 167, 222
Tolerance Group, 167, 168, 169, 170, 171, 173,
174, 175, 176
Transaction
BP, 51, 82
CMOD, 381
F150, 267
F-22, 116
FB50, 364
FBICC, 327
FBIC004, 336
FBIC006, 335
FBIC031, 336
FBIC032, 343
FBICO10, 339
FBICRC_SNRO, 343
FBN1, 304
FBRC001, 333
FBRC002, 332
FBRC003, 345
FBRC004, 346
FBRC006, 349, 350
FBRC007, 334
FBRC008, 338
FBRC009, 348
FBRC010, 331
FBZP, 188
FD01, 51
FD02, 51
FD03, 51
FD08, 68
FD09, 68
FI_APAR_SEPA_CUST, 232
FI12, 189
FI12_HBANK, 189
FINS_FCT, 354, 361
FINT, 298, 302
FINTAP, 299
FINTSHOW, 299
FK01, 83
FK02, 83
FK03, 83
FK08, 90
FK09, 90
FSSP, 351
FY01, 377
MK01, 83
MK02, 83
MK03, 83
O7E4, 138
O7E6, 137
O7FC, 221
O7FE, 221
O7V1, 134
O7Z1, 133
O7Z2, 133
OB00, 162
OB05, 60
OB09, 160
OB17, 247
OB27, 156
OB28, 112
OB32, 135
OB40, 226, 283
OB41, 107, 109
OB44, 60
OB46, 261
OB55, 78
OB57, 173
OB60, 185
OB61, 246
OB70, 153, 225
OB74, 277
OB81, 314
OB83, 315
OB84, 322
OBA0, 175
OBA1, 360
Index
OBA3, 177
OBA4, 169
OBA7, 102, 103
OBAA, 309
OBAC, 313
OBAP, 219
OBAR, 63
OBB0, 366
OBB8, 147, 150, 151
OBB9, 150, 151
OBBA, 217
OBBB, 218
OBBE, 180
OBBH, 126
OBBU, 371
OBBV, 373
OBBW, 373
OBBX, 373
OBC4, 121
OBC5, 123
OBD2, 54
OBD3, 85
OBDF, 379
OBL6, 267
OBR2, 73, 94
OBT10, 130
OBT8, 129
OBU1, 117
OBV1, 317
OBV3, 320
OBV4, 321
OBV9, 320
OBWE, 143
OBWF, 144
OBWG, 145
OBWH, 146
OBWJ, 140
OBX1, 229
OBXB, 283, 286
OBXC, 219
OBXH, 164
OBXK, 163
OBXL, 159
OBXM, 370
OBXO, 162
OBXP, 220
OBXR, 281
OBXU, 158
409
OBXV, 159
OBXW, 227
OBXY, 363
OBXZ, 279
OBY6, 123
OBYP, 368
OBYR, 285
OBZ3, 202
OBZH, 238
OBZI, 240
OXK1, 123
REMMHBACC, 212
S_ALR_87001305, 265
S_ALR_87003179, 89
S_ALR_87003378, 67
S_ALR_87004651, 290
S_ALR_87004660, 292
S_ALR_87012089, 93
S_ALR_87012090, 90
S_ALR_87012182, 72
S_ALR_87012183, 70
SCC3, 377
SEPA_MND_FM_CUST, 233
SEPA_MND_FM_MT, 232
SEPA_NR_CUST, 234
SEPA_NR_MT, 233
SMARTFORMS, 263
SO10, 265
VD01, 51
VD02, 51
VD03, 51
XD01, 51
XD02, 52
XD03, 52
XDN1, 62
XK01, 83
XK02, 83
XK03, 83
XKN1, 87
XKN2, 88
Transfer Days, 300, 306
True Reversal, 289, 290
U
UI Technology Guide for SAP S/4HANA, 383
US GAAP, 353, 375
410
Index
V
Validation Callup Point, 111
Validation in Accounting Documents, 111
Validations, 111, 153
Valuate, 353
Valuation Area, 357, 358, 362, 375
Valuation Difference, 368
Valuation Method, 354, 355, 356, 375
Value Adjustment Key, 364, 375
Vendor Accounts, 48, 81
Vendor Down Payments, 285, 287
W
Work Flow, 138, 154
Workflow, 4, 28, 141, 142, 143, 144, 155
Workflow Variant, 28, 138, 139, 140, 141, 142, 143,
155
Worklist, 77
Writing Off of Bad Debt, 362
List of Figures
Figure 2.1 Customer Master Data Areas ............................................................................................... 50
Figure 2.2 Customer Account Group - New ........................................................................................... 55
Figure 2.3 Making AR Pledging Indicator Field as Optional ................................................................... 56
Figure 2.4 Customer Account Groups for BESTM .................................................................................. 56
Figure 2.5 Defining Screen Layout per Company Code ......................................................................... 57
Figure 2.6 Defining Screen Layout per Transaction ............................................................................... 58
Figure 2.7 Message Control Settings ..................................................................................................... 59
Figure 2.8 Accounting Clerk Field in Customer Master ......................................................................... 60
Figure 2.9 Accounting Clerk Definition .................................................................................................. 60
Figure 2.10 Defining Industries.............................................................................................................. 61
Figure 2.11 Assigning Industry Code in Customer Master Record ........................................................ 61
Figure 2.12 Number Ranges for Customer Accounts ............................................................................ 62
Figure 2.13 Assigning Number Ranges to Customer Account Groups................................................... 63
Figure 2.14 Activating AR Pledging Indicator ........................................................................................ 64
Figure 2.15 AR Pledging Indicator - Details ........................................................................................... 65
Figure 2.16 AR Pledging Indicator for BESTM Company Codes ............................................................. 65
Figure 2.17 AR Pledging Indicator in Customer Master ......................................................................... 66
Figure 2.18 Sensitive Fields for Dual Control ......................................................................................... 67
Figure 2.19 System Displaying a Message on the Changes to Sensitive Fields...................................... 68
Figure 2.20 System Displaying the Confirmation Status........................................................................ 68
Figure 2.21 System Displaying the Changed Sensitive Field .................................................................. 69
Figure 2.22 System Displaying the Details of Changes Made to Sensitive Fields .................................. 69
Figure 2.23 System Not Allowing to Confirm the Changes by the Same User ...................................... 69
Figure 2.24 Field Group for Customer Master Change Control ............................................................. 71
Figure 2.25 Adding Fields to Field Group .............................................................................................. 72
Figure 2.26 Selection Screen of Report RFDABL00 Showing the Field Group ....................................... 72
Figure 2.27 Report RFDABL00 Displaying Changes ................................................................................ 73
Figure 2.28 Periodic Account Statement Indicator................................................................................ 76
Figure 2.29 Periodic Account Statement Indicator in Customer / Vendor Master Record ................... 77
Figure 2.30 Manual Worklist for BESTM................................................................................................ 78
Figure 2.31 Enabling Worklist Entry during Open Item Processing ....................................................... 79
Figure 2.32 Maintaining Users / Accounts for Internet Services ........................................................... 79
Figure 3.1 Vendor Master Data ............................................................................................................. 82
Figure 3.2 Vendor Account Groups ....................................................................................................... 85
Figure 3.3 Defining Screen Layout per Company Code (Vendors) ........................................................ 86
Figure 3.4 Defining Screen Layout per Transaction (Vendors) .............................................................. 86
Figure 3.5 Number Ranges for Vendor Accounts .................................................................................. 88
Figure 3.6 Assigning Number Ranges to Vendor Account Groups ........................................................ 88
412
List of Figures
Figure 3.7 Sensitive Fields under Dual Control for Vendor Master ....................................................... 89
Figure 3.8 Confirming Changes to Sensitive Fields of Multiple Records ............................................... 90
Figure 3.9 Field Group for Vendor Master Change Control ................................................................... 92
Figure 3.10 Assigning Fields to Field Group for Vendor Master Change Control .................................. 92
Figure 3.11 Selection Screen of Report RFDABL00 Showing the Field Group ....................................... 93
Figure 3.12 Report Output of RFKABL00 with List/Detail of Changes to Vendor Records .................... 93
Figure 3.13 Overdue Thresholds for Vendor Account Groups .............................................................. 96
Figure 4.1: New Document Type (YR) .................................................................................................. 102
Figure 4.2: Making ‘Reference Number’ as Required Entry for Document Type DR ........................... 103
Figure 4.3: Standard Posting Keys ....................................................................................................... 106
Figure 4.4: Settings for a Posting Key .................................................................................................. 107
Figure 4.5: Settings for Posting Key 05 ................................................................................................ 109
Figure 4.6: Settings for Posting Key 02 ................................................................................................ 110
Figure 4.7: Field Status Settings for Posting Key 06 ............................................................................ 110
Figure 4.8 Company Code – Business Area Relationship, for BESTM Group ....................................... 111
Figure 4.9 Change Validation: Overview Screen .................................................................................. 112
Figure 4.10 Create Validation: Creating a Step.................................................................................... 113
Figure 4.11 Create Validation: Creating Prerequisite .......................................................................... 114
Figure 4.12 Create Validation: Prerequisite and Check Configured .................................................... 115
Figure 4.13 Create Validation: Fully Configured Step .......................................................................... 116
Figure 4.14 New Validation in Accounting Documents ....................................................................... 116
Figure 4.15: Default Values: Document Type and Posting Key ........................................................... 117
Figure 4.16 Standard Field Status Groups (FSG) .................................................................................. 119
Figure 4.17 SAP Link Rules to resolve conflicting Field Statuses ......................................................... 120
Figure 4.18 Defining FSV ‘B100’ for BESTM ......................................................................................... 121
Figure 4.19 FSGs associated with FSV ‘B100’ ...................................................................................... 121
Figure 4.20 Field Status change for ‘Payment Reference’ field ........................................................... 122
Figure 4.21 FSV – Company Code Assignment .................................................................................... 123
Figure 4.22 Defining a new Subscreen for Coding Block ..................................................................... 125
Figure 4.23: Screen Variant for Document Entry................................................................................. 126
Figure 4.24: Substitution in Accounting Documents ........................................................................... 127
Figure 4.25: Using Text IDs in Document Header ................................................................................ 127
Figure 4.26: Using Text IDs in a Line Item ............................................................................................ 128
Figure 4.27: Configuring Text IDs for Document Header..................................................................... 129
Figure 4.28: Configuring Text IDs for Line Items ................................................................................. 130
Figure 4.29 Entering Text Key (ID) in Text Field ................................................................................... 131
Figure 4.30 Line Item Text ID ............................................................................................................... 132
Figure 4.31 Text ID replaced by Actual Text together with the value of Variable ............................... 132
Figure 4.32 Standard Line Layout Variants for Document Change / Display ....................................... 133
Figure 4.33 Selecting Default Line Layout Variant for Document Change / Display ........................... 134
Figure 4.34: Document Change Rules for Document Header ............................................................. 135
Figure 4.35: Document Change: Editable Fields in Document Header................................................ 136
Figure 4.36: Standard Screen Variants for G/L Account Items Fast Entry ........................................... 137
List of Figures
413
Figure 4.37 Defining Workflow Variant US01 ..................................................................................... 139
Figure 4.38 Assigning Workflow Variant US01 to Company Code ...................................................... 140
Figure 4.39 Release Groups ................................................................................................................. 141
Figure 4.40 Release Approval Paths .................................................................................................... 141
Figure 4.41 Assigning Release Approval Paths for Parking Documents .............................................. 142
Figure 4.42 Assigning Release Approval Procedures for Parking Documents ..................................... 143
Figure 4.43 Release Levels with Amount Limit .................................................................................... 144
Figure 4.44 Allocating Organization Object to Release Levels ............................................................ 144
Figure 4.45 Customer Line Item Fields for Resetting Document Release ........................................... 145
Figure 4.46 Vendor Line Item Fields for Resetting Document Release ............................................... 146
Figure 4.47 Configuring Payment Terms BC90 for BESTM .................................................................. 148
Figure 4.48 Payment Terms for BESTM ............................................................................................... 150
Figure 4.49 Defining Installments for Payment Terms BINS ................................................................ 151
Figure 4.50 Instalment Payment Term BINS - Details.......................................................................... 152
Figure 4.51 Configuring Cash Discount Base ....................................................................................... 153
Figure 5.1 Payment Block Reasons ...................................................................................................... 156
Figure 6.1 G/L Account for Cash Discount Received ........................................................................... 158
Figure 6.2 G/L Account for Cash Discount Lost ................................................................................... 159
Figure 6.3 G/L Account for handling Under / Over Payments ............................................................. 159
Figure 6.4 G/L Accounts for Posting Exchange Rate Differences during OI Clearing ........................... 161
Figure 6.5 G/L Accounts for handling Rounding Differences ............................................................... 162
Figure 6.6 G/L Accounts for Payment Differences with Alternative Currencies .................................. 162
Figure 6.7 G/L Account for Bank Charges (Vendors) ........................................................................... 163
Figure 6.8 List of Clearing Transactions ............................................................................................... 164
Figure 6.9 Standard Posting Keys for the Clearing Procedure ‘Incoming Payment’ ............................ 164
Figure 6.10 Enabling Company Code for Posting Translation Gain / Loss ........................................... 165
Figure 6.11 Default Block Key Configuration via Payment Terms ....................................................... 166
Figure 6.12: Tolerance Group TGUS for Company Code 1110 ............................................................ 169
Figure 6.13: Null Tolerance Group for Company Code 2100 ............................................................... 171
Figure 6.14: Assigning Users to a Tolerance Group ............................................................................. 174
Figure 6.15 Null G/L Tolerance Group for Company Code 1110 ......................................................... 176
Figure 6.16 G/L Tolerance Groups for BESTM ..................................................................................... 176
Figure 6.17 Customer/Vendor Tolerance Group BEU1 - Details ......................................................... 178
Figure 6.18 Customer/Vendor Tolerance Groups for BESTM .............................................................. 180
Figure 6.19 Reason Codes for Manual Outgoing Payments ................................................................ 181
Figure 6.20 Cross-Company Code Transactions – Settings for Clearing between 110 and 1120 ........ 183
Figure 6.21 List of Company Codes paired for Cross-Company Code Transactions ............................ 184
Figure 6.22 Settings for Cross-Company Code Manual Payments ...................................................... 185
Figure 6.23 Configuring Manual Payments ......................................................................................... 186
Figure 6.24 Entry Screen of Transaction FBZP ..................................................................................... 188
Figure 6.25 New House Bank Creation ............................................................................................... 190
Figure 6.26 House Banks for Company Code 1110 ............................................................................. 192
Figure 6.27 Creating a Bank Account at House Bank .......................................................................... 193
414
List of Figures
Figure 6.28 Accounts at a House Bank ............................................................................................... 193
Figure 6.29 Setting up All Company Codes for Payment Transactions ............................................... 195
Figure 6.30 Setting up Paying Company Codes for Payment Transactions ........................................ 198
Figure 6.31 Payment Methods in Vendor Master .............................................................................. 200
Figure 6.32 Country-Specific Payment Methods for USA ................................................................... 202
Figure 6.33 Details of Payment Method Settings for ‘Check’ for USA ................................................ 203
Figure 6.34 Payment Method Configuration Per Company Code ...................................................... 206
Figure 6.35 Configuring ‘Single Payment’ in Vendor Master .............................................................. 208
Figure 6.36 Configuring Payment Methods Per Company Code ........................................................ 210
Figure 6.37 Configuring Payment Medium Format Per Company Code ............................................ 211
Figure 6.38 Configuring Bank Determination – Ranking Order .......................................................... 213
Figure 6.39 Configuring Bank Determination – Bank Accounts .......................................................... 214
Figure 6.40 Configuring Bank Determination – Availabe Amounts .................................................... 214
Figure 6.41 Configuring Bank Determination – Value Date ................................................................ 215
Figure 6.42 ‘Check Cashing Time’ Field in Vendor Master ................................................................. 216
Figure 6.43 Automatic Posting Settings for Payment Program .......................................................... 219
Figure 6.44 Automatic Posting Settings for Payment Requests ......................................................... 220
Figure 6.45 Standard Search Fields for Payments in Payment Run .................................................... 221
Figure 6.46 Standard Search Fields for Line Item Display in Payment Run ........................................ 222
Figure 7.1 Cash Discount Base for Outgoing Invoices......................................................................... 225
Figure 7.2 Tax Accounts for Outgoing Payments ................................................................................ 226
Figure 7.3 Posting Key Definition for Outgoing Invoice/Credit Memo ............................................... 227
Figure 8.1 G/L Account for Posting Cash Discount Taken ................................................................... 230
Figure 8.2 Activating SEPA Mandate Management ............................................................................ 231
Figure 8.3 Function Module Configuration for Generating SEPA Mandate ID ................................... 232
Figure 8.4 Selecting the Function for Generating SEPA Mandate ID .................................................. 233
Figure 8.5 Number Ranges for SEPA Mandate ................................................................................... 233
Figure 8.6 Number Ranges Assignment for SEPA Mandate ............................................................... 234
Figure 9.1 Central FI Settings for Payment Cards ............................................................................... 238
Figure 9.2 G/L Account Assignment to Clearing Account (Payment Cards) ....................................... 240
Figure 10.1 Mantaining Dunning Area in a Customer Master Record ................................................ 246
Figure 10.2 Defining Dunning Key ...................................................................................................... 247
Figure 10.3 Entering Dunning Block Reason in Customer Master Record .......................................... 248
Figure 10.4 Defining Dunning Block Reasons ..................................................................................... 249
Figure 10.5 Defining a New Dunning Form (SAPScript) by Copying the Standard Form .................... 250
Figure 10.6 New Dunning Proceudre – Overview............................................................................... 253
Figure 10.7 New Dunning Proceudre – Dunning Level ....................................................................... 255
Figure 10.8 New Dunning Proceudre – Dunning Charges .................................................................. 257
Figure 10.9 New Dunning Proceudre – Minimum Amounts ............................................................... 258
Figure 10.10 New Dunning Proceudre – Dunning Texts ..................................................................... 258
Figure 10.11 New Dunning Proceudre – Company Code Dunning Control ........................................ 259
Figure 10.12 Interest Indictors ............................................................................................................ 262
Figure 10.13 Dunning Interest Rates .................................................................................................. 262
List of Figures
415
Figure 10.14 Dunning Form F150_DUNN_SF (Smart Form) ............................................................... 263
Figure 10.15 Assigning Dunning Forms for Normal Dunning Procedure ............................................ 264
Figure 10.16 Assigning Dunning Forms for Legal Dunning Procedure ................................................ 264
Figure 10.17 Configuring Sender Details for Dunning Forms ............................................................. 265
Figure 10.18 System Generated Configuration List for Dunning Program ......................................... 266
Figure 11.1 Payment Difference Processing during Clearing .............................................................. 274
Figure 11.2 Criteria for grouping Clearing Items in Automatic Clearing .............................................. 278
Figure 11.3 G/L Accounts for Posting Clearing Differences ................................................................. 279
Figure 12.1 Special G/L List for Customer ........................................................................................... 281
Figure 12.2 Reconciliation / Special G/L Accounts for Customer Down Payments ............................ 282
Figure 12.3 Account for Output Tax Clearing on Down Payments ..................................................... 283
Figure 12.4 Automatic Posting Rules for Output Tax Clearing on Down Payments ........................... 283
Figure 13.1 Special G/L List for Vendor .............................................................................................. 285
Figure 13.2 Reconciliation / Special G/L Accounts for Vendor Down Payments ................................ 286
Figure 13.3 Account for Input Tax Clearing on Down Payments ........................................................ 286
Figure 14.1 Configuring Negative Postings .......................................................................................... 290
Figure 14.2 Configuring Negative Postings using Transaction OBY6 ................................................... 291
Figure 14.3 Reversal Reasons .............................................................................................................. 292
Figure 15.1 Fields Relevant for Interest Calculation (Customer Master Record) ................................ 296
Figure 15.2 Item Interface Calculation – Initial Screen ....................................................................... 298
Figure 15.3 Number Range for Interest Forms ................................................................................... 305
Figure 15.4 Configuring Item Interest Indicator (1U) ......................................................................... 307
Figure 15.5 Configuring Interest Indictor ............................................................................................ 311
Figure 15.6 Reference Interest Rate – Item Interest Calculation – Credit .......................................... 313
Figure 15.7 Time Dependent Interest Terms of Interest Indicator 1U ............................................... 314
Figure 15.8 Time Dependent Interest Terms for BESTM .................................................................... 314
Figure 15.9 Interest Rate Values for Reference Interest Rates for Item Interest ............................... 315
Figure 15.10 Fixed Amounts for Interest Calculation ......................................................................... 316
Figure 15.11 A/R: Calculation of Interest on Arrears – Account Determination Settings .................. 318
Figure 15.12 A/R: Calculation of Interest on Arrears – Control Parameters ...................................... 319
Figure 15.13 A/R: Calculation of Interest on Arrears – Account Symbols .......................................... 319
Figure 15.14 A/R: Calculation of Interest on Arrears – G/L Account Assignment .............................. 319
Figure 15.15 A/R: Calculation of Interest on Arrears – Document Type Specification ....................... 320
Figure 15.16 A/R Balance Interest Calculation – G/L Accounts .......................................................... 321
Figure 15.17 A/R Balance Interest Calculation – Account Symbols .................................................... 321
Figure 15.18 Forms for Interest Calculation ....................................................................................... 322
Figure 16.1 Reconciliation of Group Receivables / Payables – Process Flow ...................................... 325
Figure 16.2 Creating Default Customizing for Intercompany Reconciliation ...................................... 328
Figure 16.3 Generate Default Customizing for Intercompany Reconciliation – Results ..................... 329
Figure 16.4 Application ID for Intercompany Reconciliation ............................................................... 331
Figure 16.5 Contact Person Database ................................................................................................. 331
Figure 16.6 Placeholders for Messages ............................................................................................... 332
Figure 16.7 Message Template............................................................................................................ 333
416
List of Figures
Figure 16.8 Text Lines for Message Template SAP0000010 ................................................................ 333
Figure 16.9 Attributes for Reconciliation Process 003 ........................................................................ 334
Figure 16.10 Activating Processes for Intercompany Reconciliation .................................................. 335
Figure 16.11 Activating Data Transaction Tables – Test Run............................................................... 336
Figure 16.12 Activating Data Transaction Tables – Log from Productive Run ..................................... 337
Figure 16.13 Maintaining Field Catalogs ............................................................................................. 338
Figure 16.14 Reconciliation Process Detail Attributes ........................................................................ 340
Figure 16.15 Company Attributes for Reconciliation .......................................................................... 342
Figure 16.16 Number Range for Group Reference Numbers .............................................................. 343
Figure 16.17 Rules for Document Assignment – Overview Screen ..................................................... 344
Figure 16.18 Rules for Document Assignment – Rule Definition ........................................................ 345
Figure 16.19 Setting up of Reconciliation Display ............................................................................... 346
Figure 16.20 Sets Overview ................................................................................................................. 347
Figure 16.21 Sets: Single Entries – Overview ....................................................................................... 347
Figure 16.22 Overview of Object Groups ............................................................................................ 348
Figure 16.23 Overview of Object Subgroups ....................................................................................... 348
Figure 16.24 Overview of Status Fields ............................................................................................... 349
Figure 16.25 Status Icons and Values .................................................................................................. 349
Figure 16.26 Activate BAdI ‘FB_RC_PRESENTATION’ .......................................................................... 350
Figure 16.27 Address Data for Reply Addresses for Balance Confirmation ........................................ 351
Figure 16.28 Additional Selection Criterial Fields for Balance Confirmation...................................... 352
Figure 16.29 Additional Selection Criteria Fields for Balance Confirmation (Transaction F.17) ......... 352
Figure 16.30 Valuation Method........................................................................................................... 355
Figure 16.31 Valuation Areas .............................................................................................................. 357
Figure 16.32 Assigning Accounting Principle to Ledger Group ........................................................... 358
Figure 16.33 Assigning Valuation Areas to Accounting Principle ........................................................ 358
Figure 16.34 Activating Delta Logic for Valuation Areas ..................................................................... 359
Figure 16.35 Accounts for Automatic Postings of Foreign Currency Revaluation ............................... 360
Figure 16.36 Activating Additional Fields for Foreign Currency Valuation .......................................... 361
Figure 16.37 Alternative Reconciliation Account for Individual Value Adjustment ............................ 363
Figure 16.38 Value Adjustment Keys .................................................................................................. 365
Figure 16.39 Value Adjustment Procedures ....................................................................................... 366
Figure 16.40 Account Assignment for a Value Adjustment Procedure .............................................. 367
Figure 16.41 Base Value Determination per Valuation Method ........................................................ 367
Figure 16.42 Automatic Posting Procedures for GR/IR ....................................................................... 369
Figure 16.43 Adjustment / Target Account for GR/IR Account ........................................................... 369
Figure 16.44 Procedures for defining G/L Accounts for Subsequent Adjustments ............................. 370
Figure 16.45 Overview Screen for Sort Methods and their Associated Settings ................................. 371
Figure 16.46 Classification Intervals for Sorting .................................................................................. 372
Figure 16.47 Adjustment Accounts for Receivables Regrouping ......................................................... 372
Figure 16.48 Adjustment Accounts for Payables by Maturity ............................................................. 373
Figure 17.1 Copying Standard Evaluations ......................................................................................... 378
Figure 17.2 Evalution Views for BESTM .............................................................................................. 379
List of Figures
Figure 17.3
Figure 17.4
Figure 17.5
Figure 17.6
417
Customer Evalution Types for BESTM ............................................................................. 380
Customer Evaluations for BESTM .................................................................................... 380
Customer Evaluation ‘Payment History’ – Details ........................................................... 381
Enhancement of Standard Evaluation – Customer .......................................................... 382
List of Tables
Table 0:1 BESTM - Companies ............................................................................................................... 24
Table 0:2 BESTM - Company Codes, Country and Currency .................................................................. 25
Table 0:3 BESTM – Credit Control Areas ............................................................................................... 25
Table 0:4 BESTM – Business Areas ........................................................................................................ 25
Table 0:5 BESTM – Profit Centers / Profit Center Groups ..................................................................... 27
Table 0:6 BESTM – Standard Messages and Changes Required for BESTM .......................................... 30
Table 0:7 Cross-Company Code Pairing for Manual Payments ............................................................. 40
Table 0:8 Dunning Charges for BESTM for US-based Company Codes.................................................. 43
Table 1:1 Key Features of FI-A/R ........................................................................................................... 46
Table 1:2 Key Features of FI-A/P ........................................................................................................... 47
Table 2:1 Customer Master Maintenance ............................................................................................. 52
Table 3:1 Vendor Master Maintenance ................................................................................................. 83
Table 4:1 Default Document Types ..................................................................................................... 101
Table 4:2 Default Posting Keys ............................................................................................................ 106
Table 4:3 Field Status Configuration for Posting Keys for BESTM ....................................................... 108
Table 4:4 Standard Screen Variants for Document Entry .................................................................... 125
Table 10:1 Dunning Charges for Multi-level Dunning Procedure of BESTM ....................................... 252
Table 11:1 Functions for Open Item Clearing ...................................................................................... 275
Table 16:1 Database Tables for Additional Fields in Intercompany Reconciliation ............................. 335
Table 16:2 Properties for Special Purpose Ledger used in Intercompany Reconciliation ................... 341
Table 16:3 Adjustment Accounts for Changed Reconciliation Accounts and Investment Accounts ... 373
Latest Book by the Author
Configuring SAP Financial Accounting – Vol. II
(SAP S/4HANA Finance)
(1st Edition)
Configure SAP Financial Accounting, in SAP S/4HANA Finance (1909), to suit your exact business needs!
Understand the concepts and learn configuring your SAP system step-by-step, through case-studies,
with numerous screenshots and illustrations covering:
• Case Study
• Accounts Receivable and Accounts Payable
• Contract Accounts Receivable and Payable
• Bank Accounting
• Asset Accounting
598 pages, 1st edition 2020
Formats: Kindle & Paperback
ISBN: B08CXPWH4B
https://www.amazon.com/dp/B08CXPWH4B
Latest Book by the Author
Configuring SAP Financial Accounting – Vol. I
(SAP S/4HANA Finance)
(1st Edition)
Configure SAP Financial Accounting, in SAP S/4HANA Finance (1909), to suit your exact business needs!
Understand the concepts and learn configuring your SAP system step-by-step, through case-studies,
with numerous screenshots and illustrations covering:
• SAP HANA
• SAP S/4HANA
• SAP S/4HANA Finance
• Case Study
• FI Global Settings I (Ledgers, Field Status, Fiscal Year, Company Code Global Parameters etc.)
• FI Global Settings II (Documents, Inflation Accounting and Correspondence)
• FI Global Settings III (Taxes including Withholding Tax)
• General Ledger Accounting
564 pages, 1st edition 2020
Formats: Kindle & Paperback
ISBN: 979-8657784145
https://www.amazon.com/dp/B08C4DHF8Z
Latest Book by the Author
Configuring SAP Asset Accounting
(SAP S/4HANA Finance)
(1st Edition)
Configuring SAP Asset Accounting, based on the latest version of SAP S/4HANA Finance, is a complete
guide to comprehend and configure SAP Asset Accounting (FI-AA). This book follows a case-study
approach to make your learning easy. Efforts have been taken, throughout the book, to guide you stepby-step in understanding how to configure your SAP system, to meet your exact business needs. Each
configuration activity has been discussed with appropriate screen shots and illustrations to help you
‘see’ what is being discussed in that activity / step. You will see a lot of context-based additional
information across Chapters, for better assimilation of concepts / settings. The entire content of the
book has been presented as in SAP Implementation Guide with appropriate menu paths and
Transactions.
324 pages, 1st edition 2020
Formats: Kindle & Paperback
ISBN: 979-865383115
https://www.amazon.com/dp/B08B4VBW32
Latest Book by the Author
Configuring Financial Accounting in SAP ® ERP
(3rd Edition)
This is your comprehensive guide to configuring Financial Accounting in SAP ERP! Brush up on the old
standbys—Accounts Payable, Account Receivable, SAP General Ledger, and Asset Accounting—and
then dive in to Contract Accounts Receivable and Payable, Consolidation, Lease Accounting, Travel
Management, SAP Fiori, and much more. You’ll learn to set up your enterprise structure, use
maintenance tools, and ensure your implementation works for your unique business.
916 pages, 3rd, updated edition 2018
E-book formats: EPUB, MOBI, PDF, online
ISBN 978-1-4932-1723-6
https://www.sap-press.com/configuring-financial-accounting-in-sap-erp_4674/
Other Books by the Author
Title: SAP ERP: Quick Reference Guide
Edition: 2
Publisher: Mercury Learning & Information, 2020
ISBN: 1683920961, 9781683920960
Length: 500 pages
Title: SAP FI: Financial Accounting ERP ECC6, R/3 4.70
Edition: 2
Publisher: Mercury Learning & Information, 2017
ISBN: 1683921003, 9781683921004
Length: 350 pages
Title: SAP CO: Controlling
Edition: 2
Publisher: Mercury Learning & Information, 2017
ISBN: 168392102X, 9781683921028
Length: 350 pages
Title: Configuring Financial Accounting in SAP
Edition: 2, illustrated
Publisher: Galileo Press, 2014 (SAP Press)
ISBN: 1493210424, 9781493210428
Length: 907 pages
Title: Implementing SAP ERP Financials: A Configuration Guide
Edition: 2
Publisher: Tata McGraw Hill Publishing Co Ltd, 2013
ISBN-13: 978-0-0701-4297-8
Length: 965 pages
Title: SAP FI Financial Accounting: SAP ERP ECC 6.0, SAP R/3 4.70
Edition: 1, illustrated, reprint
Publisher: Mercury Learning & Information, 2013
ISBN 1937585646, 9781937585648
Length: 338 pages
Title: Customizing Financial Accounting in SAP
Edition: 1, illustrated
Publisher: Galileo Press, 2011 (SAP Press)
ISBN 1592293778, 9781592293773
Length: 792 pages
Title: Mastering SAP CO: Controlling
Edition: 1, illustrated
Publisher: BPB Publications, 2007
ISBN: 9788183333344
Length: 297 pages
Title: SAP FI
Edition: 1, illustrated
Publisher: BPB Publications, 2010
ISBN: 9788183333238
Length: 302 pages
Title: SAP FI/CO Demystified
Edition: 1, illustrated
Publisher: BPB Publications, 2008
ISBN: 8183332315, 9788183332316
Length: 370 pages
Title: SAP R/3 FI Transactions
Edition: 1, illustrated
Publisher: Jones & Bartlett Learning, 2007
ISBN: 1934015016, 9781934015018
Length: 530 pages
Title: Mastering SAP R/3 FI: Transaction Made Easy
Edition: 1, illustrated
Publisher: BPB Publications, 2007
ISBN: 8183331319, 9788183331319
Length: 472 pages
***