Iut240 SAP Fica
-
Upload
vamshi-gokul -
Category
Documents
-
view
539 -
download
45
description
Transcript of Iut240 SAP Fica
SAP AG 2003
IUT240 Contract Accounts Receivable and Payable
THE BEST-RUN BUSINESSES RUN SAP
© SAP AG 2003
IUT240Contract Accounts Receivable and Payable
SAP IS-Utilities/Customer Care Service 472 2005/Q1 Material number: 50072720
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
SAP AG 2003
Copyright 2003 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
All rights reserved.
Copyright
Trademarks: Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
SAP AG 2003
Prerequisites
Recommended:
IUT210: Master Data and Basic Functions
Basic knowledge of the Windows environment
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
SAP AG 2003
Target Group
ParticipantsProject managers responsible for implementing contract accounts receivable and payableThe project team in charge of modeling the business processesAdministrators responsible for optimizing processesConsultants preparing for implementation
Duration: 5 days
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
SAP AG 2003
Course Objectives
This course enables you to:
Understand the concept of contract accounts receivable and payable
Describe the options for customizing customer-specific requirements
Know how to use the Contract Accounts Receivable and Payable component efficiently
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-1
SAP AG 2003
Contents:Course goals
Course objectives
Course content
Course overview diagram
Main business scenario
Course Overview
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-2
SAP AG 2003
This course will enable you to:
Get to know the conceptual characteristics of the component FI-CA Contract Accounts Receivable
Execute the basic business processes
Make the necessary settings for configuring FI-CA
Understand the integration of FI-CA with other R/3 components and web-based SAP applications
Course goals
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-3
SAP AG 2003
At the conclusion of this course, you will be able to:
Modify FI-CA business processes to meet your individual needs
Execute and check these business processes
Describe the integration with other components and applications
Course Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-4
SAP AG 2003
Preface
Table of Contents IUT240
Unit 9 Clearing Control
Unit 10 Dunning / Collections
Unit 11 Interest Calculation
Unit 12 Deferral / Installment Plan
Unit 13 Other Business Transactions
Unit 14 Security Deposits
Unit 15 Integration
Appendix Industry-Specific Functions
Unit 1 Course overview
Unit 2 Introduction
Unit 3 Documents
Unit 4 Account Balance Display
Unit 5 Transactions and Account Determination
Unit 6 Payment
Unit 7 Returns Processing
Unit 8 Incoming Payments/Clarification Processing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-5
SAP AG 2003
Overview Diagram IUT240
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 1-6
SAP AG 2003
The accounts receivable accounting department in your company has to process a large amount of postings.
All business processes, such as payment processing, dunning notices, collection transfers and interest calculation must be executed as efficiently and correctly as possible.
The subledger also has to be transferred to the general ledger.
Main Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-1
SAP AG 2003
The life cycle of an open item
Accounting transactions
Master data
Customizing
Introduction
This unit will provide you with an overview of the following technical specifications in the subledgeraccounting component: Contract accounts receivable and payable:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-2
SAP AG 2003
At the conclusion of this unit, you will be able to:
Understand the objects involved in contract accounts receivable and payable
Understand the most important functions
Define the basic system settings
Understand the special features of the technical concept
Introduction: Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-3
SAP AG 2003
Introduction: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-4
SAP AG 2003
Your company has just implemented FI-CA as the subledger accounting.
As accounts receivable agent, you have to get to know the master data and its controlling characteristics as well as understand the basics of the new tool.
Introduction: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-5
SAP AG 2003
Invo
icin
g
Gen
eral
Ledg
er
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
The Life Cycle of an Open Item (1)
Open items can be posted in invoicing, dunning, or returns processing. Alternatively, open items can be posted manually in subledger accounting
Items relevant for the general ledger are regularly compressed and transferred to the general ledger. Cleared documents that have expired can be archived. Open and cleared items can be displayed in the account display function.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-6
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
The Life Cycle of an Open Item (2)
Payments are initiated either by the business partner (cash payer) or via payment runs (direct debit). Payments usually clear open items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-7
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
ArchivingSo
urce
ope
n ite
m
Sour
ce o
pen
item
/cha
rges
Returns
Payment (Cash or Direct Debit)
The Life Cycle of an Open Item (3)
In returns processing, cleared payments are reset, the source receivables are posted as debit items, and return charges are posted. Return charges can be bank charges that are passed on to the business partner or company charges.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-8
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Dunning
The Life Cycle of an Open Item (4)
Overdue items for cash payers or blocked items from direct debit payers can be dunned. Dunning charges or interest on arrears can be posted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-9
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Dunning
Interest Calculation
inte
rest
The Life Cycle of an Open Item (5)
Interest calculation can be carried out automatically in invoicing and in the dunning run, or it can be triggered manually. An interest document is posted.
Interest can be calculated for cleared items as well as for credit and/or debit items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-10
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
inte
rest
New
due
dat
e
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Deferral
Dunning
Interest Calculation
The Life Cycle of an Open Item (6)
Open documents can be deferred manually. A deferral can take place automatically in returns processing.
The original due date is retained in the case of a deferral. If the deferral date is reached and the item is still open, the original due date is used again for further business processes.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-11
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
inte
rest
New
due
dat
e
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Deferral
Dunning
Interest Calculation
Seve
ral O
Is
Inst. plan
The Life Cycle of an Open Item (7)
Payment (Cash or Direct Debit)
You can define an installment plan for open items. Interest calculation can be triggered via the installment plan.
The interest receivable is integrated into the installment plan.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-12
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
Seve
ral O
Is
inte
rest
New
due
dat
e
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Deferral
Dunning
Interest calculation
Inst. planWrite off
Doubtful flagsIndiv. value adj.
The Life Cycle of an Open Item (8)
Overdue items can be entered as doubtful, adjusted individually or written off.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-13
SAP AG 2003
Gen
eral
Ledg
er
Invo
icin
g
Item (cleared)OI (not due) OI (due) -- TimeAccount display
Archiving
Payment (Cash or Direct Debit)
Seve
ral O
Is
inte
rest
New
due
dat
e
Cha
rges
Sour
ce o
pen
item
Sour
ce o
pen
item
/cha
rges
Returns
Deferral
Dunning
Interest calculationWrite off
Doubtful flagsIndiv. value adj.inst. plan
Submit to coll. agency
The Life Cycle of an Open Item (9)
Items can be submitted to external collection agencies.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-14
SAP AG 2003
Optimized use of storage space due to a special type of document structure
Parallel mass runs
Business partner concept
Documents are assigned to business partners and contract accounts (and contracts - depending on the industry)Summarization of general ledger information (summary records)Agent-friendly processing of accounting transactions
Enhanced functionality
Basis for industry- and customer-specific functions
Why Contract Accounts Receivable and Payable as the Subledger?
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-15
SAP AG 2003
Current applications
Utilities (IS-U)
Insurance (IS-IS-CD)
Telecommunications (IS-T)
Waste disposal (IS-Waste)
Media (IS-M)
Public services and authorities (Public Sector)
Non-industry based FI-CA (FI-CAX)
Applications for Contract Accounts Receivable and Payable
IS-U: Industry Solution -Utilities IS-IS-CD: Industry Solution -Insurance - Collections and Disbursement IS-T: Industry Solution -Telecommunications FI-CAX is available as of Release 4.64
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-16
SAP AG 2003
BP
Account Account
ContractContractContract
IS-U
FI-CA
Central Objects
Account
Business partnerContains central data such as names, addresses, communication data and bank details
A natural person or legal entity with which your company has a business relationship
Contract accountContains control data such as payment methods, payment conditions, and dunning procedures
Object for open-item accounting in contract accounts receivable and payable
Is usually a group of contracts (division)
Contract (division-specific)
Document (items)
Electri-city
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-17
SAP AG 2003
Creditworthiness(automatic/manual)
Dunning procedure
Account class
Account determination
ID
Paymentterms
Clearingcategory
Interest key
Tolerance group
Elements of the Customer Profile
The business partner's payment patterns are reflected in his/her creditworthiness. The dunning procedure is stored at contract account level. The payment term determines the due date. This includes the due date for the cash discount. The clearing category controls payment allocation and the clearing of credit notes and receivables. The interest key is used to determine individual conditions for interest calculation. The account determination ID is used for determining general ledger accounts. The account class is not used by SAP programs and can, therefore, be used freely. The tolerance group defines limits for payment differences in the incoming payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-18
SAP AG 2003
Contains all company codes that can be used to post items to a contract account
A standard company code is allocated to each contract account
It is used for all postings for which no specific company code can be determined
It is also used for postings on account
A paying company code is allocated to a company code group. It is responsible for payment processing
Company Codes in the Contract Account
Company code group
Standard company code
Paying company code
Different entities in FI-CA
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-19
SAP AG 2003
Paymentterms
Interest key
Account determinationcharacteristic
Account class
Dunning procedure
creditworthiness(automatic/manual)
Paymentterms
FI-CA terms of payment FI terms of payment
Receivables : FI01CA01
Credit memos : FI02
FI01
FI02
Payment term 1
Payment term 2
Tolerance group
Terms of Payment
Contract account
Payment term:CA01
The payment term contains data for determining the due date and cash discount terms. The payment conditions of general ledger accounting are referenced. FI-CA supports the single-level cash discount procedure. You can store different rules for determining the due date for credit and receivables. The due date can automatically be corrected to a working day in connection with the factory calendar.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-20
SAP AG 2003
=
Dunningactivities
Returnsactivities
Writeoffs
Manualentries
Returns
AutomaticCredit-
worthiness
ManualpointsManualpoints
Influencing factors Effects
[ ∑ (Dunning * Weighting)+ ∑ (Returns * Weighting)+ ∑ (Write-offs * Weighting)+ ∑ (Manual entry * Weighting)+ ∑ Device locks IS-U]* credit worthiness factor / business partner
+
Creditworthiness 1
Device locksIS-U
Dunning notices
The business partner's payment patterns are reflected in his/her creditworthiness. You can override automatic determination of creditworthiness by entering a percentage-based weighting and creditworthiness data manually.
Creditworthiness is stored in the business partner's master data record. Creditworthiness can be updated manually or in the dunning run.
You can also enter creditworthiness data manually. This means that business transactions such as a customer complaint over unjustified returns (creditworthiness improvement) or 'black lists' from external credit evaluators (worsening creditworthiness) can also influence a business partner's creditworthiness.
Manual creditworthiness entries influence a business partner's creditworthiness the same as the entries created by the system. They can contain positive (worsening creditworthiness) and negative (improved credit worthiness) values. They can also be reversed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-21
SAP AG 2003
Display Business Partner's CreditworthinessCreditworthiness Edit Goto Extras System Help
Creditworthiness records
Creditworthiness history
Business Partner 4711Man. CreditworthinessCreditw.Factor 100Creditworthiness 75Date 04.01.2003
2003 2 Reminder 03/17/03 10 1000045
.....
2003 1 Reminder 03/03/03 5 1000045
Year Number Origin Date Creditw Cont. acct. Revers.
2003 1 Ret. paym. 02/17/03 5 1000044
2003 0 5 15 0 0 0 0 0 0 0 0 0
.....
Year JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
2002 0 0 0 0 0 0 0 0 0 0 0 0
Creditworthiness 2
Fixed CreditworthinessDate of FixingRelease Date
Dynamic calculation of current creditworthiness: Table of creditworthiness weighting TFK046A:
1 month - factor 4 2 months - factor 3 The following formula is used for the runtime 01/04/2003: 5 creditworthiness points (February) * 3 + 15 creditworthiness points (March) * 4 = 75 creditworthiness number
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-22
SAP AG 2003
Interest CalculationDunning Payment run
Postinglock
Lock Concept
Calendar
OI
CalendarAccount
OI
CalendarAccount
OI
CalendarAccount
Account
Postings to a contract account can be prevented by a central posting block. This prevents postings, clearing, reversal, and the cancellation of clearing for the involved account.
In addition, the open items in this account are not dunned. During online clearing processing, open items of blocked contract accounts are flagged with an
appropriate icon. It is not possible to activate these items. Individual business processes can also be prevented by blocks. You can set these locks for all items at contract account level, or at the level of an individual item.
Lock reasons can be defined in Customizing. All locks can be given a time limit. Once this limit has expired, the locks are deactivated. You can generate a list of business locks in the SAP application menu under Utilities Industry -> Contract Accounts Receivable and Payable -> For Contract Accounts -> Evaluation of Business Blocks. When you do this, you can select lock entries according to business partner, contract account, lock category, process and lock reason. The entries are output as a report list or ALV list and can be sorted according to business partner or contract account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-23
SAP AG 2003
Basic Customizing
IMGFinancial Accounting -> Contract Accounts Receivable and Payable
Organizational Units
Set Up Company Codes for Contract Accounts Receivable and Payable
Basic Functions
Application Area
Contract Accounts
Define Account Determination Characteristics
Open Item Management
Maintain Tolerance Groups
Postings and Documents
Document
Maintain Payment Terms
Define Company Code GroupsAssign Company Codes to Company Code Groups
To generate an FI-CA project for IS-U, IS-T, or IS-M, you must select both contract accounts receivable and payable and IS-U-CA, IS-T-CA or IS-M-CA in the component hierarchy during project generation.
When contract accounts receivable and payable is integrated in an industry add-on, the industry in question (for example, IS-U) must be activated (application area).
The overviews of the Customizing activities in this unit only represent an extract of the IMG. Customizing of the (central) business partner is stored in the "cross-application components".
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-24
SAP AG 2003
Yes
Yes
No
No
FI-CA program(Event)
FI-CA program(Continuation)
Customer-Specific
Industry-specific
Standardprogram
ISprogram
Customerprogram
Allows flexibilitywithout modifyingSAP programs
Technology: Event Concept (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-25
SAP AG 2003
Standard functionalityTFKFBMEvent
2000............
Text
Interest key determ.............
ABAP/4 modules
FKK_SAMPLE_2000............
Industry functionalityTFKFBSEvent
0350............
Text
Dunning Activities............
ABAP/4 modules
ISU_0350............
Customer functionalityTFKFBCEvent
...
...0260
...
...
Text
...
...Return charges
...
...
ABAP/4 modules
...
...FCS_0260
...
...
SAPxxxxx
program.
...event 2000
...
...event 0350
...
...event 0260
...
...
...
Technology: Event Concept (2)
Events can be managed using transaction FQEVENTS.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-26
SAP AG 2003
Indicators of large data volumes:
Target: Processing time can only be reduced if processes are split up
Parallel processing of the dataset
Payment run
Mass calculation of interest
Dunning notices
Correspondence print
Generation of bills
Technology: Mass Processes in FI-CA
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-27
SAP AG 2003
Job 1Business partner:
From 100,000 to 699,999
Job 1Business partner:
From 100,000 to 699,999
Job 1Business partner:
From 100,000 to 349,999
Job 1Business partner:
From 100,000 to 349,999
Job 2Business partner:
From 350,000 to 401,000
Job 2Business partner:
From 350,000 to 401,000
Job 3Business partner:
From 400,001 to 699,999
Job 3Business partner:
From 400,001 to 699,999
Job 1-3end at nearlythe same time
Job 1-3end at nearlythe same time
End of runtimeNot in parallel
RuntimeRuntime
Parallel runs
Technology: Splitting-Up Processes
Interval separation issupported by the system
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-28
SAP AG 2003
Intervalsize = 3
Intervalnumber = 4
Intervalnumber = 3
Intervalsize = 4
Interval_1 Interval_2Interval_3
Interval_1
Interval_2
Interval_3
Interval_4
BP_1
BP_3
BP_4
BP_5
BP_9
BP_19
BP_20
BP_30
BP_21
BP_35
BP_40
BP_31
Technology: Parallel Processing - Interval Creation
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-29
SAP AG 2003
Technology: Parallel Processing - Portioning
?? ??
Problems
How is the dataset to be portioned?The dataset is not distributed evenly:
Contract account numbers or business partner numbers are generally more concentrated in some number intervals than in others.
Contract accounts have varying numbers of items.
How many portions are to be assigned to each process?Each processing run does not contain the same processes or number of processes:
Processes on different servers have varying degrees of "performance".
Furthermore, performance is dependent on other processes that are being carried out at the same time.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-30
SAP AG 2003
mOIs
mOIs
mOIs
...
Interval1
Interval4
Interval9
Interval3
Interval6
Interval2
Interval10
Server AJob 1
Server AJob 2
... Server XJob n
Dispatcher formass data program
m = Block value
Technology: Parallel Processing - Realization
You can find documentation on planning batch processes in FI-CA and working with the FI-CA job container in OSS under the keyword FP-JOB.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 2-31
SAP AG 2003
Contract accounts receivable and payable is a sub-ledger accounting component that manages mass data.
It is used for processing open items.
The business partner and the contract account are the required master data.
Open items are managed as documents.
Contracts are realized in industry solutions.
Event management enables you to integrate customer-specific requirements into the SAP System without modifying SAP programs.
Parallel processes drastically reduce the runtimes of mass runs such as payment or dunning processing.
Introduction: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-1
SAP AG 2003
Contents:
Document types and number ranges
Document structures
Posting documents
Clearing documents
Integration with General Ledger accounting
Customizing
Documents
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-2
SAP AG 2003
How a document is structured
How to post, change and display documents
How to customize document numbers, document types and entry tools
The link between general ledger and sub-ledger accounting
Documents: Overview
This unit will provide you with an overview of the following in FI-CA:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Post documents in contract accounts receivable and payable
Specify entry help for document entry
Explain the use of reconciliation keys
Transfer the reconciliation keys to G/L accounting
Customize documents
Documents: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-4
SAP AG 2003
Documents: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-5
SAP AG 2003
Documents are usually created automatically in sub-ledger accounting. FI-CA documents can also be entered manually in special cases.
After extensive telephone consultation, you post a receivable to your business partner's contract account.
The totals records entered in FI-CA are transferred to G/L accounting during the day-end closing.
Documents: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-6
SAP AG 2003
Documents: Document types and Number Ranges
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-7
SAP AG 2003
Ext.Number range
010000000000 - 019999999999200000000000 - 209999999999310000000000 - 399999999999660000000000 - 699999999999760000000000 - 769999999999
.
.
.
Document Types for Single Processing
Document types
B1
Z2
V3
Z4
R5...
Description
Receivable
Incoming payment
Consumption billing
Payment
Repayment...
NR
01
20
31
66
76
Each document type is identified by a two-digit abbreviation in connection with a description. The document type classifies the document (for example, payment document). You can define for each document type whether it can be used for manual postings or as a document type for a payment or returns lot.
Each document type is allocated to a number range. Document number intervals are specified for the corresponding document type using the number range. The number range also determines whether document numbers are assigned internally or externally.
Document number ranges are specified depending on the volume of the business processes.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-8
SAP AG 2003
NRIndividual
31
NRMass
F1F2F3...
Ext.Number ranges
31 310000000000 to 319999999935 350000000000 to 359999999936 360000000000 to 3699999999
....
F1 320000000000 to 3299999999F2 330000000000 to 3399999999F3 340000000000 to 3499999999
....
Doc. type
V3
Number Ranges for Mass Processing
NRIndividual
3536...
In addition to the document number ranges for manual posting, extra number ranges must be defined and allocated for business transactions that result from parallel mass processing (for example, invoicing or payment run).
The key for the mass processing number range must begin with a letter. The parallel background processes take their document numbers from these number range intervals. As a result, they must be defined depending on the volume of business processes and the number of parallel processes.
If individual postings of a certain category are frequently executed in dialog (for example, cash desk or cash journal), and if all postings are executed with the same document type, users may have to wait because all users access the same number range when document numbers are assigned. To avoid or reduce this period of waiting, several number ranges for individual postings can be allocated to a document type.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-9
SAP AG 2003
Documents: Document Structures
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-10
SAP AG 2003
1:n
Document header
010023459101
General ledger items
010023459101
Doc. number: 010023459101Posting date: 02/22/2003Doc. type: F1 Currency: USDReconciliation key: 03032701/SK1
010023459101
Item 0001
BPART CCODE Due Date Trans. Amount4711 U100 02/22/03 0100-0011 232.00
CCODE G/L Acc. BA Cost Cent. AmountU100 800000 200.00U100 175000 32.00
1:n
Business partner items
Structure of a FI-CA Document (1)
The document header contains general data for the accounts receivable/payable document such as: the document number, document category, document date, posting date, currency, and reconciliation key. Data on the person making entries and on the origin are stored in the administrative data of the document header.
Data relevant to posting is stored in the business partner items: Data on the partner/contract, general ledger data (receivables account), data on the receivables amount, specifications on the due date, dunning and clearing data, cash management and forecast data, and other data.
Information on offsetting posting is stored in the offsetting item. This normally means the line items for revenue posting(s) and the tax posting line items.
Offsetting items and tax lines are created automatically, so only the business partner items must be created.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-11
SAP AG 2003
Document header
010000234591
General ledger items
010000234591
Document number: 010000234591Posting date: 01/03/03Doc. type: F1 Currency: USDReconciliation key: 03032701/SK1
010000234591
Item 0001
BPART CCODE Due Date Trans. Amount4711 U100 03/01/03 0080-0011 116.00
CCODE G/L Acc. BA Cost Cent. AmountU100 800000 100.00U100 175000 16.00
Repetition item
Repetition group 01Repetition item 03010000234591
Due: 03/03/03Due: 02/03/03Due: 01/03/2003
Business partner items
1 :
n
1 : n
1:n
Structure of a FI-CA Document (2)
Repetition documents are put into repetition groups. Budget billing plans and installment plans are represented in IS-U as documents with repetition groups.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-12
SAP AG 2003
Source receivable
010023459101
010023459101
Doc. number: 010023459101Posting date: 02/22/2003Doc. type: F1 Currency: USDReconciliation key: 03032701/SK1
010023459101
Item 0001
BPART CCODE DueDate Trans. Amount4711 U100 02/22/03 0100-0011 232.00
CCODE G/L Acc. BA Cost Cent. AmountU100 800000 200.00U100 175000 32.00
Doc.number: 012204445552Posting date: 03/05/03Doc. type: Z2 Currency: USDReconcil. key: ZE0503200302
Payment
CCODE G/L Acc. BA Cost Cent. AmountU100 113100 232.00
012204445552
012204445552 Item 0001
012204445552
Business partner item
General ledger item Bank offsetting item
Structure of a Payment Document
The clearing document that can be posted, for example, during incoming payment, only consists of a document header and the offsetting item(s).
The following information is stored in the offsetting items: the payment amount, the corresponding general ledger account, and information on the cleared document.
The document number of the clearing document, the clearing date, and the clearing amount are stored in the business partner items of the cleared document.
This means that both documents are linked as long as the clearing exists. The payment document does not maintain a business partner item since all information on the business partner item can be viewed in the linked, cleared receivables document.
If clearing is reversed, the connection between the clearing document and the receivable is deleted, and the payment document is given a new business partner item with all posting information.
The clearing information is stored in the clearing history, even if clearing is reversed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-13
SAP AG 2003
Source receivable
010023459101
010023459101
Doc. number: 010023459101Posting date: 02/22/03Doc. type: F1 Currency: USDReconciliation key: 03032701/SK1
010023459101
Item 0001
Item 0001
Subitem BPART CCODE Due Date Amount0 4711 U100 02/22/03 132.00
Item CCODE G/L Acct. Cost center Amount0001 U100 800000 200.000002 U100 175000 32.00
Doc.number: 012204445552Posting date: 03/05/03Doc. type: Z2 Currency: USDReconcil. key: ZE0503200102
Payment
CCODE G/L Acc. BA Cost Cent. AmountU100 113100 100.00
012204445552
012204445552 Item 0001
Business partner item
Offsetting item Bank offsetting item
Subitem BPART CCODE Due Date Amount1 4711 U100 02/22/03 100.00
Cl. doc Cl. date Cl. amount012204445552 03/05/2003 100.00
Document Structure for Partial Payments
If the incoming payment only results in a partial clearing, the item of the source receivable document is split into a cleared partial item and a partial item that is still open. The clearing data, that is the amount of the partial payment and the document number of the payment, are stored in the cleared partial item.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-14
SAP AG 2003
Statistical receivable
010000234001
Doc.number: 010000234001Posting date: 02/22/2003Doc. type: F1 Currency: USDReconciliation key: 03032702/SK1
010000234001
Item 0001
BPART CCODE Due Date Trans. Amount4711 U100 02/22/03 0100-0011 10.00
Statistical business partner item
Only business partner items exist
Structure of a Statistical Document
Statistical documents only consist of a document header and business partner items. These documents are not forwarded to the general ledger.
Statistical postings make it easier to deal with uncertain receivables, since these postings are not transferred to the general ledger and, as a result, are easier to reverse if they are not paid. A typical example of this are budget billing receivables in IS-U. This is because budget billing amounts are not normally backed up by a bill and, if they are not paid, are more difficult to collect than amounts based on a bill. Furthermore, in the case of budget billing requests, value-added tax is only due when the budget billing amount is paid and the receivable is posted in the general ledger. Dunning charges are also another example of amounts that are often not paid, or documents from an installment plan since the underlying source receivables have already been posted in the general ledger.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-15
SAP AG 2003
Source receivableDoc.number: 010000234001Posting date: 02/22/2003Doc. type: F1 Currency: USDReconciliation key: 03032702/SK1
Payment
Item CCODE G/L Account Amount0001 U100 113100 10.000002 U100 800000 -10.00
Offsetting items
Cl. doc Cl. date Cl. amount012204445553 03/05/2003 10.00
Item BPART Trans. Stat. key Amount0001 4711 0010-0010 G 10.00
Item BPART Trans. Stat. key Amount0001 4711 0010-0010 G 10.00
Business partner item
Cl. doc Cl. date Cl. amount012204445553 03/05/2003 10.00
Item BPART Trans. Stat. key Amount0001 4711 0010-0020 10.00
Business partner item (after payment)
Customizing Item CCODE BPART Amount0001 U100 4711 10.000002 U100 4711 10.00
Cleared items
Payment for Statistical Items
Doc.number: 012204445553Posting date: 03/05/03Doc. type: Z2 Currency: USDReconcil. key: ZE0503200102Clearing info: "Real items also cleared"
Stat. key MTR STR => MTR STR Restr.G 0010 0010 0010 0020
Business partner item (beforepayment)
When statistical items are cleared (for example by a payment), the clearing information is stored in the statistical document. A "real" business partner item (that is relevant for the general ledger) is created simultaneously in the payment document and cleared immediately. This item transaction is determined from Customizing. Revenue and tax lines are added to the offsetting item.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-16
SAP AG 2003
Documents:Posting documents
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-17
SAP AG 2003
Fast entry of posting information
Variable entry format
Flexible, screen customizing
Clear representation
Integration of clearing logic
No restrictions on posting logic
Goals of Document Entry
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-18
SAP AG 2003
Posting date: 02/23/2003 Document type: 01 Currency: USDDocument date: 02/23/03Reconciliation key: 03033101/SK1
Calculate automatically: Taxes are determined from the business partner item
Post Document: Entry Point
Screen Variant RECHNUNGCompany code U100
Tax:Manual entryCalculate automatically
Jurisdiction codeNet receivables
Line layout:Business partner item: SAPGeneral ledger item: SAP
Items
You can use the screen variants defined in Customizing to design the screens to execute the functions for the business transactions mentioned above (for example, creating a manual bill). You can select the fields you want hidden when the functions for posting, changing or creating a document are executed. For example, it makes sense to hide the fields containing information on the dunning procedure from the document entry. Users can store their preferred screen variants in the central user-specific settings in Customizing. This setting can be changed in the initial screen and during document entry.
In addition, certain fields can be hidden (client-dependent) by Customizing as long as they are not needed in business transaction.
In the initial screen for document entry, the company code is used as the default value for the line items. You can overwrite it there.
When posting with tax, you can select whether the tax rate is entered manually or automatically determined and calculated from the business partner item.
The net receivables field specifies that the amount entered is treated as a net amount; otherwise the amount entered forms the basis of tax calculation as a gross amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-19
SAP AG 2003
Document date: 02/23/03 Document type: 01 Posting date: 02/23/03 Currency: USD
Header data
List Entry: Business Partner Items
Business partner itemsBPART CCODE Net due date CACCT Mtrans STrans Amount Contract
1740 U100 03/23/03 634 6000 0020 232.00 531
o SAP Standard o ZAP line layout with text
Line layout
...
You can select various freely definable line layout variants in the list for entering business partner items. Fields included in a variant cannot be longer than 250 characters.
Screen variants are specified in the customizing of the documents. Release 4.71 has been converted to table control. As a result, variants that existed previously, are no longer valid. However, they can be migrated using the report RFKK_VAR_MIGRATE_DOCUMENT. If you want to process a document but no current variables exist at this time, the system automatically generates the SAP variant. You can use this to process the document items. The previous SPA/GPA parameters 802 and 803 have been replaced by the new parameters 802TC and 803TC. In the initial screen of the Post Document transaction, you can enter the two line layout variants in the line layout for list entry group box. When you choose the Display/Change Settings function, the system displays a dialog box. You can select and save the variants in this dialog box using the input help. The variants are saved in the user parameters.
You can branch to the detail view of document entry by double-clicking on a line. The detail view contains all document fields that can be maintained..
One or more items can be posted for one business partner. You can also enter items for different business partners within the same document. These items are posted in one document number.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-20
SAP AG 2003
Doc.number: 010000234592Posting date: 02/22/2003Doc. type: F1 Currency: USDReconciliation key: 03033101/SK1
BPART CCODE Due Date Trans. Amount4711 U100 02/22/03 6000-0020 600.00
Business partner itemsItem 0001
Item 0002
BPART CCODE Due Date Trans. Amount4711 U100 02/22/03 6000-0020 500.00
Document header
Tolerance group CA01Company code U100Currency: USDUpper limit for posting:Max. amount per document: 1000.00Max. amount per item: 600.00
Amount checkItem level Document level
599.00 < 600.00 o.k.
500.00 < 600.00 o.k.
599.00+ 500.001099.00
Posting not possible because amount limit exceeded
Customizing:
Tolerance Groups for Amount Limits
You can define tolerance groups for amounts in Customizing. Users can then be assigned to these groups. The tolerance groups specify that users can only post documents up to a certain amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-21
SAP AG 2003
Specification ofexchange rate
Determination ofexchange rate
Amount in local currency
92.00 USD
100.00 USD
Posting: Foreign Currency
The exchange rate can either be determined from the rates stored in the system, or by an entered exchange rate when entering a document in a foreign currency.
If you want to calculate the exchange rate of a specific date, you must enter this exchange rate date. If you do not, the system uses the current rate.
If an exchange rate is entered, it is compared to the rates stored in the system. If the rates differ, a message is displayed.
An exchange rate can only be entered by users for whom a local currency is stored in their user-specific settings for FI-CA.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-22
SAP AG 2003
Payment - in CCODE U100 for:
Contract 2 - CCODE U200 50.00 USD
Contract 1 - CCODE U100 -100.00 USD
(1) 100.00
(1) 50.00
Bank clearing in U100
(3a) 100.00
Payables for CCODE U200
Receivable for CCODE U100
100 (3a) 50.00 (4)
(2) 150.00(3b) 50.00
Business partner 4711Contract account 1234
Receivable Water
Receivable Waste Water
Contract 1 inCCODE U100
Cross-Company Code Posting
(4) 50.0050 (3b)Contract 2 in CCODE U200
The business partner is not allocated to a company code. The information on the leading company code is stored in the contract account. Incoming and outgoing payments are handled via the responsible company code.
Posting examples: (1) Debit entry (without revenue and tax) (2) Cash receipt in company code U100 (without bank account display) (3a) Payment allocation in company code U100 (3b) Payment allocation in company code U200 (4) Company code U100 owes a payment to company code U200. (4) Company code U200 receives a payment from company code U100. The posting (4) is created with the incoming payment.
Cross-company code posting must be set in the central user settings. The clearing accounts for payments/receivables are specified in customizing. One or more documents are posted in each affected company code during the transfer of the summary records to general ledger accounting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-23
SAP AG 2003
Document header
010000234593
Doc. type: FA010000234593
Item 0001
BPART CCODE Due Date Trans. Amount4711 U100 02/22/03 6000-0020 232.00
1:n
Business partner items
Non-periodic postingX
Change / DisplayChange / Display
Alternative accountExpense Revenue
Post Document: Additional Functions
DT blocked formanual posting
AlternativeG/L account
AlternativeVAT
determination
Billing period 01/05/02
Document types can be blocked for manual posting. The non-periodic posting indicator means that an non-periodic posting takes place in an alternative account. The indicator specifies that the posting is not for the current posting period, however is posted there.
The start of the billing period, to which the previous open items relate. Use: The business partner can be informed of the date in payment notifications, account statements,
direct debits or other correspondence. The date is only used for information purposes when displaying documents or accounts.
For utility and telecommunications companies, this date is used as well as the posting date for manual posting for determination of tax on sales and purchases. If postings relate to a demand period during which the tax on sales and purchases was changed, the posting date is most often unsuitable. In such cases, this date can be specified. It is used to determine the tax on sales and purchases.
Individual documents can be printed using the correspondence component (correspondence type 014).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-24
SAP AG 2003
Documents: Clearing Documents
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-25
SAP AG 2003
Exchange rate difference
Foreign currencies
Charges receivableClearing statistical
charges
Down payment
Tax after cash discount
clearingdocument
Minor differencesWrite-off
Clearing: Generation of Line Items
Cash Discount Expense/Revenue
Various new line items can be generated by allocating clearing amounts to open items. Differences in exchange rates must be posted during the clearing of foreign currency documents. If a cash discount is granted and deducted, you must post the cash discount paid. Minor differences that do not exceed tolerance limits are posted as paid or received. A real charges receivable is posted and cleared during clearing of a statistical charges. A down payment must be posted for the clearing of a down payment request. Cash discount postings or revenue from charges can be subject to tax. The tax amount is automatically calculated and posted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-26
SAP AG 2003
010000234591
Source receivable
Document number: 010000234591Posting date: 02/22/03Doc. type: FA Currency: EUR
Doc.number: 012204445552Posting date: 03/05/03Doc. type: Z2 Currency: USD
Payment
012204445552
Clearing: Different Currency
It is possible to clear open items in a different currency. For example, receivables can be cleared in EUR with an incoming payment in USD.
All selected open items are recalculated in the clearing currency if they have different document currencies. The calculation is carried out in two steps using the posting date of the clearing document:
- Document currency -> Local Currency / Local Currency -> Clearing Currency.
- In this way, maintaining the rates for all currency pairs is not necessary. The system uses the current average rate for the conversion according the rate table. If you have agreed upon different rates or amounts with the customer, differences will then appear during the conversion. In Account Maintenance (menu: Account -> Maintenance) in the screen Account Maintenance: Process Open Items, you can change the converted amounts and prevent these differences.
The clearing currency and the clearing amount are stored in a cleared item.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-27
SAP AG 2003
Header dataDocument date: 02/23/03 Document type: F1 Posting date: 02/23/03 Currency: USDDocument no.: 123456789
Summarized business partner items:
CCODE Partner CACCT Contract MTrans STrans DueDate AmountU100 1740 634 531 6000 0020 02/22/03 232.00
Document Overview
Summarized general ledger items
CCODE General Ledger Long Text AmountU100 800000 Other receivables 200.00U100 175000 Tax 16% 32.00
Header Business partner item General ledger item
The document overview displays all entered document items on one screen. You can use table control to adjust the structure of aggregated items to meet your individual needs.
By double-clicking on the individual items or selecting the appropriate button, you can branch to the detailed display of the document items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-28
SAP AG 2003
Documents: Integration with General Ledger Accounting
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-29
SAP AG 2003
Summary Records"Transfer unit" for postings from sub-ledger to general ledger accountingThe documents from sub-ledger accounting are consolidated into summary recordsSummarization criteria include:
Posting dateAccount assignment data (G/L account, cost center ...)
Integration with FI General Ledger: Definitions
Reconciliation keyKey under which summary records are recorded for transferring
FI-CA documents to the general ledger Automatic determination in the case of mass postings (such as
payment runs)Manual entry in the case of single postings (when posting a
document for example)Default values for individual postings
Other summarization criteria include: - Company code - Business area - G/L account - Currency - Additional account assignments of controlling such as cost center, order or profit center.
You can prevent summarization with other document items by using the Single document indicator. If you set this indicator, normal summarization of items in the summaries record will not take place. If this indicator is set for a document, a separate document item is created in the transfer document for general ledger accounting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-30
SAP AG 2003
Lot (payment or returns lot)XXXXXXXXXXXX Default: lot name
Payment runYY DDD NNNNN PP 03 101 PAY01 01 (PAY01: Na
Interest runYY DDD NNNNN PP 03 101 INT01 01 (INT01: Name
IS-U InvoicingYY DDD HHH LLL 03 101 R04 0003 (R04: fixed source)
YY/DDD = Year/day in year LLLL = Run ID
SSS = Source PP = Number of process
NNNNN = Name
Reconciliation Key Structures - Automatic Determination
Various business processes create a reconciliation key in the system. The reconciliation key is identified by the current day in the business year - which is derived from the creation date - and the source or name.
Reconciliation keys that have been created automatically are closed automatically at the end of the business process.
The system can also propose reconciliation keys for manual business transactions (post document, payment at cash desk ...). In order to do this, reconciliation groups for default values must be maintained in Customizing. These reconciliation keys can be accepted or overwritten. You must close them manually before transfer to the general ledger.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-31
SAP AG 2003
Mass closing
User (group) dependent reconciliation key
Source:Yes/no?
03031101/SK1
Event: 1113
Tools: Reconciliation Keys
Reconciliation key: 03031101/SK1Itemization for gen. ledger documents
OI 4711 - BP1 - USD 2500.00OI 4713 - BP2 - USD 800.00OI 4811 - BP3 - USD 760.00...
SD01020508-010803-0511-010602-01TK050201TK050201...
Delete Close
The reconciliation key can be can be structured user (group) specifically for online postings. User-dependent and user-independent reconciliation keys can also be proposed for origin keys stored in Customizing. However, for this to happen, the SAP function modules FKK_SAMPLE_1113_USER or FKK_SAMPLE_1113 must be used in event 1113.
During mass closing (transaction FPG4), the system closes all keys that are not reserved for a specific group of postings, for example postings for a payment run or a payment or returns lot.
In addition to this, keys that are reserved for posting invoicing documents from Sales and Distribution (SD) are also closed
If necessary, you can also delete reconciliation keys that have been created but are not used. To do this, select the Delete Unused Open Keys or the Delete Unused Closed Keys parameter.
Document itemization for reconciliation key (RFKKABS30): The report selects all FI-CA documents posted under a reconciliation key The FI-CA totals records are selected according to the selection criteria. The corresponding FI-CA document line items are selected and sorted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-32
SAP AG 2003
Reconciliation key03040101/SK1Doc. 12 Amount 116.00
Post document
FI-CA Documents
Summary RecordsReconciliation key
03040101/SK1
FI documentsReference key03040101/SK1*
Reference transactionFKKSU
140000 D 34840 140000 348.00
FI-CA Document - Summary Record - FI Document
Doc. 13 Amount 232.00
800000 C 300175000 C 48
TransferReconciliation key
50 800000 300.00
50 175000 48.00
Requirement for transferring a summary record: reconciliation key with "closed" status Display transferred totals records in FI: Transaction FB03 (Document Display) Document list and enter reference transaction FKKSU and the reference key reconciliation key +* in the selection parameters.
Reference in FI document header: Reference key = reconciliation key + sequential transfer number set during the transfer
Checking/correcting summary records Reasons:
- due to reconciliation differences between sub-ledger and general ledger - due to technical problems (such as database problems, termination of a payment run)
Procedure: - Checking summary records (RFKKABS1/RFKKGL20) - Correcting summary records (RFKKABS2) - Transferring summary records to the general ledger in correction mode (RFKKGL00) (provided
that the summary record has been transferred already)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-33
SAP AG 2003
Document 120001234
Reference key: 03041001/SK1*
PDATE 04/10/0340 140101 500.0050 800003 500.00
Document 10004713Recon. key. 03041001/SK1PDATE 04/11/03CCODE U100Partner 99000129Amount 600 USDRev. account 800003
Document 10004712Recon. key. 03041001/SK1PDATE 04/10/03CCODE U100Partner 99001148Amount 300 USDRev. account 800003
Document 10004711Recon. key. 03041001/SK1PDATE 04/10/03CCODE U100Partner 99000123Amount 200.00 USDRev. account 800003 Reference key
03041001/SK1
PDATE 04/10/03D 500.00 USD 140101C 500.00 USD 800003
PDATE 04/11/03D 600 USD 140101C 600 USD 800003
Reference Documents: FI-CA - Summary - FI
Document 120001235
Reference key:03041001/SK1 *
PDATE 04/11/0340 140101 600.0050 800003 600.00
Documents in a reconciliation key are cumulated according to posting date or general ledger account. Transfer of summary records with different posting dates leads to the creation of a general ledger document for each posting date.
The reconciliation key is transferred according to the key date. If the reconciliation key contains documents with posting dates in the future, then the reconciliation key is only partially transferred to general ledger accounting on the key date. The rest of the key is transferred if the future posting date is earlier than or the same as the transfer date.
If the number of lines in the general ledger document exceeds the maximum number of documents lines allowed in financial accounting, the document is split and another document is created.
The required "zero balance" is posted via a transfer account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-34
SAP AG 2003
Docs. Subledger Reconciliation Key Docs. General Ledger
Transfer
Reconciliation
Reconciliation
Open itemlist
RFKKGL20
RFKKGL00
RFKKOP04
RFKKABS1
Reconciliation: FI-CA with the General Ledger
Σ
Report RFKKGL00 transfers the summary records accumulated in the reconciliation keys to the general ledger.
Program RFKKGL20 is used to reconcile between the general ledger and contract accounts receivable and payable. It reads from the general ledger the documents that were posted by transfer of the FI-CA summary records in the general ledger and compares them with the FI-CA summary records. Differences are displayed in color and marked with a red traffic light. You can select the corresponding menu option in the output list to correct the differences that occurred, for example, if posting was terminated, and that you were not able to subsequently post . If you select the correction run flag, the system executes the correction automatically in background processing.
The report RFKKABS1 (check totals records) checks whether the FI-CA postings totals match the totals of the associated FI-CA documents and that the balance of the FI-CA documents is zero. The program displays any discrepancies between the posting totals and the FI-CA documents. The differences can be corrected in dialog or in background processing. If FI-CA documents do not have a balance of zero, the corresponding document numbers and reconciliation keys are output. These reconciliation keys cannot be exported and cannot be corrected automatically.
Report RFKKOP04 generates a key date-specific list of open items for business partners in FI-CA. You can use the report during the final work (month, quarter, year) or for reconciliation purposes.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-35
SAP AG 2003
FI-CA Documents
Reconciliation: General Ledger Documents
12/0012/0012/002/2003
Balance/Posting period
General ledger accounts
RFKKGL30
Reconciliation key: 03021101/SK1Itemization for general ledger docs
OI 4711 - BP1 - USD 2500.00OI 4713 - BP2 - USD 800.00OI 4811 - BP3 - USD 760.00...
12/0012/0012/002/2003
FI documents
Σ
Reconciliation key
Report RFKKGL30: The program displays the documents from contract accounts receivable and payable (FI-CA) that have been transferred to the general ledger (FI) as totals records. The general ledger documents are read according to the selection criteria. The corresponding totals records and document lines from contract accounts receivable and payable are selected and sorted.
Report RFKKGL30 guarantees the possibility for revision in contract accounts receivable and payable; this means that you can use it any time to determine and display items and documents in contract accounts receivable and payable (subledger) from the general ledger document (transfer document). A general ledger document can, therefore, be explained by the items in the subledger at any given point in time.
You can use the report RFKKABS6 to reconcile the general ledger accounts: The program outputs postings that were transferred to the general ledger. The postings are displayed as an overview of balances or as line items with the corresponding posting date and, if available, an alternative posting date.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-36
SAP AG 2003
BalancesOpen items
FI-CA
Reconciliation: Open Items
BalancesReconciliation
accounts
RFKKOP10
Σ
BalancesReconciliation key
Not yet transferred+
Report RFKKOP10 reconciles contract accounts receivable and payable (FI-CA) with the general ledger (FI). It reconciles the current balance for all reconciliation accounts or the reconciliation accounts specified as well as on sales and purchase tax clearing accounts. The following balances are determined per company code, business area and reconciliation account:
- Balance of current open items in contract accounts receivable and payable The tax on sales/purchases clearing account is also useful for down payments. Statistical items are not evaluated.
- Current balance of reconciliation accounts for the general ledger in contract accounts receivable and payable .
- Balance of reconciliation keys in contract accounts receivable and payable that have not yet been transferred
- Balance of adjustment totals records in contract accounts receivable and payable that have not yet been transferred.
Report RFKKOP10 creates a totals sheet with the balances for the reconciliation accounts. The Status field in the list specifies differences per company code, business area and reconciliation account. The Missing OIs field informs you that a reconciliation account in the general ledger has a balance, but no corresponding open items were found in contract accounts receivable and payable. If you want to analyze in more detail which items or business partners are involved in specific differences, start report RFKKOP04 with the relevant reconciliation account as current OI list.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-37
SAP AG 2003
Documents: Customizing
Document Types and Number Ranges
Document Structures
Posting Documents
Clearing Documents
Customizing
Integration with General Ledger Accounting
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-38
SAP AG 2003
Documents: Customizing (1)
IMG Contract Accounts Receivable and PayableBasic Functions
Postings and Documents
Maintain User-Specific Posting Settings
Basic SettingsMaintain Central Settings for Posting
Maintain Document Number Ranges
Maintain Default Document Types for.....Screen Preparations
Select Fields to be Hidden (at client level)
Document
Maintain Document AssignmentsMaintain Document Types and Assign Number Ranges
Define Screen Variants for Document Posting
Select Screens to be Hidden for Screen Variants...
In the central posting settings, you can specify the functions you want to be used for posting and processing documents. Whether or not the functions entered are required (for example, installment plans, interest posting during clearing) depends on the business transactions that are processed.
Certain settings for document entry, such as the entry variants, release to cross-company code postings and to foreign currency postings, as well as tax information for account display are stored in the central user settings.
To configure the documents, the document number ranges must be assigned, document types defined, certain document type specifications for business processes and screen variants must be defined.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-39
SAP AG 2003
Documents: Customizing (2)
IMG Contract Accounts Receivable and Payable
Define Screen Variant for List Entry of Business Partner Items
Include own Fields in Detail Screens
Define Screen Variant for List Entry of General Ledger Items
Define Posting Specifications for General Ledger Transfer
Define Default Values
Maintain Rules for Reconciliation Key Default Values
IntegrationGeneral Ledger Accounting
...
Define Default Values for Document Entry
Maintain Reconciliation Groups for Default Values
...
The posting keys for credit and debit items, as well as the document type for posting the G/L account when the totals records are transferred to the general ledger (FI-GL) are stored in the posting specifications for the general ledger. It must be possible to post the document type on an intercompany basis. The transfer accounts for the general ledger transfer must also be entered here.
Prerequisites - The required general ledger accounts must be created (go to the IMG structure and select Financial
Accounting -> General Ledger Accounting -> G/L Accounts). - The necessary document types must be maintained (go to the IMG structure and select Financial
Accounting -> Financial Accounting Global Settings -> Document -> Document Header).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-40
SAP AG 2003
Documents are usually generated automatically in contract accounts receivable and payable:
From incoming payment postings, reversals
From the dunning process, interest calculation
From invoicing processes (IS-U, IS-M-SD, external billing systems)
Documents can also be entered manually in special cases
Contract accounts receivable and payable has its own document structure.
Documents: Summary (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-41
SAP AG 2003
Individual FI-CA postings are cumulated into summary records by specifying reconciliation keys.
Regular transfer of the summary records (for example, on a daily basis) generates postings in general ledger accounting.
Reconciliation reports support you when you check and reconcile the FI-CA subledger with the general ledger.
Documents: Summary (2)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-42
Documents - Exercises
Unit: Documents Topic: Entering Documents in the System, Transferring the Summary Records to G/L Accounting
Enter a document in the system and transfer the summary data to G/L accounting.
Documents are usually created automatically in the subledger accounting of FI-CA. Documents can also be created manually in special cases.
The summary records are transferred to G/L accounting during day-end closing.
First of all, save the following parameters on the Parameters tab page in your user profile under System User Profile Own Data:
BUK: U100 (Company code) FWS: EUR (Currency key) 8P3: (post without jurisdiction code) If you are taking part in a course without US scenarios.
BUK: U300 (Company code) FWS: USD (Currency key) 8P3: X (post with jurisdiction code) If you are taking part in a course with US scenarios.
Make sure you use uppercase letters.
‘Your’ business partners have the following number ranges: PICA… For business partners without US scenarios PI… For business partners with US scenarios
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-43
1-1 Post two receivables – one amount of EUR (USD) 200 and one amount of EUR (USD) 300 for the business partner you have been assigned:
1-1-1 Which document type does the system propose? ______________
1-1-2 Where can you define the proposed document type in the system? ________________________
1-1-3 Use the following data to enter the documents: Document date: 04.05.03 Posting date: 04.05.03 Reconciliation key: Proposed by system Currency: EUR (USD) Company code U100 (U300) Taxes: Calculate automatically → x
Enter the additional data with function ”New business partner item”: Business partner: PICA0210## (PI0202C0##) Contract account: PICA0210## (PI0202C0##) Transaction: 6000 / 0020 Amount: 200.00 Repeat this transaction for the same business partner with amount EUR (USD) 300.00. Write down the document numbers: ___________________________________________________
1-2 Which payment date (due date) was determined for the receivable? ___________
1-3 How can you control the determination of the payment date? ____________
1-4 Display your documents in the account display.
Use the following information: Business partner: PICA0210## (PI0202C0##)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-44
Company code: U100 (U300) List category: All items Line layout: Standard line layout – account display
1-5 Transfer to general ledger accounting
1-5-1 Display the documents. Where can you find the corresponding reconciliation key in the document? Write down the reconciliation key: _________________________________________________________
1-5-2 Display the reconciliation key (choose a different screen variant if necessary) and close the reconciliation key for further postings. Which status does the reconciliation key have now? _________________________________________________________
1-5-3 Once you have closed the reconciliation key, transfer this reconciliation key to G/L accounting.
Use the following information: Reconciliation key: Proposed by system Test run: SPACE List of layouted FI documents: X
1-6 Status of reconciliation key
Which status is assigned to the reconciliation key after the transfer to general ledger accounting? _______________________________________________________________
1-7 G/L accounting document
Go to financial accounting and display the document that was generated in G/L accounting. Document number: __________________________________________________ Where in the G/L accounting document can you see the reference to FI-CA subledger accounting, and where is the reconciliation key from FI-CA subledger accounting saved? ____________________________________ _______________________________________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-45
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-46
Documents: Solutions
Unit: Documents Topic: Entering Documents in the System
1-1 Post document
1-1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post
The system proposes document type AB.
1-1-2 The document type is defined in Customizing in the IMG.
Choose: Tools → Customizing → IMG → Edit Project → SAP Reference IMG.
Choose the following path in the SAP Reference IMG:
Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Define Default Values → Define Default Values for Document Entry.
Document type AB has been defined here as the default value.
1-1-3 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post
and enter the data specified in the exercise.
1-2 The receivables are due immediately based on the posting date.
1-3 The payment date is determined using the payment conditions in the contract account.
1-4 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-47
1-5 Transfer to general ledger accounting
1-5-1 The reconciliation key is saved in the Document Header, in the Reconciliation Key field.
1-5-2 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Reconciliation Key → Close
Choose function Goto → Totals records.
Choose function Reconciliation key → Close
The status changes from
Reserved for individual postings
→ Postings can be made
to:
Reserved for individual postings
→ Postings can no longer be made.
1-5-3 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → Forward Postings → Execution→ Transfer to General Ledger
1-6 Choose: Utilities Industry Contract Accounts Receivable and Payable Document Reconciliation Key Display
The status is:
Postings can no longer be made Transfer to general ledger is complete
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 3-48
1-7 Choose: Accounting Financial Accounting General Ledger Document Display Document List
Enter FKKSU as the reference procedure. Enter the reconciliation key with “*” as the last character for the reference key.
Choose Program Execute.
FKKSU is saved as the Reference Procedure and the Reconciliation Key is saved as the Reference Key in the document header of the G/L accounting document.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-1
SAP AG 2003
Contents:
Structure of the account balance display
Display and navigation options
Customizing
Account Balance Display
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-2
SAP AG 2003
The structure
The entry criteria
The functions and flexibility
Customizing
Account Display: Overview
This unit will provide you with an overview of the following in the account balance display of contract accounts receivable and payable.:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Analyze the contract accounts of business partners using the account balance display
Design your own line layout variants for effective use of the account balance display
Account Balance Display: Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-4
SAP AG 2003
Account Balance Display: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-5
SAP AG 2003
A business partner calls to inquire about their account balance. The partner's account is analyzed using the account display. After the analysis, you determine:
The customer has paid only some of his payment obligations. A deferral or installment plan was arranged for other receivables.
Account Balance Display: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-6
SAP AG 2003
Account Balance Display: Structure of Account Balance Display
Structure of Account Balance Display
Display Options
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-7
SAP AG 2003
Fast selection of individual items
Flexible, configurable display
User-specific views (agent, accountant, ...)
Clear display
Can be called from other transactions (with selection criteria)
Tasks of Account Balance Display
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-8
SAP AG 2003
User-specific selectionWith archiveOnly due/partially paid budget billing amounts
Further Details
Account Balance Display: Entry
Business partnerContract accountContractCompany code
Account balance role
Inst. planCollective billReference
List Type
Line layoutSort VariantInitial screen
All itemsOpen itemsCleared items
Statistical items(all/budget billing plan/charges/ ...)
When the account balance display is called, the level of detail specifies the items that are displayed. Frequently used list types can be preconfigured in Customizing and temporarily modified if you enter via the detail selection. You can use the settings to save a list type as a default value in the user parameters.
You can also further limit the selection by entering user-specific selection conditions based on certain item characteristics, such as due date, transaction or clearing reason. These user-specific limitations can be saved and are available to the user who specified them the next time he/she calls the account balance display.
Account balance roles are an enhancement of the master data restriction. The account balance role 'consolidation parent' can be defined for an installation. If this is the case, the account balance role must have a function module, which determines all the subsidiaries. If you enter the business partner in the initial screen of the account balance and leave the field account balance role empty, the system displays all items for this business partner. However, if you enter a business partner and the account balance role 'consolidation parent' in the initial screen of the account balance, the system displays all items for this business partner and all items for the subsidiaries.
Line layout, sorting and initial screen define in which form the selected documents are displayed, and which fields of the selected documents are displayed. This can be changed later in account balance display. If you want other items to be selected straight away, you must return to the initial screen,
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-9
SAP AG 2003
List Type
Selection of items
Cleared items
With postings of other partners
Non-statistical items
Statistical items
Number of requests
Budget billing plan
Charges Receivable
Collective bill
All
Req. for cash security deposit
*)
*) Not used in IS-U / IS-T.
Open items
....
Installment plan
Document category
Original items for installment plans
Standard items
Account Balance Display: List Type
The list type determines the item selection for the account balance display. In Customizing, you can define list types that can be used for account balance display. These list types for account balance display can be modified when you enter the transaction.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-10
SAP AG 2003
Account Balance Display: Line Display
Line layout
Due date
Document number
Main transaction
Subtransaction
Clearing document
Traffic light
Attribute "decreasing"
Amount
Due date
StandardSorting variant
Due date + amount
Amount in local currency
You can use the line layout variants you define in Customizing to generate different displays of contract account items.
A line layout can be saved as a default value in the user parameters using the settings. You can also set the "decreasing" attribute for the account balance in each line layout. When you set this attribute, the default sort sequence of the fields in the line layout is descending instead of ascending. The default sort sequence takes into account the first six fields of the line layout.
You can use sort variants in the account balance to determine the sort sequence of the selected items prior to their display. They consist of a freely definable key and up to three fields. You can set the "sort ascending/descending" option separately for each field.
You specify sort variants in the initial screen of the account balance. The traffic light display is based on the due date. "Red" means that the due date/deferral date has been exceeded, "Yellow" means that the due date/deferral date has not been exceeded yet, and "Green" means that the receivable has been cleared.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-11
SAP AG 2003
Line layout for totals variant
Business partner
Contract accounts
Line item
Detail
Level 2
Level 4
Level 1
Document numberLevel 3
Account Balance Display: Totals Variants
The level of detail of the account balance display can be enhanced level by level using totals variants. Totals variants are summarized according to fields with the same content (for example, business partner, business partner number, or document number). However, this field may not be an amount
The following totals variant is displayed in the example: - Level 1: Items summarized at the business partner level - Level 2: Items summarized at the contract accounts level - Level 3: Items summarized at the document number level - Level 4: Line item level
The subsequent variant and the type of sorting are stored in the line layout attributes of a summary level. The last defined level of a sum variant is automatically the line item display.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-12
SAP AG 2003
SAP Reference IMGTable view Edit Goto Selection Utilities System Help
Account Balance Display: Structure of Totals Variant
List class M
Line layout S03 Totals variant document
Text**** B partner Cont. acct Document no. Due date Debit amount Credit am
ount Still open Total amount S C Dl
A__B_______ C_________ D___________ E_______ F_________ G________
____ H______________ I________________ J K L_ M
Variant FieldsECEGIKM
AMPEL B GPARTVKONT D OPBELFAEDN F SBTRWHBTRW H OBETHLBTRW J STAKZXZAHL L MAHNSCNTPO
Dialog structure
VariantsFields of a V
This example of summarization at document level can be useful for the summarized document display of items from several contracts as well as for the due dates of a budget billing plan in IS-U. This means that, for every due date, you can view a customer's total budget billing amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-13
SAP AG 2003
Account Balance Display: Display Options
Structure of Account Balance Display
Display Options
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-14
SAP AG 2003
Contract
BusinesspartnersItem
Selection
ItemDisplay
Contractaccount
Itemsorting
Navigation & Functions I
Totals
Send account information
Billprint document
Send payment form
Additional Fields
Withoutreversals
Environmentand
settings
Items can be selected, sorted and totaled in account balance display. Additional fields can be displayed and reversals can be hidden.
You can branch to different transactions from the account balance display without having to change transactions. This means that when you select 'Back' (F3), you return to the account balance display.
- Display or change the business partner master data, the contract account, and the contract - Display of the dunning history, returns history, and clearing history - Display of the payment use - Display of installment/budget billing plans - Display of the source receivables of an installment plan - Interest supplement from interest documents
and so on.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-15
SAP AG 2003
Navigation & Functions II
Budget billing plans
Security DepositsDunning notices
Submit forcollection
Write-offs
Returns
Corrections
Installment plan history
Installment plans
Mass change
Account maintenance
Credit-worthiness
Blocks
Account
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-16
SAP AG 2003
Navigation & Functions III
Documentchange
Clearing reversal
Document reversal
Line itemCollective bill
Interest supplement
Line itembundling
Payment usage
Bank data(Payment run, payment
lot, returns)
Source receivables
installment plan
Budget billing plan
Histories
Cash security deposits
Document
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-17
SAP AG 2003
Account Balance Display - Example
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras Environment System Help
Variants 001
Receivables Down paym. Total Payment list Chronology
1000000 100001671 Other receiv. 04/24/03 100.00 100001673
Receivables USD 50.00
1000000 100001673 Incom. payment 04/28/03 100.00 100001673
1000000 100001671 Other receiv. 04/24/03 50.00 50.00
50.00
ISU Account Balance Display: Standard Display
**** Contr. acc. Doc. no. Transaction Due date Amount Still open DL Clearing doc
Example: There is a due receivable to the amount of 150.00 USD with document number 100001671. This amount has been partially cleared by payment document 100001673 and an amount of 100.00 USD
If field Double-click field-sensitive is set in the user settings, then the detailed information for the respective field is displayed depending on the cursor position. If the double-click is not field-sensitive, the detailed view of the respective document is called.
If you double-click on the traffic light symbol, the respective line is displayed inversely. In contrast to the previous list, you can now choose the display as an ALV grid list. The standard tab pages (for example, receivables, down payments) are still displayed. To access the detailed view of a payment (previously on the Payment List tab page), you must now double click on the payment. The document display with the clearing document items and the cleared items is called. The functions in the list and the menu functions correspond to the functions in the standard list.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-18
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras Environment System Help
Account Balance Display - Example
Variants 001
Down paym. TotalsReceivables Payment list Chronology
Business partner 000004711 Contract account 000001000000
ReceivablesBB planDown pay. req.CSD requestCharges/inter.QuotationsPoA/creditPayment req.
50.000.000.000.000.000.000.000.00
DueUSD Total
50.00
Inst. plan itemsTotalDown paym.CSD payment
1237.471237.47
0.000.00
237.47237.47
ISU Account Balance Display: Standard Display
Totals: Totals of items in categories such as open receivables, payments on account, down payments, and total of the selected items.
The totals display can be used as an aid to navigation. The totals display is cursor-sensitive. When you double click on the display, the corresponding documents are displayed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-19
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras Environment System Help
Account Balance Display: Payment 1
Variants 001
Down paym. Total Payment list
1000000 100001671 Other receiv. 04/24/03 100.00 100001673
10000167324.10.00 man. check payment 100.00 USD
Receivables Chronology
Cleared items (according to selection)
General ledger items
U300 113100 Bank1 (check rec.) 100.00 USD100$
ISU Account Balance Display: Standard Display
Compressed Detailed
The payment list displays an overview of all incoming payments with the clearing information. If you want the payment list to be displayed, the payment document must contain a general ledger item for a general ledger account that is relevant to the cash flow. You must, therefore, make sure that the general ledger accounts are flagged as relevant to cash flow.
Example: There is a due receivable to the amount of 150.00 USD with document number 100001671. This amount has been partially cleared by payment document 100001673 with an amount of 100.00 USD
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-20
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras
**** Contr. acc. Doc. no. Transaction Due date Amount Still open DL Clearing doc
Account Balance Display: Payment 2
Variants 001
Receivables Down paym. Total Payment list Chronology
1000000 100001671 Other receiv. 24.10.00 100.00 100001673
Receivables USD 50.00
1000000 100001673 Incom. payment 10/24/2000 100.00 100001673
50.00
EnvironmentSystem Help
ISU Account Balance Display: Standard DisplayDocumentPayment data...
...Payment usage CTRL+F8
1000000 100001671 Other receiv. 24.10.00 50.00 50.00
Payment usage / Clearing analysis for document 100001673
Amount Open Doc. No. Partner/Contract Acct Text
Man. Check payment Clerk 04/28/03 10:40:43
Amounts in USD
Pmnt 100.00 100001673
Bill PPmnt 100.00 50.00 100001671 TD- 005/000001000000
Payment usage shows the item cleared by a payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-21
SAP AG 2003
Account Balance Display: Payment 3
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras
**** Contr. acc. Doc. no. Transaction Due date Amount Still open DL Clearing doc
Variants 001
Receivables Down paym. Total Payment list Chronology
1000000 100001671 Other receiv. 24.10.00 100.00 100001673
Receivables USD 50.00
1000000 100001673 Incom. payment 10/24/2000 100.00 100001673
50.00
System Help
ISU Account Balance Display: Standard Display
1000000 100001671 Other receiv. 24.10.00 50.00 50.00
50,00 50,00
Document...
History of Clearing and Reversal
Business partnerDocument no.
Item
Amount
Contract AcctPosting date
Repetition Item
Currency
000004711
1000016711
150.00
1000000
04/28/030
USD
Clearing/Reversal History
Clearing date Reversal post. Amount Curr. Clearing amount04/28/2003 100.00 USD
Chronology
Environment
…
Histories Dunning HistoryClearing historyInterest history
The clearing history displays the details of clearings and clearing reversals.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-22
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status
Account Balance Display: Find
Variants 001
Receivables Down paym. Total Payment list Chronology
1000000 100001677 Inst. plan request 01/25/2001 100.00 100.00 R
Receivables USD 300.00
100.00 R
1000000 100001677 Inst. plan request 02/26/2003 100.00 100.00
300.00
R
ISU Account Balance Display: Standard Display
System Help...Find F5...
**** Contr. acc. Doc. no. Transaction Due date Amount Still open DL Clearing amt
Goto Settings Extras
1
2
3
Edit
1000000 100001677 Inst. plan request 12/27/2002 100.00-
The search function is cursor-sensitive: If the cursor is positioned on a column header, a search can be carried out via this entity. If for example the cursor is positioned on Document number, a search can be carried out on document number intervals. If it is positioned on Contract account, a search can be performed on contract accounts.
If the cursor is positioned on a field in a document line, then all documents are displayed that have the identical field contents. If, for example, the cursor is positioned on 100.00, all line items containing the amount 100.00 are selected. If for example the cursor is positioned on 01/25/03, then all line items that are due on 01/25/03 are selected.
If the cursor is positioned on an area of the screen that contains no data, a selection window appears. You can select up to three fields from the field list as search criteria. The fields that are available here are determined via customizing.
Sorting and totaling is also cursor-sensitive.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-23
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras Environment System Help
Account Balance Display: Totals Display
Variants S01
Receivables Down paym. Totals Payment list Chronology
000004711 795.00 355.00- 440.00 440.00 9
S02 S03 S04
795.00 355.00- 440.00 440.00 9
IS-U Account Balance Display - Total by Business Partner
**** B-Partner Debit amt Credit amt Still open Total amount
The totals variant is summarized at business partner level in the first level.It is then summarized at contract account level. The third level is summarized at document number level. The fourth level is the line item view.
Totals variants are summarized according to fields with the same content (for example, business partner number or document number).
In totals variant S03 – summarization at document level – several document items (such as for partial payments) are summarized to a single document number.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-24
SAP AG 2003
Account Status: Basic List
0000004711 / U300Claire Clemens123 Main StreetNew York, NY 10101
Account Status Edit Goto Settings Extras Environment System Help
Account Balance Display: Additional Fields
Variants 001
Receivables Down paym. Totals Payment list Chronology
1000000 100001674 Other receiv. 04/24/03 300.00 300.00
Receivables USD 300.00
1000000 100001673 Incom. payment 04/28/03 100.00 100001673
1000016731000000 100001671 Other receiv. 04/24/03 100.00
300.00
**** Cont. acct. Document no. Trans. text Due date Amount Open amount DL Clearing doc
+ STUDT
Deferral
00.00.0000
15.01.2003
00.00.0000
ISU Account Balance Display: Standard Display
Any document field can be inserted in single item variants with +<FIELDNAME> (independent of Customizing). For example, if you enter +STUDT in the OK code field, the cursor determines the column in which the transaction text is inserted in the current display.
You can also display an additional field from the menu. This additional field can be selected from the selection window. The fields that are available in the selection window are determined in Customizing. If some of these fields are already contained in the line layout, they are no longer available in the selection window.
Additional fields can only be displayed in the line item display. This function is not available in the totals variants.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-25
SAP AG 2003
Account Balance Display: Events
In the account balance display events, you can make different installation-specific changes/enhancements:
1200 Account Balance: Set Header Data 1201 Account Balance: Display Contract Data 1203 Account Balance: Status Icons / Colors 1205 Account Balance: Supplement Data 1206 Account Balance: Name and Execute Additional Functions1207 Account Balance: Output Header Data 1208 Account Balance: Output Address Data 1209 Account Balance: Key 1210 Account Balance: Add Selection Specifications 1211 Account Balance: Change Hit List and Totals 1212 Account Balance: Change Chronology 1213 Account Balance: Chronology - Modify Output 1214 Account Balance: Navigation - List of Contracts 1215 Account Balance: Overview of Budget Billing Plans 1217 Account Balance: Output Header Data (ALV) 1230 Account Balance Short Form: Add Data
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-26
SAP AG 2003
Account Balance Display: Customizing
Structure of Account Balance Display
Display Options
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-27
SAP AG 2003
IMG Contract Accounts Receivable and Payable
Documents: Customizing (1)
Basic Functions
Account Balance Display
Define Line Layout for Account Balance Display
Define List Category
Maintain Sorting Variants
Select Fields for Search Function
Define Proposal for Line Layout
Choose Fields for Selection FunctionSelect Fields for Sort Function
Select Additional Fields to be Displayed
Define Account Balance Roles
Assign Transactions for Account Balance Display
Set Budget Billing Display
Search function: The VRGNG (transaction) field is made up of the main transaction and subtransaction fields, and enables you to search for items with specific main and subtransactions by entering a single selection criterion.
You can also use the fields CPUDT (entry date) and CPUTM (entry time) for searching and displaying information.
Assign transactions for account balance display: Business partner items are not saved for some documents (such as payment documents). Text is not displayed in the account balance display for these transactions. However, you can define dummy transactions in this activity, depending on the clearing reason. This ensures that a text appears in the account balance display. The texts for these transactions are then displayed.
Special feature for IS-U in line layout: Fields OPBEL_KK_RG and AUGBL_KK_RG. If the document item was created during IS-U invoicing, the print document number is displayed. It is prefixed by the letter 'D'. If it is a 'normal' posting document, it is prefixed by the letter 'F'. At the same time, the clearing number of the document is entered in the Clearing Document Number field. This enables you to replace the different FI-CA document numbers that are generated during invoicing with a universal document number.
Budget billing display represents another IS-U feature: The indicator 'No Clrd Budget Blg' allows you to hide invoiced budget billing plans and allocated budget billing amounts.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-28
SAP AG 2003
All account transactions for a business partner can be viewed using the account balance display.
The display can be freely configured.
Various views are available for a contract account.
It is possible to branch from the account balance display to the account environment, for example to documents and master data.
Account Balance Display: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-29
Account Balance Display - Exercises
Unit: Account Balance Display Topic: Analysis of Contract Accounts
Providing information about a business partner’s business transactions
One of your business partners calls and requests information about his/her account balance.
The business partner wants to see all his/her account transactions.
1 Account display
1-1 Display all open items for the contract accounts of business partner PICA0710## (PI0904C0##) (0## = group number).
Which list type do you have to use to display all the open items?
_______________________________________________________________
Which line layout variant do you choose?
_______________________________________________________________
1-2 Change the display to show all the statistical and non-statistical open items.
Which list type do you choose now?
_______________________________________________________________
Which items are also shown using this list type?
_______________________________________________________________
1-3 Branch from the display of an installment plan receivable to the display of the source receivable(s). Describe your actions. _______________________________________________________________ _______________________________________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-30
1-4 Go back to the initial screen of the account balance display, choose the list type All items and display the payment list. Which receivable cleared the payment from the oldest payment lot before the payment was reversed by a return?
_______________________________________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 4-31
Account Balance Display: Solutions
Unit: Account Balance Display Topic: Analysis of Contract Accounts
1 Account display
1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance.
List Type: Standard: All open items
Line Layout: Standard line layout – acc. display
1-2 Choose list type: Open items (stat. and non-stat.)
All additional installment plan receivables and dunning charges receivables are displayed.
1-3 Double-click on an installment plan receivable. In the display document, choose Environment → Source Items → For Installment Plan. Alternatively, you can choose the Installment Plans button (cntrl + 9) and display the source receivables via Environment → Source Receivables (Account Display).
1-4 Choose the Payment list hotspot in the display screen for all items. Determine the oldest payment lot and choose the button at the start of this line to display the detail view.
The payment has cleared a miscellaneous receivable.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-1
SAP AG 2003
This unit will enable you to understand:
The structure of the transactions
The determination of general ledger accounts
The tax determination process
The Customizing of your accounting transactions
Transactions and Account Determination
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-2
SAP AG 2003
At the conclusion of this unit, you will be able to:
Tell the difference between internal and external transactions
Tell the difference between main transactions and sub-transactions
Define the main and sub-transactions within contract accounts receivable and payable
Design the account determination for the business transactions
Explain the structure and processes of tax determination
Transaction and Account Determination: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-3
SAP AG 2003
Transaction and Account Determination: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-4
SAP AG 2003
As an agent in financial accounting, you are involved setting-up automatic account determination during the implementation project.
You have to find out about the concept of account determination and sales/purchase tax in contract accounts receivable and payable.
Transaction and Account Determination: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-5
SAP AG 2003
Transactions and Account Determination: Structure and Conception of Transactions
Structure and Concept of Transactions
Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-6
SAP AG 2003
Account DeterminationTax determinationAdditional account assignment
Attributes- Debit/credit- Interest key- Statistical/non-statistical
Allocation to internal transactions
Default settingby SAP
Transactions
Transactions describe the business transaction uponwhich the posting of a document line item is based
Transactions
Allocation
Maintransactions
Sub-transactions
SAP
SAP
InternalSub-
transactions
InternalMain
transactions
A transaction is a combination of main and sub-transactions. The texts allocated to the main and sub-transactions explain the corresponding business transaction and are available in the correspondence.
The main transaction controls the determination of receivables and payables accounts. The sub-transaction controls revenue account determination, determination of the tax determination code, and of information about any additional accounts (business area, CO account assignment data).
FI-CA and the industry specific applications (such as, IS-U, IS-M or IS-T) use internal main and subtransactions. These are assigned during the various business processes and control these processes. These internal transactions are to be assigned to installation-specific, defined transactions.
If all FI-CA functions or industry solutions are used, internal transactions represent the minimum of transactions. In addition to this, for manual posting, you can define any transaction that does not correspond to an internal transaction.
Transactions in IS-U must be specified by characteristics such as debit/credit indicator, interest key, statistic indicator, etc. These characteristics are automatically transferred to the document during posting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-7
SAP AG 2003
Main Transaction
Payment on account
Returns
Otherpostings
Cash security deposits
Interest
Budget billingrequest
Charges
Interest on cashsecurity deposit
Installment plan
Collective bill
Manual credit note/Backbilling
Final billing
Consumption billing
Down payment
Main Transactions
Internal main transactions are defined in contract accounts receivable and payable programs. These main transactions are needed for various business processes and are used for controlling these processes. All internal main transactions are stored in the system table TFKIHVOR.
If the complete functionality is used, the internal main transactions represent the minimum of main transactions to which the freely definable main transactions must be allocated.
Any number of main transactions can be defined for business transactions that have not yet been mapped. These main transactions are not allocated to any internal main transactions, for example, the main transaction Other Postings.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-8
SAP AG 2003
Main TransactionReturns
Returns chargesReceivable 1
Subtransactions
Returns chargesReceivable 2
Returns chargesStat. receivable 1
Returns chargesStat. receivable 2
Internal subtransactions of a main transaction specify the business transaction exactly; for example, the statistical returns charges are allocated the internal transaction 0070/0020. All internal transactions are defined in the system table TFKITVOR. This table contains transaction specifications such as, the debit-credit indicator and the statistical key.
The fully defined internal transactions - internal main and internal subtransactions - can each be allocated once to a customer-specific transaction.
When you specify a transaction with attributes, the system checks whether the credit/debit indicator and statistical key correspond to the attributes of the allocated internal transaction (table TFKITVOR).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-9
SAP AG 2003
Posting Areas
Definition:
Key representing a business subfunction that supports automatic determination of certain data required to create documents. This data can include account numbers, transactions and other specifications or defaults used in posting transactions and clearing transactions.
In contract accounts receivable and payable, individual Customizing tables are not defined for every posting area. Depending on the posting areas, tables are identified by their key and function fields.
Posting areas can be called up using Customizing activities or the transaction FQC0.
The posing areas are broken down into the following areas: Posting areas for all application areas (for example, posting area used to identify a tax account based on the tax code)
Posting areas for more than one application area (for example, posting area used to determine the default values for incoming payments). You can make a number of different specifications for each application area.
Application-Specific posting areas -> prefixed by the letter from the application area The active application area is defined in the user parameters and/or by selecting the application area. Transaction FQCR: Select and output data from account determination. You can use this report to select and display account determination data from any posting area. In the list, you can use functions such as find, sort and total. If you select the entry, the system branches to display screen. You can maintain the entry by selecting display -> change. If you enter a search value, you can use the report, for example, to find what Customizing entry an automatically posted general ledger account was determined from.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-10
SAP AG 2003
Transactions foraccount display Incoming payment
Account maintenance
Freely Defined Transactions
Main transaction Subtransactions
Account maintenance, invoicing account maintenance, write-off
Incoming payments, outgoing payments,clearing reversal, ...
Clearing item transactions Incoming payment
Reversal
Main transaction Subtransactions
Reversal from returns
Payment on account
Main transaction Subtransactions
Other receivables
Main transaction SubtransactionsOther receivables, other credit memos
Transactions for SD billing docs
Transactions for other postings
Household connection:ElectricitySubsidiary xyz
Receivable, credit memo
Receivable, credit memo
... ...
R010, T010, M010...
1090, 1091
1200
Transactions for account balance display must be freely defined. These transactions are defined for documents that do not have any business partner items (reversal or payment documents). The transaction is determined using the clearing reason of the document that was cleared by these documents (reversal or payment documents). These transactions must then be defined in the posting areas R001 (IS-U), T001 (IS-T) or M001 (IS-M).
If documents that do not have any business partner items are cleared themselves (by reversal or clearing cancellation) , the system creates a business partner item and the clearing information can be written here. This item transaction is also determined from Customizing. The original clearing reason is also used for determination here: Posting area 1090 and/or 1091.
Any sub-transactions can be specified for business transactions that are not represented in FI-CA processes. These sub-transactions are allocated to the freely-defined main transactions. This enables you, for example, to map infrequent business transactions and use them for manual posting.
For SD billing documents that are posted to FI-CA, the transactions are determined based on several characteristics of the SD billing document. Transactions can also be freely defined here: Posting area 1200.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-11
SAP AG 2003
Allocating an Internal Transaction - Defined Transaction
No allocation in the following cases:
User-defined transactions for manual postings exist and these do not correspond to an internal transaction.
A 1:1 allocation of an internal transaction to defined transaction is not sufficient
In FI-CA interface areas, the business process is configured individually by defining user-specific subtransactions. As a result, there are no internal transactions.
Examples: Customer-specific transactions: Other receivables for manual postings (6000 / 0020 in the training system) do not correspond to internal transactions.
Depending on the charge schema selected in the dunning steps of a dunning procedure, dunning charges must be posted either statistically or as relevant for the general ledger. The transaction is 'allocated' to the business process (specifies, which defined transaction is used in the business process) with the option of creating 1:n relationships.
The rate structure in IS-U Billing and Invoicing enables you to create different rate steps, which generate posting-relevant bill lines to different revenue accounts and CO account assignments. The freely defined subtransactions are included in these rate steps. Allocations cannot be made in the transaction configurations due to the customer-defined rates and subtransactions.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-12
SAP AG 2003
Credit memo:Energy charge
Credit memo:Demand charge
Receivable:Demand charge
⇒ Freely definable - No allocation / inclusion in rates / account determination
⇒ Allocation to internal invoicing transactions / no account determination
Sub-Transactions in IS-U: Billing / Invoicing
FI-CADocument
FI-CADocument
Receivable:Periodic bill
Credit memo:Periodic bill
Cumulative transactions
Receivable:Energy charge
..... .....
Main transactionPeriodic bill
Receivable:Servicecharge
Credit memo:Servicecharge
The accumulation transactions are allocated to the internal transactions, and do not have a defined account determination. These accumulation transactions (for example, 0100/0020 Consumption Billing Receivable) maintain the business partner items in the FI-CA documents that come from IS-U Invoicing.
Transactions for the price components can be freely defined and are maintained in the rates. Account determination is defined for these (transaction-relevant account determination with revenue account, sales/purchase tax code and CO key).
Subtransactions must be defined for all main billing transactions (consumption billing / final billing / manual billing).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-13
SAP AG 2003
Budget billing planDebit
Budget billingpay-out
transfer posting
Budget billingpayment
Budget billingpay-out
..........
⇒ Allocation to internal transactions / no account determination
⇒ Freely definable / inclusion in rates / account determination (budget billing)
Sub-Transactions in IS-U: Statistical Budget Billing Procedures
Main transactionStatistical
budget billing procedure
Budget billing plancredit
Budget bill. paym.transfer posting
Payment and transfer posting transactions must be allocated to the internal transactions. No account determination is necessary.
The payment transactions must be defined as "follow-up" transactions for the extrapolation transactions. The sub-transactions for budget billing extrapolation are maintained in the rates. They must be defined statistically (debit = "P" / credit = "Z"). You must specify the account determination for these transactions.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-14
SAP AG 2003
Transactions and Account Determination: Account Determination
Structure and Concept of Transactions
Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-15
SAP AG 2003
Balance account 140580
(Receivables)
Receivablesaccount
Account Determination: Receivables Account
For example, interest:
Main transaction 0040
Business transaction
Contract account/Contract
Company code U100Division -Account determination ID 01
Account Determination
Define account assignment data relevant for main transactions
Posting area R000 / T000 / M000
The system determines the main transaction during business partner processing based on the internal transaction and its allocation to a defined transaction.
The account determination ID is determined from the contract account for cross-contract business transactions, or from the contract for business transactions relating to contracts.
The account determination ID controls determination of the receivables account in FI-CA (together with the main transaction that resulted from the business transaction). The company code and, potentially, the division are further criteria.
The same receivables account is determined when identical business transactions occur for contract accounts that have the same account determination IDs, for example residential customers or affiliated companies.
You can use different account determination IDs to access different receivables accounts in general ledger accounting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-16
SAP AG 2003
Profit/Loss account 800520
(Revenues)
Sales revenue account
Account Determination: Revenue Account
For example, interest:Main transaction 0040Subtransaction 0020
Business transaction
Contract account/Contract
Company code U100Division -Account determinationID 01
Transactiondetermination
Transaction
0040/0020
Define account assignment data relevant for transactions
Posting area R001 / T001 / M001
Account Determination
The account determination ID is determined from the contract account for cross-contract business transactions, or from the contract for contract-related business transactions.
The subtransaction is also required for the revenue account determination This enables you to allocate different revenue accounts to one business transaction (main transaction) by defining special subtransactions. It is also possible to allocate different revenue accounts for each company code and division.
The business area and sales/purchase tax code are defined in revenue account determination. Further account assignment characteristics (such as cost and profit centers) can be saved there using the CO account assignment key.
In IS-U, you can override the auxiliary account assignments from cost accounting using a contract-dependent CO account assignment key that is defined in the IS-U contract.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-17
SAP AG 2003
Transactions and Account Determination: Tax determination
Structure and Concept of Transactions
Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-18
SAP AG 2003
Tax: Tax Code Determination
Tax determination
Tax determination E1From-date 04/01/1998Sales/pur.tax cde (FI) A3
S/P tax code A3Tax rate 16 %
Tax determ. FI
For example, interest:Main transaction 0040Subtransaction 0020
Company code U300Division -Account determinationID 01
Transactiondetermination
Transaction
0040/0020
Account Determination
Accounts for sales/purchase tax 0010
Define sales/purchase tax determination
Business transaction
Contract account/Contract
Taxdetermination E1
Profit/loss account 800520
Sales revenue account
The determination of the indicator for posting sales tax is connected with the determination of the revenue account for a business transaction.
In the table TE011, the valid sales tax code for general ledger accounting is determined historically (that is, the periods for which a tax code is valid are defined), based on the tax determination code determined in revenue account determination.
The tax accounts to be posted are defined in the posting area 0010 depending on company code, sales tax code and tax transaction.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-19
SAP AG 2003
Country DescriptionTaxValid-fromTDDE E1 01/01/1995 A1 Output tax 15% 03/31/1998DE E1 04/01/1998 A3 Output tax 16 % 12/31/1999DE E2 01/01/1995 A2 Output tax 7% 12/31/1999US E1 01/01/1995 O1 A/R Sales Tax, taxable 12/31/9999.....
Valid-to
Tax deter-mination ID
TaxID
in FI
Long textfor tax
ID
Start ofvalidityperiod
End ofvalidityperiod
Tax: Tax Change
Example: Tax increase from 15% to 16%: The sales/purchase tax determination code E1 is valid from 01/01/1995 to 03/31/1998. The tax determination ID A1 is valid in general ledger accounting for this period. The tax code (A3) resulting from the change of tax must be newly defined in general ledger accounting.
In FI-CA, a new validity period is specified, in which the new tax code is allocated.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-20
SAP AG 2003
Specification of tax determination ID
CCODE Division MTORG STORG KOFIZ TAXDETIDU100 01U100 01
01000100
0020 (AP)0030 (LP)
0101
E1E1
Billing
Historical determination of tax code
Country TAXDETID FDATE
DEDE
DE
E1E1E2
01/01/95
01/01/9504/01/98
A1
A2A3 E1 A1 (15 %)
E1 A3 (16 %)E2 A2 (7 %)
TE011
Tax: Procedure for Changing Tax IS-U (1)
TAXID
Starting from a business transaction, in this case IS-U Billing, a tax determination code is automatically determined from account determination.
The tax determination code for general ledger accounting is found using the history of the tax determination ID.
The tax percentage rate is determined using this FI tax code.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-21
SAP AG 2003
Proration for change date
Determination of tax account and amount
OPERAND TRANS NETAMNT FDATE TODATE TAXID
NTVBHTVB
NTVB
HTVB 0100 00200100 00200100 00200100 0020
130200500
100
. . . . . . . . . . . .. . .
06/01/9704/01/9806/01/9704/01/98
03/31/9805/31/9803/31/9805/31/98
A1
A1A3
A3
Billing
Invoicing
OPERAND NETAMNT TAXID TAXAMNT TAXACNTHTVB 100 A1 15 175000
Tax: Procedure for Changing Tax IS-U (2)
Tax determination codes contained in the billing period are determined during creation of the billing document. The resulting tax code provides information on the tax percentage rate and tax account.
If the tax changes within the billing period, proration occurs in the billing line items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-22
SAP AG 2003
Transactions and Account Determination: USA -Jurisdiction Code
Structure and Concept of Transactions
Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-23
SAP AG 2003
Standard SAP interface for internal or external tax calculation with jurisdiction code
Determination of tax code is the same as without jurisdiction code
Jurisdiction code assigned at contract level and contract account level
Tax rate changes maintained in table TE012 if tax calculation is executed in an external system
Tax Calculation Based on Jurisdiction Code
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-24
SAP AG 2003
Change Contract: Page 2 4711Contract Edit Goto Extras Environment System Help
Data relevant to billing
Contract 4711Division 01 Division electricityCompany code U300 IBU Utility US Inc. 300
Account assignment dataAct. Determ. Code 01
Jurisdict. code 101110001
Page 1 Page 2Page 2 Page 3
Jurisdiction Code Assigned in Contract
The tax jurisdiction code is used for determining the tax rates in the USA. The jurisdiction code defines the tax authority you have to pay your taxes to. It is always the city to which the goods / services are supplied.
You may enter the tax jurisdiction codes in the data relevant to billing on the contract. The jurisdiction code on the contract is assigned during move-in.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-25
SAP AG 2003
Contract account Change: General dataContract account Edit Goto Extras Environment System Help
General data
Contract acc. 4811 Cont. acc.Partner/Address 1000 Rose Taylor
Jurisdict. code 101110001
01 IS-U Contract Account US/02100/Boston/Oxlade Drive
Jurisdiction Code Assigned in Contract Account
The system uses the jurisdiction code on the contract for calculating contract-related taxes. For transactions that do not involve a contract, the jurisdiction code on the contract account is used.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-26
SAP AG 2003
City Valid fromUS 101110001 01/01/1995 03/31/1998
.....
Valid to
JurisdictionCode Start date End date
Jurisdiction Code Product
Product Codeexternal System
US 101110001 04/01/1998 12/31/9999
External System - Tax Rate Change
You have to manually maintain this table for tax changes since there is an interface is not yet available. If no data is maintained in Customizing, the actual billing data is used for tax determination.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-27
SAP AG 2003
BusinessTransaction
Contract Account/Contract
Tax Determination with Jurisdiction Code
Sales/PurchaseTax determination
Tax Determination E1From 04/01/1998S/P key (FI) O1
Tax Determination E1
S/P key 01JD code 101110001S/P rate 8%, 3%, 1%
Tax Determ. FI
P&L Account 800520
Revenue Accounte.g. Interest:MainTransaction 0040SubTransaction 0020
Company Code U300Division -Account Determination ID 01JD Code 101110001
FindingTransaction
Transaction
0040/0020
Account Determination
In Customizing, you define the tax determination code in IS-U that links to the tax code in FI. The tax account is determined during revenue account determination. The tax code and the jurisdiction code determine the tax rates to be charged. External tax packages may be used in conjunction with FI-CA for tax rate determination.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-28
SAP AG 2003
Transactions and Account Determination: Customizing
Structure and Concept of Transactions
Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-29
SAP AG 2003
Transactions and Account Determination: Customizing
IMG Contract Accounts Receivable and PayableBasic Functions
Postings and Documents
Maintain......Transactions
DocumentDefine Sales/Purchase Tax Determination
Perform Consistency Check for Transactions
Store CO Short Account Assignments for IS-U Contracts
Automatic G/L Account Determination
Define Accounts for Sales/Purchase Tax
Define Account Assignments for Automatic PostingsDefine CO Short Account Assignments
Define Accounts for .........
......Define account assignment data relevant for main transactions
Account Assignments for Down Payments/Charges
.... Define account assignment data relevant for transactions
Define Accounts for Budget Billing Down Payments
In the activity, 'Maintain ...... Transactions', you can define main and subtransactions, carry out allocations to internal transactions, make cross-industry settings and add attributes to the transactions.
The consistency check program RFKK_TRANSACTION_CONS_CHECK checks whether transaction configurations are complete and plausible.
CO keys can be defined depending on company code, business area, and - if contract-related - depending on main and subtransactions. You define contract account-related CO account determination keys in transaction-relevant account determination; contract-related CO account determination keys (ISU) are assigned in the contract master record, however, they can be included in the posting area R001 before the contract account CO account assignments.
In the account assignments for down payments and charges, you can define the transactions that are automatically posted when down payment requests, budget billing requests, or statistical charges receivables are cleared. You define these transactions according to the statistical keys. The statistical document items form the basis for posting. Account assignments that cannot be taken from the statistical document items must be defined here in the system.
Accounts for budget billing down payments in IS-U only have to be defined here if the statistical budget billing procedure has been selected in the invoicing system parameters. You do not have to make any more settings in this posting area for the other budget billing procedures.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-30
SAP AG 2003
The business transactions of FI-CA subledgeraccounting transactions can be illustrated by the definition of FI-CA transactions
Non-industry and industry-specific transactions are already implemented in FI-CA through internal main and sub-transactions.Examples include:
Charges, returns charges, interest
Consumption billing, telephone billing
Budget billing plan
Collective bill and installment plan
Transactions and Account Determination: Summary (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-31
SAP AG 2003
The receivables account that is relevant to a specific accounting transaction is determined by the main transaction.
The transaction, which is made up of a main transaction and a sub-transaction, helps to determine the revenue account and the tax determination ID.
Transactions and Account Determination: Summary (2)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-32
SAP AG 2003
The tax determination code is managed historically.
The tax determination code refers to the tax ID in general ledger accounting
The tax percentage rate is determined in Financial Accounting.
Transactions and Account Determination: Summary (3)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-33
Transactions and Account Determination: Exercises
Unit: Transactions and Account Determination Topic: Configuring Transactions
Expand the transaction definition in FI-CA.
The concept of account determination in FI-CA.
How sales/purchase tax determination works.
FI-CA requires defined transactions in order to post documents.
Account assignments are also defined using the posting function in subledger accounting.
1-1 Concept
1-1-1 What does a transaction consist of and what does it represent in FI-CA?
___________________________________________________________ ___________________________________________________________
1-1-2 What controlling tasks form the basis of the transaction concept?
___________________________________________________________ ___________________________________________________________
1-1-3 What is a posting area?
____________________________________________________________ ____________________________________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-34
1-2 Definitions
Check with your instructor that Customizing has been opened for concurrent access to the necessary transaction configuration tables and posting areas.
1-2-1 Define a new transaction: SB## / FO## (## = group number) ‘Other posting group ## / Receivables group ##’. Add the necessary attributes to this transaction using posting area U100 (U300) and the division ‘space’.
1-2-2 Define the account determination in the chart of accounts INT: Receivables account: 140520 Revenue account: 800525 Sales/purchase tax determination code: E1 CO account assignment: 1
1-2-3 Post a document to contract account PICA0210## (PI0202C0##) using your new transaction SB## / FO##.
1-2-4 Why does your transaction not have to be allocated to an internal transaction? ____________________________________________________________ ____________________________________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-35
Transactions and Account Determination: Solutions
Unit: Transactions and Account Determination Topic: Configuring Transactions
1-1 Concept
1-1-1 A transaction consists of a main transaction and a subtransaction. It represents the business transaction that is currently being processed in FI-CA.
1-1-2 Transactions control the determination of receivables and payables accounts. A transaction also controls revenue account determination, the determination of the sales/purchase tax determination code, and the determination of information about any additional account assignments (business area, CO account assignment data).
1-1-3 A posting area is a subprocess that supports automatic determination of certain data required to create documents.
1-2 Definitions
1-2-1 Choose: Tools → Customizing → IMG → Edit Project and then the SAP Reference IMG.
Once you have done this, choose Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Maintain Document Assignments → Maintain Transactions for IS-U/IS-T → Maintain Transactions for Other Receivables.
In the dialog structure, double click on the first level: Define Main Transactions. Select New Entries and define your main transaction. Choose Enter. Select the line that contains your main transaction and double click on the level: Define Sub-Transactions. Select New Entries and define your subtransaction. It is sufficient to enter only the key and the description of the subtransaction.
Save your entries and use F3 to return to the IMG. Select the activity Maintain Transactions for Other Receivables again. On the dialog structure level Maintain Attributes per Company Code and Division, select New Entries and enter the following data:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-36
Company Code: U100 (U300) Division: Short text: othRec.## Long text: Other receivables ## Main trans.: SB## Subtrans.: FO## Debit/credit indicator: Debit Manual posting allowed: X
Save your entries and use F3 to exit the maintenance dialog.
1-2-2 Choose the following path in the SAP Reference IMG:
Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Define Account Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U: Define Acct Assmt Data Relevant to Main Transactions.
Enter INT as the chart of accounts. Select create (shift + F4). This takes you to a maintenance step where you can enter the receivables account for your main transaction.
Enter the following data:
Company Code: U100 (U300) Division: Act determ. ID: 01 Main Trans.: SB##
Enter account 140520, save your entry and use F3 to exit this activity.
Select: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Define Account Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U: Define Acct Assmt Data Relevant to Transactions.
Enter INT as the chart of accounts. Select create (shift + F4). This takes you to a maintenance step where you can enter the receivables account for your main transaction.
Enter the following data:
Company Code: U100 (U300) Division: Act determ. ID: 01 Main Trans.: SB## Subtrans.: FO##
Enter the revenue account 800520, the tax determination code E1, and the CO account assignment 1 (use F4 help). Save your entry and use F3 to exit this activity.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 5-37
1-2-3 To manually post a document, go to the SAP application menu and select: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post. Enter the data as described in task 1-1, unit 2. This time, however, select your new transaction SB## / FO##.
1-2-4 This transaction is used for other manual postings and does not correspond to an internal transaction defined by an SAP program.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-1
SAP AG 2003
Contents:
Overview of the payment run
Payment Run - Procedures, Parameters, Program Flow
Payment methods
Payment Cards
Customizing
Payment
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-2
SAP AG 2003
This unit will enable you to understand:
The prerequisites for making payments
How to define payment methods and how they influence the payment process
How to customize your payment requirements
Payment: Overview
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Make payments in contract accounts receivable and payable
Carry out postings and repayments using the payment run
Make payments with credit cards
Payment: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-4
SAP AG 2003
Payment: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-5
SAP AG 2003
During invoicing, receivables were posted to a business partner's contract account. Billing also created credit for several business partners.
The receivables are posted using the debit memo procedure and the credits are refunded during payment processing.
Payment: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-6
SAP AG 2003
Payment Run: Overview
Overview of Payments
Payment Run - Program Flow and Parameters
Payment Cards
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-7
SAP AG 2003
Business partnerBank data
Payment card data
Address
Contract AccountResponsible company code
Link to business partner's bank details(if necessary, alternative payer)
Payment methods
Payment block
Contract account or business partner used for clearing purposes in payment transactions (payer)
Payment Program: Master Record
Account
The business partner's address and bank data are used. The bank details defined in the contract account refer to the business partner's bank data.
The function of the responsible company code is the same as the paying company code in General Ledger Accounting.
If you specify another business partner and/or contract account to be used for clearing, the items from the contract accounts are paid together for this business partner. The system determines the payment method, bank details, and locks using this clearing contract account.
You define the additional details which are relevant to payment separately for outgoing and incoming payments: • You can specify a business partner's bank details (or any alternative business partner's bank details) in
each case. • You can override the payment methods entered by specifying a different payment method in the
document. • You can block the contract account for outgoing or for incoming payments. You can also prevent bank
collection after failed debit memos being carried out until a processing block date.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-8
SAP AG 2003
Bank
Contract Acct
39.00 [1]
[1] 300.00
[1] 300.00
[2] 300.00
261.00 [1]
300.00 [2]
Receivables account
Bank clearing
Revenue account
Tax account
300.00 [2]
FI-CA
FI
Payment: Posting 1
[1] Debit position of a receivable [2] Payment in FI-CA by the payment run.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-9
SAP AG 2003
FI-CA
FI
Bank
Contract Acct
39.00 [1]
[3] 300.00
[1] 300.00
[1] 300.00
[2] 300.00 300.00 [3]
261,-- [1]
300.00 [2]
Receivables account
Bank clearing
Revenue account
Tax account
300.00 [2]
Payment: Posting 2
[3] Incoming payments in General Ledger Accounting (posting the account statement).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-10
SAP AG 2003
Payment Run - Program Flow and Parameters
Overview of Payments
Payment Run - Program Flow and Parameters
Payment Cards
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-11
SAP AG 2003
Grouping of due items
Determination of items to be paid
Selection of payment methods and bank details
Posting of payment documents / clearing of open items
Retrieval of data for payment medium
Generation of data medium
Payment Program: Procedure
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-12
SAP AG 2003
Bank selection
Payment Program: Parameters
Date identifier
Identification
General selections
Business partner
Contract Account
Company codeDue date
Simulation run
Repayments
Bank selection Tech. settings
Free selections
Free selections
Posting parameters
Logs
Company codePayment methodCurrencyHouse bankAccount IDRanking order
Number of jobs Problem classAdditional logSelection
Payment methods
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-13
SAP AG 2003
Payment Program: Parameters
Payment runs: Find payments
Determination of payments in payment runs based on certain selection criteria:Bank dataPayment card dataAmounts
Result: List with detailed information on each payment
You can look for payments in the SAP applications menu under Contract Accounts Receivable and Payable -> Payments -> Payment Run -> Find Payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-14
SAP AG 2003
Payment Run
Overview of Payments
Payment Run - Program Flow and Parameters
Payment methods
Payment Cards
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-15
SAP AG 2003
Contract account 4712
DME
DME
Bank dir. debit - pymnt meth. 02Bank no.: 10010000 - acct: 541237
Bank trans.ref. - pymnt meth. 01Bank no.: 10010000 - acct: 541237
Outg. check - pymnt meth. 0369190 Walldorf, Astor Street 12
Payment Program: Payment Methods 1
Contract account 5421
Contract account 4711
123.45
The payment method determines the way in which a business partner pays his/her receivables or how credit is paid out.
Payment methods are defined for a country. They are allocated for paying company codes and specified in more detail.
The format determines the technical attributes of the payment medium. This way you determine whether the payment medium is created with a document (on paper) or using without (DME or EDI).
If there is a credit memo and an open receivable in a contract account, then the credit memo is cleared against the receivable and the remaining balance is either collected or refunded. If, however, the credit is marked with a refund payment method, the refund still takes place and the payment for the full amount of the receivable is also posted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-16
SAP AG 2003
Inc.pymnt method .....XBank details................X
Create check…...........XStreet. P.O. box...........X
Direct debit- pymnt meth. 01Bank no.: 10010000 - acct: 541237
Outg. check - pymnt meth. 0369190 Walldorf, Astor Street 12
Doc. 1230067Doc. type 05
Doc. 600999Doc. type 08
Payment Program: Payment Methods 2
Format
Format
The payment method defines the way in which payment transactions are carried out in a country. You define rules within a payment method that have to be met for that individual payment method: For example, you have to define bank details in the business partner's master record for a payment method that is classified as a debit memo procedure and reference these from the contract account. To create an outgoing check, however, you have to know the business partner's address.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-17
SAP AG 2003
Doc. 0123456789Amount: 112.67 USDDue: 05/22/03
Alternativepayer
Payment method
Paymentblock reason
Grouping
Due date Deferraldate
Payment Program: Document Data
In addition to data from the contract account, information required for the payment process is also taken from the document. You can also define certain data at document level that overrides the specifications from the contract account, or prevents incoming or outgoing payments.
You can use grouping keys to group together open items that have to be paid or collected together. This means that you can prevent these items from being paid separately or other items being entered with them. As a result,you can ensure that a payment is made or debit memo is created with the exact amount that the customer was notified of (for example by IS-U invoicing). A grouping key can be freely allocated. Items can only be grouped together if at least the following characteristics correspond: Business partner; alternative payer in document; contract account used for payment; responsible company code; payment locks in items; item currency; item payment method; grouping key. An extra grouping field (DE PAYGR_PAY ) can be maintained for event 0600. This also has to be the same for all items in a group. The SAP Biller Direct component enables customers to display bills over the internet and release them for collection or pay them using a card. In these cases, the system allocates (and overrides) the payment group so that the authorized amounts can also be paid jointly, if possible.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-18
SAP AG 2003
DMEDME
Payments: Output
Logs
Payment advice
Exceptionlist
Paymentsummary
Data medium
Karl Einstein
Bank transfer 9.500Date
Accompanying sheetDME
Karl Einstein
Bank transfer 9.500Date
Forms
Clarification of payment exceptions
DME
?
The payment medium is created at the end of a successful payment run (data medium exchange). SAP supplies payment medium formats (see the IMG structure: Financial Accounting -> Contract Accounts Receivable and Payable -> Program Enhancements -> Define Payment Medium Formats).You only need to create your own formats in exceptions. Information on data medium for collection or refund:
All payment records are written on the data medium. This data medium is deposited at the company's house bank. If several house banks are involved in payment, a data medium is created for each house bank. Logs: All executed activities can be recorded in the application log, based on the problem class selected. In an additional log, it is possible to restrict the log to individual business partners.
When Customizing the Note to Payee, the user defines the content that the Note to Payee fields must contain in the data medium exchange. Any number of categories can be defined for the Note to Payee, and these are later assigned to the payment method. You can, therefore, use the structure and contents of the Note to Payee in several DME formats.
You can include payment exceptions on the clarification worklist. From here, you can branch to the document of contract account to check whether the exceptions are correct. In some cases, locks have to be reset; The appropriate items are then processed and paid during the next payment run.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-19
SAP AG 2003
CA daughter paysvia BP + CA father:
Payment
Bank details 2Payment method 2....CA document 1CA document 2 CA document 3
Total 1,2,3
Business partner
Father
Business partner
Daughter
Cross-Business Partner Payments
Cont. acct: Daughter
Bank details 1Payment method 1Payer: BP fatherPaid by: CA father ...CA document 1 CA document 3
Cont. acct: Father
Bank details 2Payment method 2....CA document 2
If you specify a different business partner and his or her contract account, the open items from all contract accounts that have the same payer are paid together.
The details needed for payment or collection (such as payment method, bank details, payment block reason, or alternative payer) are only determined from the contract account of the paying business partner.
Blocks in the paying contract account therefore also prevent the addition of items from the account to be paid. On the other hand, blocks on the account to be paid only prevent the addition of items to this account, not the items in the paying account.
The contract accounts are cleared when the payment program is run. Clearing is only executed when the paying business partner is also selected in the payment run parameters. Joint payment is only possible when the business partner is the parallel processing object.
In contrast to the payer, receivables for different contract partners are paid separately, not together, when you define an alternative payer.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-20
SAP AG 2003
Payment Run: Payment Cards
Overview of Payments
Payment Run - Program Flow and Parameters
Payment Cards
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-21
SAP AG 2003
DME
Payment run
Clearing account120 USD
Payment method K
BillingBilling
DME
Items to be billed
Billed items
..... .....
Business partnerwith payment cards
Card account120 USD
Payment Cards
Contract accountBank details 1Payment method K KCA document 50
Payment doc. -50
1120
DME
50 USD70 USD
50 USD70 USD
Receivables
Card account
1120
When credit card payments are processed in the payment run, no entries have to be made in the bank selection. The card account where the amounts reported to a credit card institute are posted , as well as the clearing account for the receivables created by billing have to be defined in posting area 1120.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-22
SAP AG 2003
FI-CA
FI
Tax account
Bank
Contract account
[4 ] 58.00
[1] 58.00
[1] 58.00
[2] 58.00 58.00 [3]
8.00 [1]50.00 [1]58.00 [2]
58.00 [2]
G/L account -Electricity
cardreporting account
Revenue account -Electricity
Example:Card payment of an open receivable
[3] 58.00 58.00 [4]
Cardclearing account
Payment Cards: Posting Process
Posting records: 1. Debit entry of the receivable 2. Clearing the receivable by the payment run; for the payment method credit card, clearing posting is
carried out to a reporting account. 3. Billing the receivables to the credit card issuer, creating the data mediums 4. Account statement: Payment receipt of billed items
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-23
SAP AG 2003
Payment Run
Overview of Payments
Payment Run - Program Flow and Parameters
Payment Cards
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-24
SAP AG 2003
Direct Debit/Repayments: Customizing
IMG Contract Accounts Receivable and PayableBusiness transactions
Payments
Define Own Bank Details and User Numbers Maintain Note to Payee Type for Payment Medium
Define Parameters for Foreign Payment Transactions
Define Specifications for Responsible Company CodeDefine Payment Methods
Define Bank Nodes for Payment Program
Maintain Bank SelectionDefine Payment Lock Reasons
Select Item Indicator for Clarification WorklistDefine Scope of Exception List
Check Number Ranges for Payment Orders
Incoming/Outgoing Payment Creation
Define Accounts for Posting Settlement Document
Define Accounts for Payment Card InstitutePayment Cards
Customizing of payments includes: Definition of house banks and bank clearing accounts (FI) Definition of payment block reasons, note to payee type Country-specific payment methods: Classification of payment method, document type, allocation, payment medium format, allocation of note to payee type
Parameters (company code specific): Minimum amounts for incoming and outgoing payments, Parameters (company code and payment method specific): Minimum and maximum amounts, processing foreign payments, bank group optimization, definition of value dates
You must define the application form for creating payment advice notes in the correspondence for correspondence type 0006 (basic functions for contract accounts receivable and payable).
You can make the basic settings for the payment card configuration in the IMG menu under: Cross Application Components -> Payment Cards -> Basic Settings.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-25
SAP AG 2003
The payment run includes the direct debit of open receivables, the refund of credits, and the clearing of open items.
When credits and receivables exist, these are cleared and the balance is paid.
Different formats and output media are used depending on the payment method.
Payment via credit card takes place through a card reporting account. In this case, the data media are created separately.
Payment: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-26
Payment - Exercises
Unit: Payment Topic: Making Payments
At the conclusion of these exercises, you will be able to:
Make payments
Create payment media
The receivables that are due from business partners who participate in the direct debit procedure are paid.
1 You are responsible for making the payments for business partner PICA0510## (PI0501C0##).
1-1 Payment run
1-1-1 Start the payment run for business partner PICA0510## (PI0501C0##) in mode “Start immediately”.
Create the parameters:
To create the parameters for the payment run, copy an existing payment run. Use the payment run from November 16th 2004 (identification IDUSA) as the copy template. Modify the parameters to meet your requirements. Use the following information for your payment run:
Date ID: Today’s date
Identification: P10## ## = Group number
Enter the parameters:
Business partner: PICA0510## (PI0501C0##)
Due date to: Today’s date
Posting date: Today’s date
Also select the Additional log option for your business partner.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-27
What is the result of the payment run?
1-1-2 What changes do you have to make to enable the payment run to pay your business partner’s items? _____________________________
Make the necessary changes and start the payment run again. Enter the parameters from your first attempt and use the copy template again. Use the identification P20##.
Determine the document number of the payment:
_____________________________
1-2 Payment by credit card
1-2-1 Business partner PICA0510## (PI0501C0##) informs you that he/she wants to make payments by credit card starting immediately. Enter the credit card information for the business partner in the payment transaction control:
Card issuer: American Express
Card number: 34123456##
Type of payment card: Credit card
Change the payment method to “K” (Credit/payment card) in the Payments/Taxes tab page of the contract account and enter the card ID.
1-2-2 First, post a miscellaneous receivable to the amount of USD 100.00. Use the following information:
Document date: 01.12.2004 Posting date: 01.12.2004 Currency: EUR (USD) Company code U100 (U300) Taxes: Calculate automatically → x
Enter the additional data using the”Business partner item list” function: Business partner: PICA0510## (PI0501C0##) Contract account: PICA0510## (PI0501C0##) Transaction: 6000 / 0020 Amount: 100.00
1-2-3 Now make the payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-28
Use the information from exercise 1-1-1 and add the payment method for the credit card to the Payment methods. You do not have to select a bank for this payment method.
Start the payment run immediately (identification P30##).
1-2-4 Display all the items that have not yet been billed to card issuer “American Express”.
1-2-5 Bill the items to card issuer “American Express” for your payment run (make sure that you select your payment run). Use the execution date and identification of the payment run from exercise 1-2-3 for your selection.
Enter the following file name
pcard## ## = Group number
1-2-6 Check the account display and see which billing document has been assigned to the document from the payment run and which name the billing run has been allocated:
Billing document number: _________________________________
Billing run identification: _______________________________
1-2-7 Once you know the identification of your billing run, you can navigate to the display of the billing data.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-29
Payment: Solutions
Unit: Payment Topic: Making Payments
1-1 Payment run
1-1-1 Starting the payment run
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → For Contract Accounts → Payment Run
Maintaining the parameters:
Use a copy template:
Enter 16.11.04 as the date and IDUSA as the identification. Choose Program run → Copy to go to parameter maintenance. Copy the template to today’s date and your identification P10##.
After the payment run is complete, choose Logs → Application Log to go to the payment run log. You can analyze the payment run messages in the No. Message (Number of Messages) column.
The result is that the contract account is locked with lock ID A (Blocked for Payment). A payment lock is entered in your business partner’s contract account.
1-1-2 You have to remove the payment lock from the contract account.
Choose: Utilities Industry → Business Master Data → Contract Account → Change.
Remove the lock for incoming payments and save the changed master data.
Copy your first run P10## and enter P20## as the identification.
Start the payment run again using the information from exercise 1-1-1.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-30
1-2-1 Choose: Utilities Industry → Business Master Data → Business Partner → Maintain Business Partner.
Select the contract partner role. In the payment transaction data, enter a payment card ID and assign it to card issuer American Express (type = 0001). Enter 34123456## (## = group number) as the credit card number and 01 as the type of payment card. The card has no expiry date. If there is more than one set of credit card details, select the Standard button for the relevant card.
Choose: Utilities Industry → Business Master Data → Contract Account → Change.
Change the incoming payment method to “K” in the Payments/Taxes tab page and enter the card ID.
1-2-2 Choose: Utilities Industry → Contract Accounts Receivable and Payable→ Document → Post and enter the required values.
1-2-3 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → For Contract Accounts → Payment Run
Copy one of your previous payment runs. Choose P30## as the identification. Use the information from exercise 1-1-1 and add the payment method for the credit card to the payment methods. You do not have to select a bank for this payment method.
1-2-4 Choose: Utilities Industry→ Contract Accounts Receivable and Payable → Periodic Processing → Data for Externals → Payment Card Organizations → List of Payments
Choose payment card type 0001 (American Express) and enter the execution date and identification of your payment run from exercise 1-2-3 in the selection criteria for the payment run. For the selection in the billing run, choose: Not yet settled. To start the evaluation, choose Program → Execute or the corresponding icon.
1-2-5 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → Data for Externals → Payment Card Organizations → Bill
Enter pcard## (## = group number) as the file name. Choose payment card type 0001 (American Express) and then enter the execution date and identification of the payment run from exercise 1-2-3 in the Selection for payment run fields. To start the evaluation, choose Program → Execute or the corresponding icon.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 6-31
1-2-6 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance and select list type All items.
Double-click on the document number of the payment run to display the details for the payment document. Choose Extras → Payment card supplement and the required information is displayed in the Settlement screen block.
1-2-7 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → Data for Externals → Payment Card Organizations → List of Settlements.
Use Program → Execute to start the analysis with the run ID from exercise 1-2-6.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-1
SAP AG 2003
Contents:
Overview of Returns Processing
Posting of Returns
Customizing
Returns Processing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-2
SAP AG 2003
This unit will provide you with an overview of:
The procedure and functions
Postings
and Customizing
of returns processing
Returns Processing: Overview
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Enter and post returns
Process return lots
Carry out the appropriate Customizing activities, for example:
Configure returns reasons
Pass on charges
Enter payment and dunning locks
Create returns correspondence
Returns Processing: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-4
SAP AG 2003
Returns Processing: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-5
SAP AG 2003
As the result of a payment run, an amount has been debited from the bank account of a business partner. However, this direct debit was not successful.
The payment document has to be reversed, company and bank charges have to be passed on to the business partner, and the incoming payment method has to be locked for a few days.
Returns Processing: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-6
SAP AG 2003
Returns: Overview of Returns Processing
Overview of Returns Processing
Posting Returns
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-7
SAP AG 2003
Reverse OI clearing or post new
receivable
Triggerposting of charges
Which items werepaid?
Does the return includecharges?
Pass on charges?
Own charges?
Returns: Activities 1
Questions regarding processing: - Can I reverse the clearing of paid items or post new (receivables) items? - Return for check payment or payment settlement? - Credit institute charges? - Pass on bank charges to business partner? - Debit own charges?
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-8
SAP AG 2003
Bill of exchange to cash payer
Accounting clerkReturns correspondence/returns history
Pass charges onCalculate graduated charges
Workflow
Returns: Activities 2
Further activities depend on:Returns reason, house bank, company code, number of returns, creditworthiness, tolerance group
Set locksDunning lock
Item levelContract account level
Payment lock incoming/outgoingItem levelContract account level
Deferral days
Lock duration days
ChargesPost charges statistically
Delete/change incoming/outgoingDelete / change item payment method
Payment method
Further activities
Further activities in returns processing: - Repeat direct debit?
If you defer the receivables and the temporary payment lock, the collection can be scheduled again. - Should no further direct debit take place?
By setting payment locks or deleting the payment method at line item level, you prevent the line item from being debited again. If you set the payment lock at contract account level, you lock the account against future direct debits.
- Should the accounting agent intervene? If event 0295 is defined, information can be sent to the agent, or other functions can be initiated.
You can have the system create different types of returns correspondence, depending on, for example, the return reason and credit rating. A correspondence request is generated in the system for the returns correspondence. You can then generate the letter from this request using the central print setting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-9
SAP AG 2003
Create Close Post Lot completed
Returns Lot: Processing Steps
Newlot
Post-processing
Enter items
Processing steps: 1. Create: A lot can be created interactively or by a program (for example a returns lot for account
statement returns). 2. Change: If a lot is not closed, items can be deleted or added. You can correct any data for items that
have already been entered. 3. Close: When a lot is closed, the header data and individual items can no longer be changed. However, a
lot can be opened again for processing. Once a lot has been closed, postings can be initiated. 4. Post: Once the lot has been closed, returns posting is carried out with the processing step Post. 5. Postprocessing: Postprocessing is necessary if the returns postings could not be performed.
You can use reports to process returns lots. These reports transfer data directly from either an application server file, the bank data storage for electronic account statements, or from a MultiCash file. They use this information to create one or more returns lots and enable users to process errors.
The application server file must have the format specified by SAP - that is, it may not contain any country-specific formats of electronic account statements.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-10
SAP AG 2003
Every return has an entry
in the returns history
Returns: Returns History
12/15/2002 123401/01/2003 367801/15/2003 4112
01/30/2003 4711Returns document 4711 Payment document 56789Amount 3,507.50Bank charge 1 7.50Bank charge 2 0.00....Returns charge 0.00....
Updating the returns history: Commercially applicable data - Amounts - Document numbers
Activities may be dependent on previous returns - The period under consideration - Number
Returns history is taken into account during the dynamic calculation of creditworthiness, whereby return reasons, number of returns, and chronological order are evaluated.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-11
SAP AG 2003
Dunning notices
Printcontainer
Printcreation
Creation of Printout with Print Container
Installmentplan
letter
Bank statement
Returnsletter
...
The correspondence component permits you to create paper records for the individual requests collected in the print container (for example account statements) and mass requests (for example bill printout, dunning notices, returns letters to the business partner).
The concept for printing correspondence has been defined in such a way that print orders are now stored centrally and processed. Previously, the printing of forms had to be initiated separately in the spool for each individual business transaction. You can limit the selection to individual business partners and correspondence categories, as well as execute test and repeat prints.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-12
SAP AG 2003
Returns: Posting Returns
Overview of Returns Processing
Posting Returns
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-13
SAP AG 2003
FI
FI-CACAcct1 FI-CA[1] 100.- 100.- [2]
Bank clearing
[2] 100.-
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2]
Posting: With Bank Charges 1
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-14
SAP AG 2003
FI
FI-CAContract account[1] 100.- 100.- [2]
Bank
[3] 100.-
Bank clearing
[2] 100.- 100.- [3]
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2]
Posting: With Bank Charges 2
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-15
SAP AG 2003
FI
Contract account[1] 100.- 100.- [2]
Bank
[3] 100.- 110.- [4]
Returns clearing acct
[4] 110.-
Bank clearing
[2] 100.- 100.- [3]
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2]
Posting: With Bank Charges 3
FI-CA
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-16
SAP AG 2003
FI-CA
FI
Contract account[1] 100.- 100.- [2][5] 100.-
Bank
[3] 100.- 110.- [4]
ReturnsClearing account
[4] 110.- 100.- [5]
Bank clearing
[2] 100.- 100.- [3]
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2][5] 100.-
Posting: With Bank Charges 4
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement) [5] Reverse clearing (return in subledger account)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-17
SAP AG 2003
FI
FI-CAContract account[1] 100.- 100.- [2][5] 100.-
Bank
[3] 100.- 110.- [4]
[4] 110.- 100.- [5]
Bank clearing
[2] 100.- 100.- [3]
Expense
[6] 10.-
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2]
10.- [6]
[5] 100.-
Posting: With Bank Charges 5
ReturnsClearing account
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement) [5] Reverse clearing (return in subledger account) [6] Post expense from bank charges
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-18
SAP AG 2003
FI
FI-CAContract account[1] 100.- 100.- [2][5] 100.-[7,8] 17.-
Bank
[3] 100.- 110.- [4]
[4] 110.- 100.- [5]
Bank clearing
[2] 100.- 100.- [3]
Expense
[6] 10.-
Revenue from returns
10.- [7] 7.- [8]
Receivables Revenue
[1] 100.- 100.- [1] 100.- [2]
10.- [6]
Receivables return
[7] 10.-[8] 7.-
[5] 100.-
Posting: With Bank Charges 6
ReturnsClearing account
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement) [5] Reverse clearing (return in subledger account) [6] Post expense from bank charges [7] Pass on bank charges to business partner [8] Raise and debit charges Step [7] does not take place if bank charges cannot be passed on to the business partner. Step [8] does not take place if you choose not to levy your own charges on the business partner. Levying your own charges for processing returns is optional. In the R/3 System, postings [5] to [8] are made in the course of one processing activity.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-19
SAP AG 2003
Returns: Customizing
Overview of Returns Processing
Posting Returns
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-20
SAP AG 2003
IMG Contract Accounts Receivable and Payable
Returns: Customizing 1
Business transactions
Returns
Assign Return Reasons to House Banks
Configure Returns Reasons
Define Bank Clearing Account for Returns
Define Charges Accounts for Returns
Define Clarification Accounts for Returns
Define Account Assignments for New Items with Returns
Determine Document Type and Clearing Reasons for Returns
Define Field SelectionDefine Field Selection for Returns
Define Transactions for Electronic Account Statement TransferDefine Time-Dependent Creditworthiness Ratings
Define Correspondence Form
Classification of returns according to bank and check returns. Definition and assignment of own return reasons to the house bank(s) reasons. Customize returns and processing activities:
Charges/debiting of charges Deferral days Define locks and forms Define information for accounting clerk Amount limits, creditworthiness. Clearing accounts, revenue and expense accounts, receivables account and clarification account. Configuration of entry lines for the dialog processing returns lots Define account assignments for new items with returns: When posting returns, you can define a mode that generates new open items. You can define the main and subtransactions for these new items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-21
SAP AG 2003
To process returns, you define return types and return reasons.
Depending on the cause and the origin of a return, some activities can be executed automatically.
The returns charges that can be passed on to customers can include your own charges (in addition to bank charges).
When processing a returns lot, the system updates the returns history.
Returns Processing: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-22
Returns Processing - Exercises
Unit: Returns Processing Topic: Entering Returns
At the conclusion of these exercises, you will be able to:
Process returns in FI-CA.
You have carried out a number of payments. Due to insufficient funds in the accounts of some business partners, your house bank cannot carry out certain payment orders. Your bank sends you the returns information, together with a debit charge.
1 Returns
1-1 Configuring the returns reason
1-1-1 Configure return reason G## (## = group number) using the following parameters and activities:
Returns category: Bank return History days: 30 Creditworthiness number 5
The returns activities must be as follows: The incoming payment method of the contract account must be blocked for 7 days for the combination of company code U100 (U300), 0 number of returns, 0 creditworthiness and the tolerance group 001 of the contract account. Charges must be passed on, posted in the general ledger if relevant, and graduated charges must be calculated. Correspondence must also be created.
Charges must total 5.00 EUR (USD) for a returns amount of 20.00, and 7.50 EUR (USD) for amounts above 50.00.
If the difference between the original payment amount and returns amount is 15.00 EUR (USD) or less, the system interprets it as a bank charge.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-23
1-2 Enter returns Enter a returns posting for the payment made by business partner PICA0510## (PI0501C0##).
1-2-1 Use the following information:
Returns lot: RL06010## Search term: Returns group 0## Currency: EUR (USD) Company code U100 (U300) Amounts contain bank charges: X Calculate charges: X
Enter the returns item: B selection value: Document number from the Payment unit Return reason: G##
Once you have confirmed with ‘Enter’, the original payment amount that the system has determined is displayed in the ‘Returns Amount’ field. Increase this amount by 10.00. Once you have chosen ‘Enter’ again, the system interprets the difference as a bank charge and displays the amount in the ‘Bank Charge 1’ field.Save your entries.
Close and post the returns lot.
1-2-2 Use the account display to check the update of the returned item. In the account balance display, also check that the incoming payment block has been set correctly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-24
Returns Processing - Solutions
Unit: Returns Processing Topic: Entering Returns
1 Returns
1-1 Configuring the returns reason
1-1-1 In the IMG, select Financial Accounting → Contract Accounts Receivable and Payable → Business Transactions → Returns → Configure Returns Reasons Choose ‘New Entries’ and enter G## (## = group number) as the identification with name ‘ID of returns reason group ##’.
Define this returns type as ‘Bank returns’, enter 30 in the History field and 5 in the Creditworthiness Number field.
Double click on the Returns Activities level in the document structure. Confirm the information message that appears and select New Entries.
Enter the following data:
Company code U100 (U300)
No. of Returns
Creditworthiness
Tolerance group 0001
Incoming payment lock contract account
A
Lock duration days 7
Pass charges on X
Calculate graduated charges X
Create correspondence: X
Double click on the Returns Charges level in the dialog structure. Confirm the information message that appears and select New Entries. Enter the following data:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 7-25
Currency EUR (USD)
Amount limit 20
Graduated charge 5
Select F8 and enter:
Currency EUR (USD)
Amount limit 50
Graduated charge 7,50
Select the Automatic Charges Determination level from the dialog structure and choose New Entries. Enter the following data:
Currency EUR (USD)
Max. difference 15
Save your entries.
1-2 Entering returns
1-2-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Returns → Returns Lot Choose Create.
Enter the required data in the returns lot. In the item data, enter the document number of the payment from the ”Payments” unit, and the Returns reason G##.
1-2-2 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance.
A new document has been posted with the transaction text ‘return charg. stat’. Select the Contract Account button (ctrl + F6) and check the payment lock in the Payments/Taxes tab page.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-1
SAP AG 2003
Contents:
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
SAP AG 2003
Incoming Payments
SAP AG 2003
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-2
SAP AG 2003 SAP AG 2003
At the conclusion of this unit, you will be able to:
Use the payment lot functions for entering incoming payments
Enter incoming payments in the cash journal
Allocate or refund unclarified payments received from the clarification worklist
Incoming Payments: Unit Objectives
SAP AG 2003
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-3
SAP AG 2003
Incoming Payments: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-4
SAP AG 2003
You have to enter the payments of your business partners on a daily basis.Your business partners pay their open bills by bank transfer or in cash.
You enter the incoming bank transfers in a payment lot.
You post cash payments in the cash journal.
You use a clarification worklist to manage payments that you cannot allocate.
Incoming Payments / Clarification Processing: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-5
SAP AG 2003
Payment Lot
123.13 USD43.45 USD
345.36 USD
Check lot
345.34 USD230.00 USD
Incoming Payments: Functions
85.00 USD123.45 USD
Payment card lot
34.00 USD210.46 USD
Payment order lotKarl Einstein
Bank transfer 9.500Date
A payment lot, credit card or check lot can be entered online. The payment lot can also be created using a program (lot of incoming bank transfers, for example). Report RKFFZE00 transfers payment data and creates one or more lots for payments, payment orders, credit card payments or checks. To do this, the report executes the following steps: 1. It reads the application server file that has been entered and checks the data it contains 2. If these data records are correct, the report creates one or more lots.
3. If the corresponding indicators have been set, it closes and posts the lots. Incorrect data records are saved separately and can be used once they have been corrected. You can find out more about the prerequisites and characteristics of the report by reading the report documentation.
Cash, check and credit card payments can be entered in the cash desk, or by using the cash desk in the active cash journal.
If you use a payment order instead of a payment posting the payment program does not post a payment document and the paid items are not cleared. Instead, the system generates and saves a payment order. The payment is posted later based on the bank statement, the selection of accompanying open items using the payment order. The paid items are locked for other clearing transactions and other payment runs until the payment is posted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-6
SAP AG 2003
Incoming Payment: Payment Lot
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-7
SAP AG 2003
The payment lot stores all information about payments initiated externally. This information is needed for follow-up processes, such as:
Posting of payment use (clearing open items, generating payment on accounts and corresponding mixed transactions).
Posting to an interim account if use of payment is unclear.
Determining the use of payment and transferring from an interim account to a contract account.
Triggering a repayment if the payment use cannot be determined.
Printing a check deposit list for a check lot.
Payment Lot: Use
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-8
SAP AG 2003
Lotprocessed
Incoming Lot: Processing Steps
Post
Display/change
Clarificationworklist
CreateNew lot
Post-processing
Close
Processing is essentially the same for payment lots, payment card lots, payment order lots and check lots. In some cases the screen variants for entering the item may be different depending on the lot type being used. If you use the standard variant SAP (automatically generated by the system), fields that are not required at that point in time are hidden.
Processing steps: 1. Create: A lot can be created online (for example, a check lot) or via a program (in the case of a
payment lot of incoming bank transfers from an account statement, for example). 2. Change: If a lot is not closed, items can be deleted or added. You can correct any data for items that
have already been entered. 3. Close: If a lot is closed you can no longer delete or add items. Once a lot has been closed, postings
can be initiated. You can also correct lot items (such improvements to selection criteria) after lot has been closed.
4. Post: Once the lot is closed, payment allocation is carried out in the Post step. 5. Postprocessing: Postprocessing is necessary if postings have been generated for an interim account or
if postings have not been carried out at all. Clarification worklist: You can use central clarification processing for clarifying payments that cannot be assigned.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-9
SAP AG 2003
Generate Payment Lot
123.13 USD43.45 USD
345.36 USD
120.00 USD349.90 USD
1250.45 USD456.90 USD
Doc. 123123.13 USD
Doc. 126120.00 USD
Doc. 1281250.45 USD
Display/changeincorrect data records
DMEDME
FF.5 Bank datamemory
FPB17
Transfer data from MultiCash
FPB7
Read elec. bank statement
Display/changeincorrect data records
Transfer data from electronic bank statement
The bank transfers from an account statement are stored in a payment lot. Payments are assigned when the payment lot is processed.
Interfaces: Data Transfer from Account Statement to Payment/Returns Lot RFKKKA00 (transaction FPB7): The report selects payments, returns and payment orders that are imported into the bank data memory during the processing of electronic bank statements for the component Cash Management (TR-CM). If necessary,the FI-CA data can be transferred directly to a payment lot, payment order lot or returns lot. Alternatively, you can output selected data from the bank data memory in a file. You can then import the files created to payment lots, payment order lots or return lots in a later step. You can do this using the FI-CA transfer programs RFKKZE00 (payments, payment orders) and RFKKRL00 (returns). The system uses the business transaction and the amount +/- sign to decide the lot type a payment position is transferred to.
Data transfer from MultiCash files to payment, payment order and returns lots RFKKKA00 (transaction FPB17): If you convert country-specific bank formats into MultiCash format, you can use this report to transfer data from the MultiCash statement file and line item file to payment and returns lots in FI-CA. However, in order to be able to process MultiCash files, you must make the system settings described in the 'Prerequisites' section of the report documentation.
The files can also be generated using neutral interfaces. However, these must have the SAP format - which means they must not contain any country-specific formats from the electronic bank statements.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-10
SAP AG 2003
Note to payee
Customer number 10004711Contract 0815, budg. bill. from 05/01/03 + Interpretation rule
for note to payee
Business partner C acct Contract Other info Due by 05/10/03
10004711 2100.00
Interpretation Rules: Note to Payee
Define interpretation rules for note to payee: In this activity, you define the rules for the automatic analysis of note to payee texts for the automatic transfer of payment data to payment lots in Contract Accounts Receivable and Payable. Using the values determined, the system then determines the selection criteria for the assignment of payments to receivables. If you want to subject the values found in this way to an additional check, you can specify a check procedure for each structure sample. This check procedure has already been defined for the interpretation of the note to payee based on sample function module FKK_SAMPLE_SEL_TYPE_CHECK in the check procedure Customizing activity. In order to simplify the settings of the interpretation rules for the note to payee, the note to payee analysis can be tested in a Customizing activity.
When payment data is transferred using the reports RFKKZE00 or RFKKKA00, you can still use the function module called up at event 0950 to make application-specific or customer-specific enhancements for payment or additional selections. For further information see the report documentation or the event description (FQEVENTS).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-11
SAP AG 2003
Incoming Payment: Postings 1
FI
FI-CAContract account
[1] 50.-
[1] 50.-
Bank
Receivables Revenue
50.- [1]
Cash clearing
Postings: 1. Debit entry from invoicing (shown without tax posting)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-12
SAP AG 2003
Incoming Payment: Postings 2
FI
FI-CAContract account
[1] 50.-
[1] 50.-
Bank
Receivables Revenue
50.- [1]
Cash clearing
[2] 50.- 50.- [2]
Postings 2. Incoming payment at the bank (the account statement is posted in the general ledger)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-13
SAP AG 2003
Incoming Payment: Postings 3
FI
FI-CAContract account
[1] 50.-
[1] 50.-
Bank
Receivables Revenue
50.- [1]
Cash clearing
[2] 50.- 50.- [2][3] 50.-
50.- [3]
50.- [3]
Postings 3. Payment allocation by processing the payment lot
In the case of payment lots, items from the bank clearing account are posted to payment usage or to the interim account. The document number is stored in the corresponding items in the payment lot.
Payment usage can include the following: - Clearing/partial clearing of open items - Postings on account - Expense/revenue (payment differences) - Creation of new debit entries that are immediately cleared via payment allocation. (Charges or
interest, for example) - Down payments
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-14
SAP AG 2003
Paymentdoc. 127
349.90 USD
470.35 USDZ: 1004711
Lot 1Payment advice: 1004711
Customer: 10000815Max Donaldson Corp.
Bill no. Amount2001234 120.453003461 349.90
∑ 470.35
Max Donaldson Corp.Acct.: 0815
Doc. Amount Open
2001234 120.45 120.45
3003461 700.35 349.90
4001234 600.87 600.87
Additional selection through payment advice
Payment allocation according topayment advice criteria
(under/overpayment possible)
Copy payment advice
Selection type: Payment advice
Payment Advice
PaymentDoc. 126
120.45 USD
31 2
3
1
2
You can use payment advice notes to enter details on announced payments. You can use the key created during the generation of a payment advice note as selection criteria for open items.
In addition to the business partner or the contract account, you can also use the payment advice note number as selection criteria when entering a payment lot. When the payment is posted, the system selects the open items of the business partner in the payment advice note. The system uses the entries in the payment advice note items to allocate clearing amounts to the selected items. Any amount differences that occur if the amount from the payment advice cannot be completely distributed (that is, if the open item amount is smaller) are combined into a posting on account.
Report RFKKAV00 also transfers payment advice notes from a sequential file: The report uses the data to generate one or more payment advice notes. It carries out the following activities: • Reads the application server file specified and checks the data contained therein • Creates one or more payment advice notes provided the data records are correct • Closes the payment advice notes provided the corresponding indicator is set. • Defective data records are saved separately and can be transferred once you have corrected them.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-15
SAP AG 2003
Revenue Distribution
Contract account 4
Receivable 320.45 USD
Last recipient XYZ
Contract account 3
Receivable 220.45 USD
Last recipient XYZ
Contract account 2
Receivable 520.45 USD
Last recipient XYZ
Contract account 1
Receivable 120.45 USD
Last recipient XYZ In
com
ing
paym
ent
Distribute revenue
Post distributionRFKKRD00
Contract account Last recipient XYZ
Credit 1,268.65 USD
∑
You can use revenue distribution to manage receivables for third parties and forward incoming payments to the final recipient. The industry component IS-T uses this functionality to bill third party-services in the deregulated telephone market.
When bills are posted, the final recipient can be recorded in the open items either manually when a document is posted, or automatically using an installation-specific function module that is processed at event 0045. For an example,see the SAP sample function module FKK_SAMPLE_0045. You can also use the SAP function module FKK_REVENUE_DIST_0045 to determine the final recipient from the attributes of a business partner. For further information, see the function module documentation.
The mass activity Revenue Distribution can then be used to select the payments in the system that still have to be distributed. The system creates a history. An installation-specific function module called at event 5415 enables you to exclude individual documents or document items from revenue distribution. You can, for example, allow a period of four weeks to pass before you pass on a payment to the final recipient.
The transaction Post Distribution creates totals for every final recipient using the amounts to be distributed. These summary documents are also created according criteria such as currency or main and subtransaction. This reduces the number of open items in the final recipients' accounts. For further information, see the documentation on the report RFKKRD00.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-16
SAP AG 2003
Incoming Payment: Clarification Worklist
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-17
SAP AG 2003
Payment form no.Business partnerDocument no.Contract accountContractGross amount
Clearing ControlIndividual criteriaManual allocation
Payment posting
Open items
Incoming payment
Incoming Payment: Payment Allocation
Selection criteria for open items in incoming payment: Amount (allocation if amount is equal) Number of the business partner/contract account/contract Document number of the open item Payment form number: This number encompasses several open items. All items included in one bill or one dunning can be summarized and paid using one number. The items summarized in this way are stored in the transparent table DFKKZR and can be displayed using the transaction FPZP.
You define codes for selection criteria of payment lot items in Customizing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-18
SAP AG 2003
Tolerance limit3.50 USD
Tolerance limit< 3.50 USD
Incoming payment270 USD
Receivable 273.50 USDCleared
Spec. difference acct:Posting 3.50 USD
Receivable 270 USDCleared
Outstanding receivable3.50 USD
Incoming Payment: Tolerance Limits
Receivable 273.50 USD
Using the tolerance groups entered in the contract account, you can define and use tolerance limits for incoming payments.
If the tolerance limit of the incoming payment is not exceeded, a tolerance account (set up in customizing) is used to post the difference between the open receivable and the payment. The receivable is then cleared in full. In order to do this, the clearing control must be set to allow tolerances to be posted.
If the difference between the open receivable and the incoming payment exceeds the tolerance limit defined for the incoming payment, the open item is partially cleared and the difference stays in the contract account as an outstanding receivable.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-19
SAP AG 2003
Doc. 127456.90 USD120.00 USD
349.90 USD
250.45 USD456.90 USD
Doc. 126120.00 USD
250.45 USD349.90 USDTransfer
Lot 1
Lot 2Doc. 198
349.90 USD
Doc. 199250.45 USD
Clarificationworklist
2
3
1
1
1 Payment Allocation
No payment allocation possible2
3
Payment Lot: Clarification Worklist
interface
DME
32
Central clarification processing is provided to clarify payments that cannot be assigned. The clarification cases for all payment lots are stored in a separate clarification worklist.
The list of clarification cases to be displayed can be restricted in the selection screen for the clarification worklist using selection criteria. The clarification cases to be displayed can be further restricted with organization units of an organization structure.
The clarification cases can be processed in parallel by more than one clerk. To do this, clarification cases can be reserved for processing. These clarification cases cannot be processed by other users. Cases that are reserved but not clarified can be released so that they can be accessed again by other clerks.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-20
SAP AG 2003
Paymentlot
Paymentrun
Clarif. WorklistPayment run
List - Payment lot List - Payment lot
Total list ofadministrator
Clarif. WorklistPayment Lot
SB1 SB2Doc. 4711Doc. 4712Doc. 4713...
Doc. 4811Doc. 4812Doc. 4712...
Doc. 4711Doc. 4712Doc. 4713Doc. 4811Doc. 4812...Accounting clerk determ.
Accounting Clerk Assignment
Doc. 4712Not SB1,
but SB2!!!
The clarification worklist can be included in a worklist. SAP supplies the following two sample workflows for this. They can be used to create individual workflows: Standard workflow A workflow must be allocated to a clerk before it can be sent to a workflow inbox. Agent assignment and agent restriction ensure that clarification cases are only assigned to an agent once. This means that if an agent cannot process and complete a clarification case, the case is sent automatically to another agent.
Ad hoc workflow - WS21000077 No agent allocations or restrictions have to be made for this workflow. If an agent cannot clarify a case, he or she determines the next agent and forwards the case to them. For this workflow, make the setting for a workflow with direct advance in the general workflow settings so that the next processor query appears immediately after processing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-21
SAP AG 2003
Clarification Proposal
Selection from payment lot
+Clarification proposal according to personal settings:
• Analyze note to payee (interpretation rules)• Business partner with same bank details• Evaluation of similar clarification cases
Immediate display or call
+
Due amountsLast payments
Exception account for payment clarification (FP05_PROP)
Error-tolerant search+
Partial / clearing of open itemsPayment on accountTransfer posting to a clearing accountInitiate repayment of amount
When you call up a clarification case, the system automatically suggests a clarification proposal. You can define the range of the clarification proposal in your personal settings. In addition to the proposed business partners, the system can display their most recent payments and due items, it can search for similar numbers (for example document and account numbers) and can switch to the clarification processing screen so that you can distribute the payment amount between several partners, contract accounts or contracts.
In the clearing proposal, you can delete proposed lines, select all proposed lines or reverse the selection in all lines.
In some cases, the clarification proposals from previous clarification cases are not helpful. This can apply, for example, to payments made by social services or pension offices. Although the payments originate from the same bank account, the payments can be made for many different business partners. Previous, incorrect clarifications are also an example of this. If a payment was allocated to the wrong business partner and re-allocated later, the system will always propose the wrong business partner whenever a payment is made using that bank account. The function 'Maintain Exception Accounts for Payment Clarification' enables you to define different rules and individual default values for creating proposals that clarify incoming payments.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-22
SAP AG 2003
Selection proposals
Note to payee
Business partner CAcct Contract Other info Amount4711 100.00
Customer number 10004711Contract 0815 + Interpretation rule
for note to payee
Clarification
Business partner CAcct Contract Other info Due by 05/10/0310004711 2100.004711 0.00
Interpretation: Note to Payee
Proposal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-23
SAP AG 2003
Clarif. account
123.23234.76
ClearPayment on account
Re-payment
Incominglot
General ledgertransfer posting
Payment run
Payment Lot: Postprocessing
Causes: No payment allocation possible Posting to the clarification account in the payment lot
Measures: Business partner / contract account clarified and known - Post or post with proposal from clearing control - Post online: Manual allocation (selection of open items for the business partner) - Payment on account
Business partner / contract account clarified but cannot be assigned in FI-CA Payment has to be allocated to another department - Transfer posting to general ledger account
Business partner/contract account unknown - Repayment
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-24
SAP AG 2003
Repaymentrequest
Paymentrun
Clarification Repaymentactive
Payment method
Clarif.worklist
Paymentdocument
Repayment Request
Repaymentflag / payment method
Paymentlot
Post-processing
If allocation of an incoming payment is not possible, you can trigger a repayment by setting the "Repayment" indicator in the item of the incoming lot.
The bank details from the bank transfer information are used for the refund. The repayment itself is performed by the payment run. The “Repayments" indicator must be set in the payment run parameters.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-25
SAP AG 2003
Posting Procedure: Repayment (1)
FI
FI-CAContract account
[1] 50.-
[1] 50.-
Bank
Receivables Revenue
50.- [1]
Cash clearing
[2] 50.- 50.- [2][3] 50.-
50.- [3]
50.- [3]
1) Incoming payment: Bank to bank clearing 2) Allocation not possible: Clarification worklist - bank clearing to clarification account 3) Clarification not possible: Repayment request generated - clarification account to repayment clearing
account 4) Repayment in payment run: Repayment clearing account to bank clearing account 5) Electronic bank statement (outgoing payment): Bank clearing account to bank
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-26
SAP AG 2003
FI
FI-CA
Bank[1] 20.--
[3] 20.--
[2] 20.-- 20.-- [1]20.-- [5]
20.-- [2]
Unclarified payments received
Bank clearing /Incoming payment
Repaymentclearing account
Example:• Payment received: USD 20• No payment allocation possible
[4] 20.--
Bank clearing /Payment Run
[5] 20.--20.-- [3] 20.-- [4]
PosAr 1040
PostAr 0130
PosAr 1061
Payment method - House bank
Posting Procedure: Repayment
No posting is madeto a contract account
1) Incoming payment: Bank to bank clearing 2) Allocation not possible: Clarification worklist - bank clearing to clarification account 3) Clarification not possible: Repayment request generated - clarification account to repayment clearing
account 4) Repayment in payment run: Repayment clearing account to bank clearing account 5) Electronic bank statement (outgoing payment): Bank clearing account to bank
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-27
SAP AG 2003
Incoming Payment: Credit Processing
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-28
SAP AG 2003
Credit Processing
Credit items
...
Clarify
Transfer
Pay
Clear
Transfer post
Write-off
Remain
Send letter
Generate credit list
Process credit
FPTCRPODoc. 101
-71.20 USDBP 1
Doc. 128-45.34 USD
Doc. 101-82.20 USD
BP 2Doc. 128
-23.74 USD
Doc. 101-53.20 USD
BP 3Doc. 128
-68.55 USD
Clarification worklist FPCRPO
You can use the following functions if the credit use has to be clarified for your business partner's contract accounts: Credit clarification Credit processing
The following types of credit can be processed with the credit clarification function: Credit that was previously selected by the mass activity Generate Credit List and sent to clarification processing.
Credit that was directly included in the clarification worklist as a result of Customizing settings The Process Credit function should only be used for manually processing individual credit that has not been entered by the credit list
The activities Remain and Send Letter can be used for processing in credit clarification.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-29
SAP AG 2003
Cash Journal / Cash Desk
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash Desk
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-30
SAP AG 2003
Cash Journal Functionality
Partial or full withdrawal
Compare cash desks
Cash desk deposit
Current cash balance
Call cash desk
Lot display
Historical data
Cash desk closingOpen/close cash desks in local branches
Special functions
Environment
Functions
CD Structure Role Concept
Basics
The enhanced cash desk functionality includes the mapping of a cash desk structure and a role-based authorization concept. Cash deposits, withdrawals and differences can be posted posting documents can be created along with a detail display of the document. In contrast to the original cash desk functionality and its evaluation options (only via the payment lot), evaluations can now be made in the cash journal based on payment type and currency, cash desk and current or historical documents.
When the cash desk is closed, the system compares the actual and the target balances in the cash desks of the cash journal and highlights any differences. A currency unit sheet makes it easier to enter the actual cash desk balances. You can enter the coin and note units in the currency unit sheet. Once you have saved this information, you can print cash desk closing. It can also be printed at a later date. You can open and close cash desks, regardless of whether a cash desk closing is to be executed for a cash desk. Cash desk closing does not have to be executed for opening and closing cash desks. However, if cash desk closing is executed for a a cash desk, this cash desk is automatically closed. If you want to make further postings to this cash desk, you must open the cash desk again.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-31
SAP AG 2003
Cash Desk Structure
Branch/local office
Double-level cash desk hierarchy
Default values:Company codeBank clearing accountLot/payment category
Default values:Company codeBank clearing accountLot/payment category
Default values:Company codeBank clearing accountLot/payment category
Default values:Company codeBank clearingaccountLot/payment category
Cash desk 1 Cash desk 2 Cash desk ... Cash desk n
The cash journal can map the cash desk structure of a company. The cash desk structure includes the cash desks in the individual branch offices of a company. The cash desks in the branch offices form the master data of the cash desk structure and are, therefore, a prerequisite for the cash journal.
The company code and the bank clearing account, as well as lots that have already been created according to the payment category, are proposed depending on the cash desk. If an open lot is not available, the system automatically creates a corresponding payment lot. The branch and the cash desk are the first 5 figures of the name.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-32
SAP AG 2003
Role Concept
YESYESYESNONOYESNONOYESCashier
YESYESYESYESYESYESYESYES
NOYESCashier with
special tasks
YESYESYESYESYESYESYESYESYESBranch office manager
Create and close
lot
Historical data
Cash balance
Transfer responsibility
Differences
Deposit
Withdraw
al
Open and close
Call cash desk
Role-specific activities
Role
Activity
Role concept (optional - can be activated/deactivated in Customizing) Branch office manager standard role 21000058 Cashier with special tasks: Standard role 21000059 Cashier: Standard role 21000060
can be allocated different activities. Users are allocated to roles using the transaction PFAC_INS or in the Customizing settings for responsibilities. Activities can also be individually allocated to the roles in Customizing, or configured according to the standard system. The overview displayed above represents a standard allocation.
Activity per role Branch office manager - All activities for all cash desks in the branch office. For example, entering incoming and outgoing
payments, posting deposits, transferring responsibilities, posting differences, posting withdrawals, the historical evaluation of all cash desks in his or her area of responsibility and opening/closing cash desks.
Cashier with special tasks - All branch office manager activities except for closing cash desks in the branch office.
Cashier - Entry of incoming and outgoing payments in his or her cash desk and posting deposits.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-33
SAP AG 2003
Individual Enhancement of Cash Journal
EventsEvent 6120:
Call additional menu functions
Historical cash balance Cash movement Check withdrawalPostal order Total of cash movements
Bar code reader
Replace standard function, for example, cash balance
Event 6130:
Account determination different to posting area 0150 and 0160
Event 6140:
Checks before an action such as closing the cash desk
Bar code reader For example, the customer data and the amount to be paid for each bar code are stored on the bill. A customer pays the bill and takes it to the cash desk. The cashier scans the bar code. The data for the business partner, contract account, amount and so on is already entered in the corresponding fields in the cash desk.
There are 5 additional customer functions that can be activated and used for event 6120.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-34
SAP AG 2003
ReceiptYou paid USD 123.45 on 05/15/2003....
Check deposit list
Cash Desk
00000150900 12131400 67291500 11Pleas e do not writ e in this area
CityBankCurrencyAmountPay to the or der of
Amount in words
oder Über bringeran
Ort
Date
Signature
Do n ot alter t he print ed tex t..
Check No. Account No.X X Amount X Bank Code X Text
New York1.4.1996
UNI - 400,-Four hundred -
UNICEF
Contract account
Postdirectly
Postonline
Post on account
Business partner
Contract account
Contract
Document no.
Net due date
Payment form no.
The cash desk has been integrated into the cash journal. This means that all incoming and outgoing payments are posted using the cash desk. You can navigate directly to the cash desk from the cash journal and back. The system transfers the cash desk allocated to an agent and other allocations (made by the system or the user) to the cash desk. When the Cash Journal transaction is activated, you cannot directly call up the Cash Desk transaction.
Caution: If you activate the cash journal later, you cannot evaluate the postings that you made in the cash desk before activating the cash journal in the cash journal. You should therefore avoid changing settings (cash journal active/not active) during running operation.
In the Payment at cash desk function, you can allocate payments directly to the open items of the business partner. You can use a payment proposal from clearing control or allocate the payment manually.
Payment at cash desk includes cash, check or credit card payments. You can print a receipt subsequent to posting. You can select the application form for printing the receipt in the activity Define Application Forms for Correspondence (under Basic Functions for Contract Accounts Receivable and Payable).
With a (cash) overpayment, you can use the remaining amount to decide whether to post on account or whether the amount should be paid out.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-35
SAP AG 2003
2. Expand installment planClearing proposal
#4711 08/30/2002 250.50 50.00
#6789 09/25/2002 149.50
Payment on Installment Plan
1. Clearing proposal
50.00
50.00
No. Due Inst. amount1 01/09/2003 100.002 02/09/2003 100.003 03/09/2003 100.004 04/09/2003 100.00
Installment plan #0815
Source receivableNo. Due Amount#4711 08/30/2002 250.50#6789 09/25/2002 149.50
Post item in dialog
If, during the clearing proposal, the allocated open item turns out to be an installment plan item, you can display the installment plan and, if necessary, change it during the online processing of the clearing proposal for clearing the source receivables.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-36
SAP AG 2003
Incoming Payment: Customizing
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash Desk
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-37
SAP AG 2003
Incoming Payments: Customizing (1)
IMG Contract Accounts Receivable and PayableBusiness transactions
Payments
Define Short Acct Assignments for Transfer Posting to Cash Desk
Incoming/Outgoing Payment Processing
Define Specifications for Cash Desk
Maintain Responsibilities for User of Cash Journal
Cash Journal
Cash Desk
Maintain Specifications for Cash Journal Define Master Data for Cash Journal
Define Accounts for Expense/Revenue from Cash PaymentsDefault Values for Posting Cash Desk Deposits and Withdrawals
Maintain Authorizations for Cashier with Special TasksMaintain Authorizations for Branch Office Manager
Maintain Authorizations for Cashier
Maintain Role-Specific Activities for Cash JournalDefine Currency Units of Notes and Coins Sheet
If you want to use the cash journal in your company, you must carry out the following in the Customizing menu for contract accounts receivable and payable under Business Transactions -> Payments -> Incoming/Outgoing Payment Processing -> Cash Journal: Prevent the cash desk from being called up directly by flagging the Cash Journ. Act. indicator in the activity: Maintain Specifications for Cash Journal.
Make the basic settings and master data in the activities: Maintain Specifications for Cash Journal and Define Master Data for Cash Journal.
When defining Default Values for Posting Cash Desk Deposits and Withdrawals, make sure that you maintain different bank clearing accounts for deposits and withdrawals. However, you can enter the same G/L account for deposits and withdrawals. You can use user roles to control the authorizations for postings and evaluations in the cash desk. In order to do this, you must activate the role concept by setting the Use Roles indicator in the Maintain Specifications for Cash Journal activity and by allocating roles to the individual users (cashiers) in the activities under Maintain Responsibilities for User of Cash Journal.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-38
SAP AG 2003
Incoming Payments: Customizing (2)
IMG Contract Accounts Receivable and PayableIncoming/Outgoing Payment Processing
Define Default Values for ... Lot(s)Define Screen Variants for Payment Lot
Define Bank Clearing Accounts for Payment Lots
Define Clearing Account for Check DepositDefine Clarification Account
Define Specifications for Repayment of Incoming PaymentsCheck Number Ranges for Repayment RequestsDefine Transactions for Electronic Bank Statement TransferDefine Programs for Converting Country-Spec. Formats into MultiCash
Define Prefix for Created Lot IDs during Account Statement TransferCheck Procedure for Interpretation of Note to PayeeDefine Interpretation Rules for Note to PayeeTest Interpretation Rules for Note to PayeeDefine Bank Accounts with Individual Clarification ProposalDefine Short Account Assignments for Transfer PostingsDefine Forms for Check Deposit List
The Customizing for processing clarification worklists is supplied by SAP (see the IMG structure under Contract Accounts Receivable and Payable -> Technical Settings -> Prepare Processing of Clarification Worklists). Check and, if necessary, modify the settings.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-39
SAP AG 2003
Incoming Payments: Customizing (3)
IMG Contract Accounts Receivable and Payable
Business Transactions
Define Document Types for Credit Clarification
Credit
Define Selection Criteria for Credit Clarification
Define Clearing Account for Transferring Credits
Define Specifications for Revenue Distribution
Revenue DistributionDefine Specifications for Deriving Final Recipient
Define Main and Subtransactions for Distribution Posting
Selection criteria for clarifying credit. Field Immediately: Ensures that a line item that fulfills the Customizing criteria is inserted directly in the credit list for clarifying credits.
If you do not set this indicator, the line items are inserted in the clarification worklist when you call the credit list.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-40
SAP AG 2003
You can use the payment lot and the cash desk function that is integrated in the cash journal for managing incoming payments.
Payment lots are used for entering external payments. Payments that have the same source or that are to be processed together are stored in a payment lot.
You use a clarification worklist to manage payments that you could not be allocated.
you can use credit clarification to select and process credit and payments on account that have not been allocated.
Incoming Payments: Summary (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-41
SAP AG 2003
The cash journal and its integrated cash desk functionality enable you to log and evaluate postings made to a company's cash desk.
Incoming and outgoing payments can be made using different payment types in the cash desk.
You can print out a receipt for a payment made at the cash desk.
Incoming Payments: Summary (2)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-42
Incoming Payments / Clarification Processing - Exercises
Unit: Incoming Payments Topic: Entering Payments
At the conclusion of these exercises, you will be able to:
Enter payments using the payment lot or the cash desk.
Use the central clarification tools to allocate unclarified payments.
You have to enter the payments of your business partners on a daily basis.
Your business partners pay their open bills by direct debit or in cash.
1 Incoming payments
1-1 Enter a payment lot.
1-1-1 Use the following information:
Name of payment lot: ZS-## (## = Group number)
Search term: Payment lot group 0##
Currency: EUR (USD)
Bank clearing account: 113100
Value date: Today’s date
Company code: U100 (U300)
Which reconciliation key does the system form? ____________
Which selection categories does the system propose? ___________
Enter check lot items with variant SAP.
Enter a payment in the amount of USD 100.00 for business partner PICA0710## (PI0701C0##).
Save your entries.
Then close and post the payment lot.
Check the status of the payment lot to see how it was processed.
What is the status of the payment lot when all the payments were processed? ________________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-43
Write down the assigned document number: _________________________
Go to the account display and check the payment allocation. Which list type do you have to select to spot clearing entries? ________________________________
1-2 Central clarification processing
Unclarified received payments are processed in central clarification processing. The unclarified payments that you have to process have the following name:
CA240-0## (ZIUT240-00##) ## = Group number
1-2-1 Call central clarification processing and define the following payment allocation in Administrator mode: Analyze item 1 of the payment lot and check the extent to which the selections proposed by the system agree with the information listed in the note to payee.
If the information agrees, post the clarification. Which document number is assigned for the payment allocation?
________________________________
1-2-2 The information in item 2 is not sufficient for clarification. Therefore, activate repayment for this item.
Which repayment request number is assigned?
________________________________
Display the repayment request.
1-3 Cash Desk
1-3-1 Enter the incoming payment using the cash desk. Once you have called the cash journal, allocate yourself to the cash desk with the branch office WDF (BOS) and the cash desk ##.
Use the following information:
Information for the posting documents:
Value date: Today’s date
Clearing account: 113100
Currency: EUR (USD)
Company code: U100 (U300)
Information for the payment:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-44
Selection category: Business partner
Field value / selection cat.: PICA0710## (PI0701C0##) ## = group number
Amount: 180,00
Select the radio button: Incoming cash payment
Choose the “Post item in dialog” variant and display the payment proposal from the system. Post the payment and write down the document number. ________________________________
Generate a receipt. Switch to the print preview to display the receipt.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-45
Incoming Payments / Clarification Processing - Solutions
Unit: Incoming Payments Topic: Entering Payments
1 Incoming payments
1-1 Payment lot.
1-1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Payment Lot → Create.
Reconciliation key: ZS-## (## = Group number)
Status: Postings made.
List Type: All items
1-2 Central clarification processing
1-2-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Clarification Activities → Payment Assignment.
Enter CA240-0## (ZIUT240-00##) as the payment lot. Start the search with Program → Execute as administrator or use the corresponding Adminstrator Mode icon.
Select the required item and choose the Clarification button. On the Clarification tab page, the selection proposals contain one item that was created from the payment data and another item that was created from the note to payee. Select the line in the selection proposals that is relevant for assigning the payment and then post the payment. After you have posted the payment, return to the clarification item.
The document number of the clarification document is in the Payment data tab page under the Posting Details group box.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 8-46
1-2-2 Use the information from exercise 1-2-1. Select the required item and choose the Clarification tab page. Select the Repayment flag and post the clarification.
The document number of the clarification document and the repayment request are saved in the Payment data tab page under the Posting Details group box.
To display the repayment document number, choose:
Utilities Industry → Payments → Clarification Activities → Overview of Repayment Requests.
Select company code U100 (U300) and start the evaluation with the status “Not yet paid ”.
1-3 Cash desk
1-3-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal Assign yourself to the branch office WDF (BOS) and the cash desk ##. Go to the cash desk. Enter the following information:
Value date: Today’s date
Clearing account: 113100
Currency: EUR (USD)
Company code: U100 (U300)
Selection category: Business partner
Field value / selection cat.: PICA0710## (PI0701C0##) ## = Group number
Amount: 180.00
Choose Post Item Online, check the clearing proposal and post the payment. Confirm the receipt printout. You can display your receipt using System → Own Spool Requests.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-1
SAP AG 2003
Contents:
Terminology and examples
Customizing
Clearing Control
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-2
SAP AG 2003
This unit will provide you with an overview of:
Automatic determination of the use of the payment amount of the incoming payment
Automatic assignment of two items to each other for the purpose of clearing entry in account maintenance
Clearing Control: Overview
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Map your company's automatic assignment and clearing strategy in the system
Clearing Control: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-4
SAP AG 2003
Clearing Control: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-5
SAP AG 2003
Example from the Utilities Industry:
One of your business partners pays his/her annual consumption bill, this includes billing for the electricity, gas and water divisions. Since this is a partial payment, the open items of the water division must be cleared first. The remaining amount must then be cleared proportionately against the open items of the remaining divisions.
Clearing Control: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-6
SAP AG 2003
Clearing Control: Terminology and examples
Terminology and Examples
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-7
SAP AG 2003
Clearing Control: Orientation
Every open item, that is every open receivable or payable, must be cleared at some point. There are different procedures that enable you to clear an item. The most frequent are:
Externally initiated payment: The customer clears their receivable by paying
Clearing: Receivables and credit for a contract account or business partner are cleared against each other in account maintenance
Since these clearing processes are normally mass processes, the system must be able to automatically determine the payment usage or automatically create the clearing proposal based on predefined rules.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-8
SAP AG 2003
Clearing Control: Definition
FI-CA clearing control is a tool for configuring a company's clearing strategy.
It contains rules for an automatic clearing proposal or automatic payment assignment
By splitting up the clearing algorithm into several work steps and combining a few basic rules, clearing control allows you to configure clearing scenarios flexibly and based on tables.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-9
SAP AG 2003
Selection
Clearing Control: Overview 1
Clearing entry
Incoming payment
1-n clearing steps
Clearing categoryContractaccount
Clearing type
Open items
DFKKOP DFKKOP
Business transaction
05
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-10
SAP AG 2003
Payment600.-
Clearing type
Grouping
Example 1 - Payment
Contract account
Contract account
Clearing category
Clearing exact amounts
Due date clearing
500.- 01/01/2003600.- 02/01/20031000.- 03/01/2003- 600.- 03/14/2003
500.- 01/01/2003600.- 02/01/20031000.- 03/01/2003
One of your business partners makes a payment to his/her contract account without specifying the payment use in more detail.
Payment must be assigned automatically according to a strategy set up in the system. The system checks the due date of an item or an item group. It also has to check whether the paid amount corresponds exactly to a receivable. Only then can the payment be assigned.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-11
SAP AG 2003
Example 2 - Account Maintenance
Clearing type Clearing category
Grouping Clearing exact amounts
Contract account
Due date clearing
Contract account300.- 01/01/2003 01200.- 01/01/2003 01600.- 02/01/2003 011000.- 03/01/2003 03- 300.- 03/14/2003 01
500.- 01/01/2003 01600.- 02/01/2003 011000.- 03/01/2003 03- 300.- 03/14/2003 01
A contract account contains open receivables and credit that were posted with reference to a certain division. In account maintenance, the system has to clear items for the same division against each other, taking into consideration the due date. The item amounting to 500.00 with the due date 01/01/03 and division 01 qualifies as the item with the highest that has to be cleared against the credit of 300.00 and division 01. In order to do this, the item is split into a sub item of 300.00, which is cleared by the credit, and a sub item of 200.00, which remains open.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-12
SAP AG 2003
Business transaction
Determination of Clearing Variants
Clearing variant05 ⇒ PY119 ⇒ PY1
04 ⇒ AM104 + SAM ⇒ AM2
Clearing typePayment lot 05Cash desk 19Automatic clearing 04
Contractaccount
0815
Optional
Clearing variants are determined depending on the clearing type of the underlying processes and, optionally, on the clearing category of the contract account.
Clearing categoryPrivate STDC&I SONCollector SAM
Clearing rules are defined depending on the clearing type. They can also be made dependent on the clearing category (optional).
The clearing type represents the business transaction. For example, payment lot (05), cash desk (19), manual account maintenance (03) With the exception of a few examples, it corresponds to the source used in the underlying process (HERKF_KK)
The clearing category represents the reference to the contract account. It is stored in the contract account. In this way, different customer groups can have their own clearing categories. For example, private, commercial and industrial, collectors The user can freely assign the category
Clearing variants can be assigned in Customizing under Define Defaults for Incoming Payments, Account Maintenance, Invoicing..... (structured according to areas of implementation).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-13
SAP AG 2003
Inc_Pymt
Clearing Control: Clearing Types
Overview of clearing types used in the standard processes (FI-CA)
4Payment run06
X1Credit Card Lot55
X3Distribute Payment to Collective Bill20S
X3Distribute Payment to Installment Plan20R
X1Payment Order Lot45X1Electronic Bill Presentment and Payment47
X1Cash Desk: Postal Order22
X1Cash Desk: Payment by Check21
X1Payment lot05
X1Cash desk: Payment19X1Cash Desk: Payment by Card20
X1Check Lot25
3
2
2
1
Use
XManual posting01
Automatic account maintenance04
XDistribute Payment to Summarization 30G
Manual account maintenance03
DescriptionClearType
(Table TFK110, level 4.71)
(*)
(*) used in the configuration of enhanced grouping (event 0600)
Use = Implementation area
1. incoming payment
2 Account maintenance
3 Distribute clearing amount amongst dependent items
4 Payment run
Inc_Pymt: Assignment of available amount, for example,payment
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-14
SAP AG 2003
Clearing open items
Selection Restrictions
Clearing type R41Clearing category Main trans. Subtrans. GraceNo clearing
STDSTDSTD
1400500020 0010
21
No clearing
In the selection criteria, you can specify for every clearing type which item is to be included in the clearing analysis based on transaction and due date. You can use the clearing category, main and subtransactions to specify whether an item is to be included and, if so, within which due date interval.
You can determine the selection criteria at the following levels: 1. Clearing category, main transaction, subtransaction 2. Clearing category, main transaction, not specified 3. Clearing category, not specified, not specified 4. Not specified
The restrictions are interpreted in up to 4 steps, starting with the specified clearing category, main transaction and subtransaction and finishing with an unspecified entry. Normally, the level found first is used. If the system cannot determine any selection restrictions for an open, it is included 'unfiltered' in the clearing analysis.
Examples from the IS-U Utilities Industry: During the account maintenance of periodic invoicing, a cash security deposit payment should not be included in the clearing. The clearing category / type and the corresponding transaction 0020/0010 for the cash security deposit payment ensure that open items with this transaction are not included. The first new budget billing amount (0050) has to be included in the annual consumption billing. To do this, a number of days between the system date and the future due date of an item must be defined so that the due dates that have not yet been reached can still be included in clearing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-15
SAP AG 2003
U100 RU100 R
U200 G
U200 G05/15/
Characteristic 1Such as company code
Characteristic 2Such as
Statistics indicator
Characteristic n:Such as due date
Characteristic attributeSuch as U200
Characteristic attributeSuch as R (inst. plan)
Characteristic attributeSuch as G (charges)
Characteristic attributeSuch as 05/02
Characteristic attributeSuch as 05/15
Ranking and Grouping of Characteristics
U100U100
U100 R05/01/
...
U200...U200...
U200...
U200 _U200 _
U100 R05/15/
Characteristic attributeSuch as U100
Characteristics normally describe a certain attribute of an item (for example,an item is a payment on account or due), or a certain event (for example, a payment is made by entering a document number).
Characteristics can be created: With a reference to the original item attribute (fields in document structure FKKOP) - business partner, contract, division, main transaction, subtransaction, due date, document number, statistic indicator,... Or with value derivation from a function module (sample FKK_SAMPLE_TFK116) using information on the open item - transaction, item is due, item is assigned to a contract account.....
Characteristics: Group open items Open items that have identical grouping characteristic values in a clearing step are regarded as a unit (for example, all items that belong to the same company code)
Specify (filter) which items are processed in a clearing step (for example, only due items, or only company code U100)
Specifies (switch) the condition required if a clearing step is to be executed (for example, only execute the step if the payment was made by entering a document number)
Sorts open items Sorting determines the sequence in which the groups are processed and the sequence of clearings within the group.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-16
SAP AG 2003
Credit or incoming payment
Clearing:
Credit/payment receivable
Currency
Absolute limits
Percentage limit
Amount check group
Receivable
Group for joint clearing
Amount Check Groups
From/to amount
Amount check groups are used in a clearing step to define amount-dependent clearing conditions. The check groups are used within a group of open items in the following way:
In the case of incoming payments, the difference between the available payment amount and the total balance of open items in a group that have already been posted undergoes an amount check.
For all other business transactions, the difference between the total credit items and the total receivable items undergoes a standard check.
Amount check groups allow you to specify differentiated amount variances within which a clearing is permitted.
You should be aware that the amount group does not have the same functionality as the tolerance group defined in the contract account. It only has to specify whether a clearing takes place or not. The amount differences from the payment and posting assignment that were determined according to the default values in the amount check group are not implicitly written off. Depending on the specifications in the clearing step, they can be written off, cleared or posted on account.
The amount check group is defined according to currency.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-17
SAP AG 2003
1-n clearing steps
Group processingIncluding:
Sort sequenceAmount-dependent grouping ruleSplitting algorithm for partial clearingCustomer-specific assignment rules
Form OI groups(from specifications for grouping string)
Nex
t gro
up
Clearing Variant
Follow-up processing specificationsTolerance handling for partial clearingSpecifications for the next clearing stepSpecifications for ending the clearing process
A clearing variant contains several steps. The individual steps control the selection, grouping, sorting, and amount-dependent assignment of the open items for clearing. The steps are executed in the sorting sequence of their numbers, you can, however, call them up directly according to each clearing rule. The individual clearing steps inherit the clearing proposal and the remaining open amount from the previous steps. Items that are completely cleared in a clearing step are not included in subsequent steps.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-18
SAP AG 2003
Clearing Step
Grouping stringCharacteristic
Sorting string characteristic
Group rule
1.
2.
3.
4.5.
1.
2.
3.
4.5.
Amount rule
Clearing rule Write off tolerance
Customer module Clear. Var.
/
End of clearing step
/Paymt. rem var.
End of Assignment
Ranking SortGrouping rule
Up to 5 grouping characteristics can be defined in the grouping string. The characteristics are connected with a logical AND.
You can also define a rule for different grouping for each grouping characteristic. Depending on each rule, you can define an alternative value for the individual values of a grouping characteristic. Example: In order to control two attributes of a characteristic in a group (company code U100 = company code U200), you can exclude individual characteristic values, and in doing so, items, from clearing (in the current clearing step,or generally), or clearing processing can be limited to certain characteristic values (such as only company code U100).
The sorting string controls the processing sequence of individual open item groups, as well as the sequence in which the open items are cleared within these groups.
From a technical point of view, the groups are sorted according to the smallest value in their sorting string. Example: When items are grouped according to company code and sorted according to due date, the company that contains the item with the oldest due date is sorted at the front of the sequence.
For most characteristics, sorting them according to their values does not lead to the desired results. If, for example, you want to clear charges first (STAKZ = G), sorting the items according the statistical indicators does not normally achieve this. In order to get the result you want, you can define a ranking order rule in the sorting string definition for each characteristic. Depending on the rule, you can, for example, specify whether a certain characteristic value is sorted at the start or the end of the item table.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-19
SAP AG 2003
Clearing Control: Customizing
Terminology and Examples
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-20
SAP AG 2003
Clearing Control: Group Rules
Examples:
Partial clearing not permitted
Clearing only with identical amounts
Clearing only with 5% difference
Clearing if within tolerance limits
The amount rules specify the conditions under which an amount can be assigned to an item group (defined by grouping string)
Examples:Assignment based on sort sequence During partial clearing, proportional distribution of amount availableAssignment using customer moduleAssignment using alternative clearing variant/step
Clearing rules specify how items in a group are cleared (presuming the amount rule for this group has been fulfilled)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-21
SAP AG 2003
Clearing Control: Special Features
When installment plan items/collective bills are cleared, the clearing amount for the installment plan/collective bill is distributed amongst each source item. For the installment plan, the amount is distributed using the clearing control for the clearing type 20R, and for the collective bill, 20S.
The workflow for amount assignment can be described as follows:1. Clearing amounts are assigned to the open items of the installment plan, for
example, manually or in the payment lot using 05.
2. For the installment plan, the clearing amounts are distributed again between source items. This is done using the clearing control for clearing type 20R.
3. Extreme example: If the source items of the installment plan are a collective bill, the clearing amount for this collective bill is distributed further amongst the individual items of the collective bill. This is done with clearing control 20S.
When installment plans or a collective bill is cleared in a payment lot/account maintenance, the system processes clearing control for two (in extreme cases, three) different clearing types.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-22
SAP AG 2003
Clearing Control: How Can I Test It?
The clearing proposal for account maintenance can be requested in manual account maintenance (FP06) if you activate the Create Proposal field in the initial screen.The clearing proposal for the payment assignment can be requested in the cash desk or during the clarification processing of a payment lot.In manual clearing processing, you can request that a clearing amount assigned to a collective bill / installment plan item / summarization item is a distributed amongst the dependent items. You can do this by selecting the appropriate icon at item level.
You can request clearing proposals online in manual clearing processing. This means that the clearing variant defined the process in question is processed.You can check the determined clearing proposal online. A clearing document cannot be posted unless it is explicitly and manually confirmed.This enables you to efficiently and simply test a clearing variant.
In the collective bill item
In the installment plan item
In the summarization item
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-23
SAP AG 2003
An agent can initiate a payment on account (for example, in clarification processing or the cash desk)
If the clearing variant can propose clearing for part of the amount, the remaining amount is paid on account
If the system cannot determine a clearing proposal for any part of the amount, for example, if an open item was not selected, the amount is either posted on account or to a clarification account, depending on the specifications for the clearing type. The clarification control can depend on the clearing category and the amount.
A posting on account is not created when you request a clearing proposal online for manual clearing (post) processing.
Clearing Control: Creating Payments on Account
If an automatic clearing proposal cannot be determined for a payment or a partial amount, or if you do not want one to be created, clearing control can create a payment on account for this amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-24
SAP AG 2003
Down payment requests or charges, for example, can be written off.
Control can be dependent on statistical indicators, transactions and amounts.The following scenarios (amongst others) are supported:
Write-off if no real receivables(*) existWrite off by the due date of the next actual open receivable(*)
(*) The decision is based on the OIs selected for clearing processing and not on the total account situation.
In the program enhancements for the clearing control, users can use their own rules to control the write-off decision.
Clearing Control: Writing Off Statistical Items
If you want to waive certain statistical receivables or payables, such as unpaid dunning charges, you can write these off in payment processing or account maintenance. In this, the items are marked as cleared but do not initiate anysubsequent processing (for example, down payments, actual requests for charges).
Due to technical reasons, you can only write-off statistical items that are not already preselected for (partial) clearing within in the procedure of a clearing proposal.!
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-25
SAP AG 2003
Clearing Control: Clearing Strategies
Special features for payment assignment:The payment assignment strategy results from the assumption that every payment entered is connected to a certain note to payee known to the payer.The payer's note to payee can differ in terms of detail.
The aim of the strategy is to determine the note to payee of the payment (item to be cleared) as precisely as possible. To this end, the open items can be grouped into 'logical' units (bill, whole item currently due etc.) in clearing control. These units reflect the payer's view of the account.
The payment goes to the item group or combination of item groups that corresponds exactly, or within predefined limits, to the payment amount.
Normally, for payment assignment a clearing variant is used that attempts to assign the exact amount in the first clearing steps, and then uses broader limits for each subsequent step. This enables the user to flexibly influence the clarification worklist for incoming payments.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-26
SAP AG 2003
Clearing Control: Clearing Strategies
Special features for account maintenance:In contrast to payment assignment, clearing processing in account maintenance is only done within a contract account's previously entered open items.
In account maintenance, it is, therefore, not normally a good idea to assign items according to exact amounts. Here, strategy concepts such as clearing sequence and clearing within certain groups (such as company code- or division-based) with permitted partial clearance play a more important role.
In account maintenance, the following strategy normally applies:From the detailed to the general view. This means, the clearing variant starts with a detailed grouping in the first step, which becomesincreasingly general with every subsequent step.
A clearing variant designed for payment assignment is not suitable for account maintenance.!
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-27
SAP AG 2003
Clearing Control: Clearing Strategies
Special features during the distribution of dependent items:The aim of this assignment algorithm is to distribute a (partial) clearing initiated for a collective bill, installment plan or summarization group among the dependent items (subordinate items, source receivables from the installment plan, summarization group items).
The installed algorithm must be able to distribute all of the clearing amount without there being anything left over. The corresponding clearing variant should allow the items to be partially cleared (at least in the last clearing step). The clearing variant cannot use any rules for the automatic write-off of tolerance differences.
An assignment of an exact amount is only a good idea when a collective bill is cleared (the collector only pays certain bills from a collective document). If the system cannot assign an exact amount, the variant must permit partial clearing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-28
SAP AG 2003
Clearing Control: Customizing
IMG Contract Accounts Receivable and PayableBasic Functions
Open item management
Define Amount Check Group
Clearing Control
Define Grouping and Sorting Features
Define Specifications for Clearing Types
Clearing Variants
Define Clearing TypesDefine Clearing Categories
Define Defaults for Account MaintenanceDefine Defaults for Incoming Payments
Define Defaults for Coll. Bill/Inst. Plan/ Summ. Group
Define Specifications for Invoicing
Define Clearing Variants
With the exception of the clearing category table, the clearing control settings are industry-specific. Since the clearing types are allocate to the standard processes and supplied by SAP, every application area is responsible for maintaining and supplying their standard settings.
In the specifications for clearing types, you can configure the determination of clearing variants, selection restrictions, information on payments on account, as well as the control for writing off statistical items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-29
SAP AG 2003
You use clearing control to model your company's automatic assignment and clearing strategy (at several levels if necessary).
Clearing control uses clearing variants to map your clearing strategy, so that incoming payments can be assigned to open items.
Clearing control is used in account maintenance and the additional account maintenance function in IS-U invoicing to clear open items against credit and payments on account.
Clearing Control: Summary (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-30
SAP AG 2003
Clearing variants are determined using contract account information and the accounting transaction (such as payment at cash desk or automatic clearing).
The selected items are grouped and sorted for clearing using characteristics.
Clearing Control: Summary (2)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-31
Clearing Control - Exercises
Unit: Clearing Control Topic: Clearing Credit and Receivables
At the conclusion of these exercises, you will be able to:
• Configure and use a clearing variant.
Clearing control maps your company’s automated allocation and clearing strategy.
Cross company code postings often have to be made. First of all, incoming payments have to clear other receivables that were posted in your own company code. Receivables with the company code that is only used for clearing should have a lower ranking priority.
1 Clearing control
1-1 Configure a clearing variant G## (## = group number), ‘clearing group ##’ that covers the clearing strategy described above.
1-1-1 Group the items together based on main transaction and company code. Select sorting based on main transaction and company code, but make sure that the company code U100 (U300) has a higher priority than company code U110 (U400) and that the main transaction for other receivables (6000,1st place) and for consumption billing (0100, 2nd place) are dealt with before all others. In addition to this, the items must be put in a sequence according to their due dates.
1-1-2 Create the new clearing category G## (clearing group ##). Assign the clearing variant G## to the new category for the clearing type ‘Cash Desk: Payment’ (19).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-32
1-1-3 Assign clearing category G## to contract account PICA0930## (PI0903C0##).
1-1-4 Use the cash desk (transaction FPCJ) to test whether your clearing variant determines the correct clearing proposal for contract account PICA0930## (PI0903C0##).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-33
Clearing Control - Solutions
Unit: Clearing Control Topic: Clearing Credit and Receivables
1 Clearing control
1-1-1 In the IMG, select: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Open Item Management → Clearing Control → Clearing Variants → Define Clearing Variants.
Choose New Entries and enter the key G## and the name Clearing group ##. Once you have chosen Enter, you can select the entry and choose the Clearing Steps level in the dialog structure. Choosect New Entries. This takes you to the maintenance screen for the clearing step.
Enter the step number 10 and enter the following in the grouping string:
1. 004 Main transaction
2. 001 Company code
Enter the following in the sorting string:
1. 001 Company code Rank: 1 (order corresponds to rank order, otherwise: Character val.)
2. 004 Main transaction Rank: 1 (order corresponds to rank order, otherwise: Character val.)
3. 0010 Due date
Choose Enter. You can now use the Alternative Sorting button (to the right of the rank number) to make the following entries for the two characteristics:
1. Company code
Characteristic value: U100 (U300)
Ranking: 1
Characteristic value: U110 (U400)
Ranking: 2
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 9-34
2. Main transaction
Characteristic value: 6000 Ranking: 1
Characteristic value: 0100 Ranking: 2
Save each of your sorting steps and the clearing variant.
1-1-2 In the IMG, select: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Open Item Management → Clearing Control → Define Clearing Categories.
Select New Entries and enter the clearing category G## and the name Clearing group ##.
Select: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Open Item Management → Clearing Control → Define Specifications for Clearing Types → Define Defaults for Incoming Payments.
Select the line with clearing type 19 (Cash Desk: Payment) and activate (double click) the Alternative Clearing Variant level in the dialog structure. Define a new entry and assign the clearing variant G## to the clearing category G##.
1-1-3 In the application menu, select Utilities Industry → Business Master Data → Contract Account → Change. In the General Data tab page, change the clearing category to G## Clearing group ##.
1-1-4 In the application menu, select Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal and then choose To Cash Desk.
Enter contract account PICA0930## (PI0903C0##) and an amount. Now choose Post Item Online. The items allocated using your clearing variant are activated. Do not save until your clearing variant is correct.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-1
SAP AG 2003
Contents:
Functions of the dunning procedure
Dunning history
Submission for collection
Customizing
Dunning and Collections
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-2
SAP AG 2003
The procedure and functions
The definition of dunning activities
The dunning history
Customizing of dunning in FI-CA
Submission of receivables for collection
Dunning and Collections: Overview
This unit will provide you with an overview of the following in FI-CA:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Perform a dunning and collection run
Establish the basic Customizing settings
Define the following terms:Dunning charge category
Charges Schedule
Dunning grouping criteria
Dunning procedure
Collection submission
Dunning and Collections: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-4
SAP AG 2003
Dunning and Collections: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-5
SAP AG 2003
A customer fails to meet his payment obligations.After the first friendly payment reminder, another dunning notice is generated in the second dunning level and the receivables due for dunning are transferred to an external collection agency.
Dunning and Collections: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-6
SAP AG 2003
Dunning and Collection: Dunning Procedure Functions
Dunning Procedure Functions
Collection Processing
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-7
SAP AG 2003
Dunning: Dunning Proposal and Dunning Activities
Post interest
and charges
Charges schedulePrint forms
Generate dunning activities
Generatedunningproposal
Amount limitsDays in arrears
Dunning frequency
Deter-mine
dunning groups and the
new dunning
levels
Businesspartner
Contract account
Openitems
Dunninghistory
A dunning run is made up of two sub-processes: The dunning proposal and dunning activities run. A dunning proposal consists of the items from a dunning proposal run that have been grouped together for dunning. Every dunning notice refers to a dunning procedure. You can specify the selection of items to be dunned using the parameters from the dunning proposal run. A successfully completed dunning proposal run is, therefore, prerequisite for dunning activities.
The dunning activity run is the second sub-process and is executed after a dunning proposal has been created. The dunning run activity determines and executes the dunning activities defined in the dunning procedure and the dunning level. A dunning activity run refers to one dunning proposal run. If all the dunning activities for a dunning notice are executed successfully, the dunning activity run enters the print date in the dunning proposal. The dunning proposal then becomes dunning history.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-8
SAP AG 2003
Contract account 2
Dunning proposal business partner 1
01/01/2003 100 USD
02/01/2003 100 USD
03/01/2003 100 USD
04/01/2003 100 USD
01/01/03 CA1 100 USD
01/15/03 CA2 127 USD
02/01/03 CA1 100 USD
Dunning run02/03/03
Dunning Proposal
Contract account 1
01/15/03 127 USD
01/15/03 232 USD
Businesspartner 1
The dunning notice contains all of a business partner's due, open items that are not subject to direct debit by the bank or that are not blocked from dunning.
Receivables for which an installment plan has been created are not dunned. In this case, dunning is carried out after the respective due dates of the installments have been reached.
Payments on account and open credit memos are taken into account during dunning and are included in the dunning notice.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-9
SAP AG 2003
Dunning procedureDunning Grouping
Dunninghistory
New dunning levels
Due date Deferral date
Amount
Last dunning dateLast dunning level
Determination of Dunning Levels
Contractaccount
Open items
The dunning level indicates how often this item has already been included in a dunning run. The highest dunning level reached by any one of the items recorded on one dunning notice determines the dunning activities to be carried out during the dunning run.
The dunning level of an item can also be decreased by the dunning program if, on the basis of the amount limits, the item would no longer reach this dunning level (for example, after a partial payment).
If the item is included in the dunning history at the time of clearing, a program can be called that executes other dunning activities. This could be, for example, canceling a service disconnection in the case of an incoming payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-10
SAP AG 2003
Business partner
Dunning procedure
Dunning group
Standard criteria
Division 1 Division 2
Dunning activity anddunning notice
Dunning activity anddunning notice
Dunning Grouping
Resp. company code
Currency
Alternative dunning recipient
Grouping key:Additional criteria
If it is possible, all items of a business partner are grouped together on one dunning notice. However, there are criteria which dictate separate dunning notices for certain items. These items are then grouped together into dunning groups on the basis of these criteria.
The items are used for checking dunning relevance (i.e., amount limits and days in arrears) per dunning group.
The grouping key enables you to use other desired criteria such as business area and division in addition to the standard criteria (dunning procedure, currency, main company code).
You must enter the grouping key in the contract accounts for which the grouping is to be valid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-11
SAP AG 2003
Dunning procedure
Dunning: Configuration (1)
Factory calendar
Alt. installment dunning procedure
Behavior with last dunning level
Dunning levels from other procedures
Do not reduce dunning level
Behavior with credit
Alt. returns dunning procedure
Dunning frequency and days in arrears are interpreted as working days in the factory calendar. You can enter an alternative dunning procedure that can be used to dun installment receivables. You can use an alternative, shortened dunning procedure for returns. You can use a parameter in the dunning procedure to specify how the dunning program reacts if a business partner's open receivables already reached the highest dunning level in a previous dunning run.
You also have to control how the dunning run reacts if the dunning procedure changes and whether the dunning levels of the other procedure are included, or whether the current dunning procedure starts again with the first dunning level.
If the system lowers the dunning level (for example, due to partial payment and if the amount limits are not exceeded), you can override this so that the item retains its original dunning level.
If contract account contains receivables due for dunning and open credit, you can use the dunning procedure to decide if dunning notice should not be created, or whether the credit should be included in the dunning balance or ignored.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-12
SAP AG 2003
Dunning: Configuration (2)
Dunning levels perdunning procedure
Amount limits perdunning level
Dunning interval
Update key
Charges
Days in arrears
Interest key
Dunning frequency
Creditworthiness
Set dunning level
Payment deadline
Alt. days in arrears / dunning frequency
Only items dunned in previous level
Optional dunning level
Days in arrears: A minimum of n days in arrears must be reached. The dunning frequency is also reached when at least n days have passed since the last dunning notice.
Always dun: When the dunning frequency has been reached - even if account situation has not changed Charges: Key that defines the schedule for determining charges. The update key lets you know if the calculated interest is relevant for the general ledger, or whether it has to be statistically posted.
Specifying the dunning level controls whether the dunning level can be allocated by an external program (for example, IS-U Invoicing).
Only items dunned in previous step: Only items that were in the dunning group for the last dunning level are included in the dunning group. This ensures that no further items are included in a dunning procedure after a legal action dunning level.
If a dunning level is flagged as optional, the system skips this level if the days in arrears have reached a higher dunning level. The system go any further than the next dunning level that is not flagged as optional. It does not skip mandatory levels. This procedure makes sense, for example, if a dunning run is delayed due to a system breakdown, but you do not want the dunning procedure to be extended unnecessarily because of this delay.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-13
SAP AG 2003
Dunning charges Dunning charges schedule
Charge category
Currency key
Dunning amount limit
Dunning charge
Percentage rate
Transaction
Document types for dunning charges
Dunning: Configuration (3)
Dunning charges schedule Charges schedule that can be allocated to the dunning levels. Every charges schedule can manage the charges data for a maximum of three charges categories. Charge scales relating to currency and creditworthiness can be created for every combination of charges schedule and charges category. These scales can be used to determine charges. You must specify how the system posts the individual charge scales (for example, statistically or for the general ledger).
Dunning amount limit The dunning amount as of which the charge is calculated.
Dunning charge The charge levied.
Percentage rate Percentage of the dunning amount is estimated as a charge; this is at least the fixed amount for the dunning charge
Transaction The transaction (main and sub) that is stored, specifies whether the dunning charges are posted statistically or as an actual receivable.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-14
SAP AG 2003
Doc. type: G1MnTr: 0010SbTr: 0010
Doc. type: G2MnTr: 0010SbTr: 0020
Doc. type: SPMnTr: 0010SbTr: 0025
Charges schedule 01
Doc. type: Z1MnTr IMTr SbTr ISTr
Amount Amount Amount
Interest doc.
Dunning: Document Type and Transaction Determination
Charges cat. 01 Charges cat. 02 Charges cat. 03 Def. valuesDoc. type
The transaction used to post the charges document for the different types of charges is predefined in Customizing for the remaining program flow.
The interest document, however, is posted either statistically or as relevant for the general ledger. The system uses the allocation of transactions to internal transactions (V_TFKIVVN) to determine which transaction the interest items receives.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-15
SAP AG 2003
Dunning Program: Parameters
Date identifierIdentification
General Restrictions
Business partner
Contract account
Contract
Company code
Free selections
Technicalsettings
Dunning parameters
Logs
Number of jobs Problem classIssue date
Payments included
Net due date
Dunning procedure
Reconciliation key
Start activity run
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-16
SAP AG 2003
Dunning run
Dunning Activities
ResetInstallment plan
Print dunning notice(container)
or
Start aworkflow
Generate telephone list
Set dunning block
Print dunning notice(directly)
Request cashsecurity deposit
Disc. document
DunningchargesDunning interest
Release to collection agency
Log
All activities that were carried out are recorded in an application log. Application forms from the print workbench form the basis of the dunning notice. Printout can be controlled immediately in the spool, or in correspondence management of the print container.
In the dunning procedure (for installments), you can specify an activity that deactivates the installment plan. After the installment plan has been deactivated, the source receivables are dunned again.
A disconnection document can be created automatically in IS-U. A meter disconnection procedure is started for the business partner and monitored using this disconnection document.
A workflow can be used, for example, to trigger a clerk notification. In the dunning procedure, you can release a receivable for submission to an external collection agency. In the dunning run, you can automatically set a dunning lock for the dunned contract account. You can use the example function module FKK_SAMPLE_0350_LOCK_VKONT to do this. The module writes a dunning lock reason in the master data. This function module is used for defining a dunning activity that can be stored in the dunning procedure. Function module FKK_SAMPLE_0395_UNLOCK_VKONT enables you to delete the lock (at event 0395) set by the dunning program when the dunning notice is reversed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-17
SAP AG 2003
Dunning: Telephone Lists
CRM ornon SAP call center system
Process telephone listFPDUTL
Telephone list
Dunning run with activity:Telephone list
Telephone dunning: Function module FKK_SAMPLE_0350_TEL_ITEM allows you to implement a new dunning activity in which the dunned business partner is included in a telephone list. A clerk then calls this business partner and works through the list. A list like this that has been generated by the dunning activity run can be forwarded to an external system (for example, a call center in mySAP CRM) automatically at event 1799, using function module FKK_TRANSFER_CALL_LIST_1799, or manually using report RFKKMADUTLTRANF. The call center then processes the list.
The events 9010, 9012 and 9013 have to be defined in order to forward the entries. SAP provides function module FKK_CALLLIST_CRM_9010 as an example.
Alternatively, the new transaction Telephone List can be used if a telephone list is being processed by several agents. You can find this transaction in the menu under Periodic Processing -> For Contract Accounts -> Dunning Notice. In this transaction, an agent can flag an item as completed after a successful telephone call with the business partner. In order to record communication with the business partner, the clerk can create customer contacts manually or automatically. In the Customizing settings for customer contacts, you must define the contact configuration for the program context SAPLFKKDUTL.
To be able to provide the business partner with information, the agent can branch from the detailed information in the telephone list to, amongst others, the account balance, objects connected to the dunning notice and a customer- or industry-specific function that can be implemented at event 9011.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-18
SAP AG 2003
Dunning History
Every dunning-relevant item has an entry in the
dunning history
Header item for eachdunning notice sent01/15/2003 800 USD
01/01/2003 800 USD01/15/2003 1200 USD01/30/2003 1500 USD
4711 08/01/02 DL 4 200 USD
4712 08/15/02 DL 4 150 USD
4713 09/01/02 DL 3 250 USD
...
4729 01/16/03 DL 1 120 USD
Information about the items dunned and the dunning activities carried out is stored per dunning notice in the dunning history.
A dunning notice can be reversed if it has been wrongly issued for a business partner. The charges generated as a result of this dunning notice are reversed as well. You can also reverse a complete run.
From within the dunning history, you can specify which dunning level will be assigned to the dunned items during the next dunning run.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-19
SAP AG 2003
Dunning notices
Print container
Printoutcreation
Creation of Printout with Print Container
Installment planletter
Bank statement
Returnsletter
...
The correspondence component permits you to create paper records using the individual requests collected in the print container (for example account statements) and mass requests (for example bill printout, dunning notices, returns letters to the business partner).
The concept for printing correspondence has been defined in such a way that print orders are now stored centrally and processed. Previously, the printing of forms had to be initiated separately in the spool for each individual business transaction. You can limit the selection to individual business partners and correspondence categories, as well as execute test and repeat prints.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-20
SAP AG 2003
Dunning and Collections: Collection Processing
Dunning Procedure Functions
Collection Processing
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-21
SAP AG 2003
Mass run: Release(FP03M)
Dunning activity (event 0350)
(FKK_COLL_AGENCY_RELEASE_0350)
Mass run: Write-off(FP04M)
Write-off(FP04)
Manual release(FP03E)
DFKKCOLL
FP03
FP03D / FP03DM(submission)
Status: Released
Collection - Release Receivables for Collection
DMESub-mission
file
Collection agency
XYItem 1 BP 1
Item 2 BP 2
Item 3 BP 3
Item 4 BP 4
...
Total:205,488 USD
If a receivable is submitted to an external collection agency, this means that a customer has not paid a receivable and that the company is not able to collect it.
Receivables submission is made up of two steps: 1. The entry of data in the database table DFKKCOLL. All submitted receivables and receivables to be
submitted (release for submission) are managed. 2. Selection of the receivables to be submitted from the database table DFKKCOLL and the physical
submission of the receivables using report RFKKCOL2, which creates a file for each collection agency (submission to collection agency).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-22
SAP AG 2003
Collection - Automatic Release: Parameters
Date identifierIdentificationGeneral SelectionsBusiness partner
Contract account
Company code
Document number
Simulation run
Technicalsettings
AdditionalSelections
Logs
Number of jobs Problem classNet due date
Dunning level
Amount
Currency
dunning procedure
Dunning level category
Executionvariant
Item selection:With statistical With write-off
If you specify an execution variant, you can determine further company-specific accruals/deferrals. You can store these accruals/deferrals in user exit 5015.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-23
SAP AG 2003
Collection - Automatic Submission Parameters
Date identifierIdentification
General Selections
Business partner
Contract account
Company code
Simulation run
Technicalsettings
AdditionalSelections
Logs
Number of jobs Problem classContract
Document number
Net due date
Amount
Collection agency
Submission reason
Submission status
Also statistical
Also written-off
Submit additional items
To collection agency
Write file
Payment form ID
Total receivables to be submitted
Submission parameters
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-24
SAP AG 2003
SubmissionRFKKCOL2
Collection Agency Payment - Incoming Payment
58.000014711
116.000014712
58.000024711
AmntINKPSDoc.Payment form 2346Payment form 2345
Payment form 2347Doc.No. Item Amnt4711 1 58.004711 2 58.004712 1 116.00
Submission file
Payment reference
Collection agency file
Payment lotRFKKCOPM
BETRWOPBEL
BETRWVKONT
BETRWGPART
BETRWVKONTGPART
BETRWINKPSOPBEL
BETRWNRZAS
Selection category for payment lot
Doc. 471158.00
Clear, write off...
Collection agency XY
When you submit an item, you can create a payment form that simplifies the assignment of payments to open items. If the file from the collection agency contains collected payments, these can be allocated to the appropriate open items using the payment form number confirmed by the collection agency
If the collection file contains interest and charges, the system posts these as interest and credit receivables and they are passed on to the customer.
Receivables that have not been collected and are, therefore, irrecoverable can be automatically written off if you activate the Write-off Item Directly indicator in the write-off parameters of RFKKCOPM.
Collection charges to be paid to the collection agency can be determined using a defined function module in event 5068 and posted as payables to the collection agency's contract account. To do this, you must activate Post Collection Charges indicator in the specifications of RFKKCOPM.
If the collection agency provides the information personally or in writing, the payments, interest and charges receivables must be posted manually. You can use transaction FPAVI (Payment advice note from collection agency) to enter a payment advice note.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-25
SAP AG 2003
Collection: Information for Collection Agency
Partner switch
Clearing
Callback
Reversal
Clearing reversal
Returns
Collection agency XY
DMEInfor-mation
file
Information for
collection agencies
FPCI
X
X
X
X
X
The collection agency has to be informed when items are called back and must receive information on items that have already been submitted. In Customizing, you can specify which information is included in the file for the collection agency.
The Information for Collection Agency (FPCI) mass run enables you to create files for the collection agency that contain the following information:
The master data of one or more business partners has changed. The business partner has directly paid part or all of the outstanding amount. The program writes items with the following submission status in the file: 10 (receivable paid directly by customer) 11 (receivable partially paid by customer)
Items that the collection agency cannot recover within a certain period have to be called back. When this happens the program includes items that have the submission status 09 (call back receivable) in the file.
The direct customer payment for a previously submitted item was reversed, clearing reset or a return made.
In the case of a reversal, returns or the (partial) reset of a clearing, the items in question receive the status 02 (receivable submitted) again. You can inform the collection agency of the re-submission of items using the information file - as long as the collection agency was already informed of the customer's direct payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-26
SAP AG 2003
Dunning and Collections: Customizing
Dunning Procedure Functions
Collection Processing
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-27
SAP AG 2003
Dunning: Customizing
IMG Contract Accounts Receivable and Payable
Business Transactions
Dunning notices
Define Document Types for Dunning Charge Categories
Define Charge Categories for Dunning
Configure Charge Schedules for Dunning Procedure
Configure Dunning Activities
Define Specifications for Interest on Arrears
Configure Dunning Procedure
Define Dunning Grouping Categories
Define Dunning Lock ReasonsDefine Time-Dependent Creditworthiness Ratings
Interaction with Other Business TransactionsSpecifications for Automatically Deactivating Installment Plans
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-28
SAP AG 2003
IMG Contract Accounts Receivable and Payable
Collection: Customizing
Business Transactions
Submission of Receivables to Collection Agencies
Define Submission Status
Define Collection Agencies
Define Specs for Submission to External Collection Agencies
Define Reasons for Receivables Callback
Define Specifications for Collection Agency Charges
Define Default Value for Callback Reasons
Specifications for Forwarding Information to Collection Agencies
Define submission status: In addition to the statuses delivered by SAP for items released and submitted to collection agencies, you can also define your own, company-specific submission statuses. You can use the number range 20 to 99 for this. Numbers 01 to 19 are standard settings and cannot be changed. In contrast to the standard settings, the additional submission statuses do not have a functional character.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-29
SAP AG 2003
Dunning is used to request payment of overdue receivables.
There are two steps in dunning: The dunning proposal and dunning activity run.
Different dunning activities can be carried out.
Items can be submitted to external collection agencies.
Dunning and Collections: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-30
Dunning / Collections - Exercises
Unit: Dunning Topic: Create Dunning Notices /
Submit Receivables to Collection Agencies
At the conclusion of these exercises, you will be able to:
Create and implement a dunning run with the predefined dunning levels and activities such as dunning notice printout in the correspondence container, posting charges and releasing receivables to be dunned for collection agencies.
Configure a two-step dunning procedure with certain preset parameters. A customer fails to meet his payment obligations. Use the dunning procedure that you have configured for the customer’s contract account.
1 Dunning
1-1 Configuring a dunning procedure.
1-1-1 Create a dunning procedure that contains two dunning levels with the following parameters and activities:
Dunning procedure Use a key that has not yet been assigned (e.g. Z9, X8…), name: Dunning group ##.
Factory calendar Use the factory calendar 01 (German standard) or US (USA). This enables you to set the payment target and calculate the days in arrears according to working days.
Dunning levels:
Dunning level 01 Payment reminder group ##
Days in arrears 7 days
Dunning frequency 7 days
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-31
Payment deadline 5 days
Charges schedule 01 Charges schedule 01
Creditworthiness number
5
Amount limits:
Currency EUR (USD)
Amount limit 5
Dunning activities:
Amount limit 0
Currency EUR (USD)
Creditworthiness 0
Number 1
Activity R004
Dunning levels:
Dunning level 02, ‘Dunning and collection group ##’
Days in arrears 14 days
Dunning frequency 7 days
Payment deadline 5 days
Charges schedule 01 Charges schedule 01
Creditworthiness number
15
Determine interest Yes
Interest key 01
Update key 1
Amount limits:
Currency EUR (USD)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-32
Amount limit 10
Dunning activities:
Amount limit 0
Currency EUR (USD)
Creditworthiness 0
Number 1
Activity 0006
Dunning activities:
Amount limit 0
Currency EUR (USD)
Creditworthiness 0
Number 2
Activity R004
1-2 Using the new dunning procedure
1-2-1 Allocate your new dunning procedure to contract account PICA0910## (PI0901C0##) and lock the incoming payment method for this contract account.
Execute the dunning run for May 2nd 2004 and for business partner PICA0910## (PI0901C0##). Use dunning run MAH99 (DUN99) from May 2nd 2003 as a template for your dunning run.
Use the following information:
Date identifier: 02.05.2004 Identifier: MAH## (DUN##)
Enter the following parameters:
Date of issue: 02.05.2004 Company code: U100 (U300)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-33
Business partner: PICA0910## (PI0901C0##) Start active run: Yes
Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner. Save your entries and start the dunning run with the dunning activities immediately.
Check the additional logs and the dunning history, and make sure the dunning run was executed correctly. Use the account balance display to check if the dunning charges were posted correctly.
Use the correspondence print to create a dunning notice for your business partner.
1-2-2 Execute a second dunning run for this business partner. To do this, copy your dunning run MAH## (DUN##) from May 2nd 2003 (unit 1-2-1) to June 2nd 2004.
Use the following information:
Date identifier: 02.06.2004 Identifier: MAX## (DUX##)
Enter the following parameters:
Date of issue: 02.06.2004 Company code: U100 (U300) Business partner: PICA0910## (PI0901C0##) Start active run: Yes
Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner.
Save your entries and start the dunning run with the dunning activities immediately.
Check that the dunned items were released for collection.
2 Submission to collection agency
2-1 Submit the receivables from business partner PICA0910## (PI0901C0##) to the collection agency GELDHER (COLLECT_IT).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-34
Display the status information of the submission.
Which changes are made at document level when the item is submitted to the external collection agency? Analyze the document changes.
Dunning / Collections - Solutions
Unit: Dunning and Collections Topic: Create Dunning Notices /
Submit Receivables to Collection Agencies
1 Dunning
1-1 Configuring a dunning procedure.
1-1-1 In the IMG, choose: Financial Accounting → Contract Accounts Receivable and Payable → Business Transactions → Dunning Notices → Configure Dunning Procedure.
Choose New Entries. Use a free key (e.g. Z9, X8…) and enter the name Dunning procedure group ##.
Activate a factory calendar and define the calendar 01 (German standard) (US, factory calendar USA).
In the dialog structure, double click on Dunning Levels and choose New Entries. Enter the first dunning level 01 for your dunning procedure using the parameters provided. Do the same in the dialog structure to define the amount limits and activities for the first dunning level.
Repeat these steps for the second dunning level and save your entries.
1-2 Using the new dunning procedure
1-2-1 In the application menu, choose: Utilities Industry → Business Master Data → Contract Account → Change.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-35
On the Payment/Taxes tab page, define payment lock A for the incoming payment method and select your new dunning procedure on the Dunning/Correspondence tab page.
Once you have saved the changes to the contract account, select: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → For Contract Accounts → Dunning Notice → Dunning Proposal Run.
Use the F4 help to select the parameter record MAH99 (DUN99) from May 2nd 2003. Choose Enter and copy the run parameter. Add the information described in the exercise, save, and start the run immediately with the dunning activities.
The application log on the Logs tab page, contains information messages that show the progress of dunning processing. You can also use the dunning history to do this. To get to and analyze the dunning history, choose Environment → Dunning History.
Choose path: Utilities → Contract Accounts Receivable and Payable → Account → Account Balance, to display the dunning charges with a suitable list type that also selects statistical items
Select the path: Utilities Industry → Contract Accounts Receivable and Payable → For Contract Accounts → Correspondence → Print, and copy the parameter record MAH99 (DUN99) from May 2nd, 2003. Add the business partner number. Save and start the correspondence run immediately. Once the run has finished, you can display the dunning notice by selecting System → Own Spool Requests.
1-2-2 Copy your dunning run from exercise 1-2-1. Change the date to June 2nd 2004 and start the dunning run immediately.
After the run has finished, you can check whether the items have been released for collection by selecting Utilities Industry → Contract Accounts Receivable and Payable → Account → Submit for Collection → Process Collection Items.
2 Submission to collection agency
2-1 In the transaction Utilities Industry → Contract Accounts Receivable and Payable → Account → Submit for Collection → Process Collection Items, select the items to be submitted and choose the Submit button. In the following selection screen, enter the collection agency ‘GELDHER’ (‘COLLECT-IT’) in the Submit to Collection Agency field. Choose Submit Receivables, not ‘Simulation’, and start the submission with Execute, F8. Once the submission has been logged in a list, use F3 to return to the collection item processing list. Update the display if necessary (submission status changes to 02) and branch to the detail display of the document by double clicking on
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 10-36
the document number. Another double click takes you to the detail screen for the business partner item. The collection agency is recorded as alternative partner for payments (Pay. Data tab page). Payment and dunning lock reasons have also been set (depending on the Customizing settings).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-1
SAP AG 2003
Contents:
Interest calculation terminology
Interest calculation functions
Interest calculation display
Customizing
Interest Calculation
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-2
SAP AG 2003
This unit will provide you with an overview of:
Interest terms
The display of interest calculation in the interest supplement
Functions for calculating interest for items, and integration with other functional areas
and Customizing
Interest Calculation: Overview
of interest in sub-ledger accounting for contract accounts receivable and payable.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Describe the interest calculation process
Use the functions of interest calculation
Understand the integration of the interest calculation function with other functions
Interest Calculation: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-4
SAP AG 2003
Interest Calculation: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-5
SAP AG 2003
A business partner pays his/her bill late.
You calculate interest on the amount of the bill for the period from the due date to the date when payment is received.
You perform interest calculation.
This results in a statistical posting of an interest document and creation of a letter for the business partner.
Interest Calculation: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-6
SAP AG 2003
Interest Calculation: Terminology
Interest Calculation Terminology
Interest Calculation Functions
Interest Calculation Display
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-7
SAP AG 2003
Interest notification
Business Transactions for Posting Interest
Customer info.Interest simulation
Item
sel
ectio
n
Post interest doc.
Mass interest run
Cash sec. dep. interest
Create installm. plan
Dunning run
IS-U Invoicing
Advance paymt bonus
Calculate and post interest
Credit interest(relevant for General Ledger )
Debit interestGeneral Ledgerrelevant or statistical?
Debit interest: Interest on open debit items is calculated for the period from the due date until the interest calculation date (this is usually the current date).
Cleared debit items: Interest on debit items that were cleared late is calculated for the period from the due date until the clearing date, provided the clearing falls before the interest calculation date.
Do not calculate interest: If an item is not cleared by a payment, then usually no interest calculation takes place (for example, interest must not be calculated for items having the clearing reason "Reverse").
Credit interest: Credit interest for calculating interest for credit always has to be posted as relevant for the general ledger. Interest is not calculated for allocated incoming payments.
Interest simulation: Interest can be calculated for information , but it is not posted.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-8
SAP AG 2003
()% Σ exp.
Transaction
Determinationof interest key
Interest key
Interest Calculation Rule
Functionsfor
calculatingand
posting
interest
Referenceinterest rates
Interest Parameters
Select items for interest calculation
Contract accountDunning level items
The interest key contains all control parameters for calculating interest, for example, the parameters for selecting items and the reference to the calculation rule.
Priority of interest key determination An interest key entered in the item has the highest priority. You can enter the interest key manually, or it can be determined from the transactions and entered in the item by the system at the time of posting.
If interest is calculated for an item in the dunning procedure, an interest key can be stored in the dunning level.
The interest key can also be entered in the contract account. If an interest key cannot be determined, interest calculation is not possible. The valid interest rates are found using the interest calculation rule. Additional conditions can also be stored in the interest calculation rule.
The interest rates depend on: The reference interest rates (optional) The analysis period
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-9
SAP AG 2003
Transfer daysTake into account the duration of the payment process
Base date for interest calculation = due date + transfer days
Tolerance daysNumber of days which must have passed since the due date before interest can be calculated.If a debit item is paid within the tolerance days, no interest can be calculated.
Interest period or interest calculation frequencyThe interest period establishes a period in which a maximum of one interest calculation can be carried out.
In this way, the business partner is ensured of a period in which interest cannot be calculated more than once.
Interest Key
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-10
SAP AG 2003
% Σ exp()Interest calculation method (calendar)
Interest category (scaled interest, scaled interest category)
Interest interval
Monthly interest calculation
Settings forRounding interest calculation
Scaled interest refers to the total amount
Interest calculation with interest calculation numerators
Interest rates are stored for each currency and debit/credit indicator
Interest rates can be based on a reference interest rate
Interest Calculation Rule
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-11
SAP AG 2003
Amount limit check
Functionsfor
calculatingand
posting
interest
Amount Limit Check
Amount limits
Itemsthat can
be posted
Items thatcannot be
posted according
to the checkInterest Items(after
summarization)
Interest is posted only if it exceeds the amount limit. The amount limit is dependent on the company code, the debit/credit indicator, and the currency. It is possible to adjust the amount limit check in event 2040.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-12
SAP AG 2003
Interest Calculation: Functions
Interest Calculation Terminology
Customizing
Interest Calculation Display
Interest Calculation Functions
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-13
SAP AG 2003
Enter Selection parameters
(BP, contract acct)
Posting parametersItem selection criteria(e.g. debit/credit item)
Item selection screen
Select items
LetterPrint
Lineitems
Post interest
Display interestDisplay variantSort/totalSave list...
Interest Calculation: Individual Processing
In individual interest calculation, you can select individual items for interest calculation. Those items for which interest can be calculated are highlighted on the screen.
Debit and credit interest can be posted, but no multiple-currency postings can be created. An interest letter can be created. Items locked for interest calculation:
- Items without an interest key - Items not yet due (based on the transfer days, tolerance days, or interest period) - Items for which interest has already been calculated - Items with an interest blocking reason
An interest lock reason can be entered in an item manually or automatically. It is transferred automatically if a lock reason is stored in the transaction. You can manually enter an interest lock in the item during posting or when a document is changed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-14
SAP AG 2003
Automatic Interest Run: Parameters
Date identifierIdentification
General RestrictionsBusinesspartner
Contract acct
Company code
Interest Key
Currency
Simulation run
Technicalsettings
FreeSelections
Logs
Number of jobs
Problem classIssue date
Posting date
Doc. type
Statistical key
Reconciliation key
Posting parameters
Interest parametersDebit items
Credit items
Debit and credit items
Open items
Cleared Items
All items
Calculate interest to
Create corresp.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-15
SAP AG 2003
Additional Functions
Interest calculation
Interest on cashsecurity depositsClearingrestrictions
Debit int. calc. -CHECK: Credit itemsavailable?
Printinterest notificationretrospectively
Massinterest calculationCash security deposits
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-16
SAP AG 2003
EnterSelection parametersPosting parametersInstallment plan parameters (default values)
Select open items Change installmentamounts and due datesAdd installmentsDelete installmentsChange installment
plan parameters
Interest calculationDetermine interest amount, Create interest document, and include in installment plan
Interest Calculation: Installment Plan
Print letter
Interest can be determined when an installment plan is created, and can then be integrated into the installment plan.
Interest is calculated over the duration of the installment plan. That is, interest on the installment plan is determined for a period in the future. Interest is calculated on the expected incoming payments, i.e. from the start date through the due date of the installments.
Interest is calculated completely for an installment plan using an interest key.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-17
SAP AG 2003
Interest calculation for cash security depositsOwn transaction / own mass run
Integrated into IS-U Invoicing
Implemented as credit interest calculation, but restricted to cash security deposits
IS-U Invoicing (only debit interest on open items)No interest letter; interest is printed on the bill
Interest for cash security deposits is posted in invoicing (In the case of the final bill, interest is calculated up to the move-out date, and the repayment/settlement of the cash security deposit payment and the cash security deposit interest is triggered.)
Dunning run (only debit interest on open items)No interest letter from the dunning run; interest is included on the dunning notice
Integration In Other Functions
Interest calculation is integrated in the cash security interest calculation, invoicing and dunning functions.
When you configure the dunning procedure in the IMG, you can assign one interest key to each of the dunning levels.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-18
SAP AG 2003
Interest Calculation: Display
Interest Calculation Terminology
Interest Calculation Functions
Interest Calculation Display
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-19
SAP AG 2003
Document Display: Display Item
Item 2
Document no.: 4711
Due date specificationsNet due date 05/01/1998Cash discount due date 04/15/1998
Document Edit Goto Settings Extras Environment System Help
Deferral to 05/20/1998
Display interest schedule for item 0002 of document 4711
Source doc. number Currency Amount of itemFrom date To date Int. rate Int. amount4712 USD 200.0001/01/2001 05/01/2001 4.000000 2.69
4713 USD 400.0001/25/2001 05/03/2001 3.000000 3.30
Interest Supplement
Interest SupplementInterest History
Items charged interest and
changes in interest
Display theinterest supplement
from the items display screen
Information used in the interest calculation is saved for each item in the interest supplement. The interest supplement is generated when an interest document is posted.
This information includes: Interest rates Periods Source items Interest amount
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-20
SAP AG 2003
Interest Calculation: Customizing
Interest Calculation Terminology
Interest Calculation Functions
Interest Calculation Display
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-21
SAP AG 2003
Interest Calculation: Customizing
IMG Contract Accounts Receivable and Payable
Business Transactions
Interest Calculation
Define Percentage Rates for Reference Interest RatesDefine Reference Interest Rates
Define Interest Calculation Rules
Maintain Amount Limits for Debit/Credit Interest
Define Interest Key
Define Interest Lock Reasons
Define Specifications for Interest CalculationActivate Additional Functions for Interest Calculation
Define Clearing Reasons for Which Interest is not CalculatedDefine Specifications for the Mass Run
Item Interest Calculation
Reference interest rates are used in different application components. Therefore, reference interest rates may already be maintained here. Date-dependent interest values can be defined for the reference interest rates in the 'Define Percentage Rates for Reference Interest Rates' process step. Reference interest rates can be used in every client.
Interest calculation rules are used in different application components. Therefore, interest calculation rules may already be maintained here. Interest calculation rules are allocated to interest keys in the 'Define Interest Keys' process step.
You must enter the interest calculation rule in the interest key. You can also allocate other parameters to the interest key.
In the additional functions for interest calculation, you can determine whether the following takes place when interest is calculated for line items: Interest calculation based on net amounts Interest calculation for source items when installment plan items are cleared
In the Customizing settings for transactions, you must set the interest transactions, the allocation to internal transactions, assignment of the statistical transactions, and account determination.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-22
SAP AG 2003
Interest calculation can be carried out for individual items.
The interest key and interest calculation rule are the most important parameters in interest calculation.
Interest calculation can be integrated into other business processes.
Interest Calculation: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-23
Interest Calculation - Exercises
Unit: Interest Calculation Topic: Interest Calculation for Documents
At the conclusion of these exercises, you will be able to:
Calculate debit and credit interest for open and delayed cleared items. The interest is posted online and in a mass run.
One of your business partners has not paid his bill. You want to calculate interest for this overdue item.
1 Interest calculation
1-1 Calculation of interest for debit items.
Calculate the interest for the overdue items of business partner PICA1010## (PI1001C0##). Use the following information:
Document date: Today’s date Posting date: Today’s date Business partner: PICA1010## (PI1001C0##) Currency: EUR (USD) Debit item: X All items: X Calculate interest to: Today’s date
Once you have selected the Line items function, the system displays as message stating that the account contains credit items. Confirm the message with Enter. Select the overdue items, use the Display interest function to display the calculated interest, and post the interest.
Write down the document number: ______________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-24
1-2 Mass calculation of interest
1-2-1 First of all, post another receivable to the amount of USD 800 for business partner PICA1010## (PI1001C0##). Use the following information: Document date: 1st April 2004 Posting date: 1st December 2004 Currency: EUR (USD) Company code: U100 (U300)
Enter the additional data with the New business partner item function : Business partner: PICA1010## (PI1001C0##) Net due date: 1st February 2004 Contract account: PICA1010## (PI1001C0##) Transaction: 6000 / 0020 Amount: 800.00.
Start the mass calculation of interest. Use the interest run from June 1st, 2003 with identification ZIN99 (INT99) as a copy template for your payment run with today’s date as the date identifier and ID ZI0## (## = Group number)
Change the following parameters: Issue date: Today’s date Posting date: Today’s date Interest calculation by: Today’s date Create correspondence: X
Choose log class Additional information in the log settings. Save your entries and schedule the interest calculation run to run immediately.
Check the interest calculated in the account display.
1-3 Creating correspondence
1-3-1 Create the cover letter for interest calculation for your business partner. Use the following information:
Date identifier: Today’s date Identifier: K10## ## = Group number Business partner: PICA1010## (PI1001C0##) Type of correspondence: 0007 Print parameters: Output device LT0Q
Choose log class Additional information in the log settings.
Save your entries and schedule the correspondence to be created immediately. Display the log.
1-3-2 Display the cover letter that was created by the correspondence.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-25
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-26
Interest Calculation - Solutions
Unit: Interest Calculation Topic: Interest Calculation for Documents
1 Interest Calculation
1-1 Interest calculation for debit items
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Interest → Post
Enter the required information and select the debit items.
Use function → Line items to display the input screen for selecting the line items.
Select the overdue items, use the Display interest function to display the calculated interest, and choose List → Post Interest to post the interest.
1-2 Mass calculation of interest
1-2-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post
Mass calculation of interest:
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → For Contract Accounts → Interest Run
Use F4 input help to choose interest run ZIN99 (INT99) from June 1st 2003 and choose Program run → Copy to copy it.
Enter the group number of your business partner in the General Selections.
In the Interest parameters tab page, activate the correspondence.
Choose problem class Additional information in the Logs tab page.
Save your entries and schedule the interest calculation run to run immediately.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 11-27
1-3 Correspondence
1-3-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → For Contract Accounts → Correspondence → Print
Enter the data in the tab pages as follows:
General selections Business partner: PICA1010## (PI1001C0##) Correspondence selection: Correspondence type: 0007 Print parameters Output device: LT0Q Logs Log class: Additional information Save your entries and schedule the correspondence generation to run immediately.
Choose tab page Logs → Application log. Double-click on the information column to display the additional information.
1-3-2 Choose: System → Own spool requests.
Select the most recent entry and choose the Display Contents button (F6).
Spool request → Display
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-1
SAP AG 2003
Contents:
Deferral
Installment Plan
Customizing
Deferral/Installment Plan
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-2
SAP AG 2003
The deferral of open items
Installment plan agreements
Deferral/Installment Plan: Overview
This unit will provide you with an overview of the following in FI-CA subledger accounting:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Defer open items
Create an installment plan
Deactivate an installment plan
Deferral/Installment Plan: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-4
SAP AG 2003
Deferral/Installment Plan: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-5
SAP AG 2003
A customer cannot make his/her payments according to the standard payment procedure. The customer has open items and requests a payment deferral.
You offer to set up an installment plan for the customer.
An open receivable for a small amount is deferred.
An installment plan is arranged for an open receivable for a larger amount; payments are distributed over different due dates in the future.
Deferral/Installment Plan: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-6
SAP AG 2003
Deferral/Installment Plan: Deferral
Deferral
Installment Plan
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-7
SAP AG 2003
DeferralAmount due: 1400
Old due date05/01/2003
TimeNew due date06/20/2003
Document - postDocument - change
Returns activityDeferral days
Deferral
1400.00
Manual
Automatic
The deferral does not change the original due date. Deferral can be performed manually in the document change transaction or automatically during returns processing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-8
SAP AG 2003
Deferral/Installment Plan: Installment Plan
Deferral
Installment Plan
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-9
SAP AG 2003
Inst. plan - CreateInst. plan - Change
Dunning activityDeactivation
Installment planAmount due: 1000
New due datesOld due date Time
250.00 250.00 250.00 250.00
Interest Calculation
Installment plan
LetterInstallment plan
Inst. plan parameters
(e.g. repayment
plan)
Installment plancharges
Installment Plan
Manual
Automatic
Interest calculation: - Interest can be determined when an installment plan is being created, and can then be integrated
into the installment plan. - Interest is calculated completely using an interest key. - Interest is calculated for the duration of the installment plan. - You can calculate interest for overdue installments, as well as an interest credit memos for
installments paid before the due date. Installment plan charges:
- As an alternative in installment plan interest, you can also use installment plan charges. Deactivation: You can deactivate an installment plan using the transaction "Change installment plan”. The deactivation can also be executed as an activity in the dunning procedure.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-10
SAP AG 2003
Interval category
Inst. interval
Inst. amount or number of installments
Rounding amount
01/10 Inst. 1 10002/10 100.............................10012/10/ 100
Installment plan
Charges amount
Account balancesOpen: 500 USDDue: 480 USDCredit: 0 USD
Rem.Amount1 First inst.2 Last inst.3 New inst.
Memos
StatusOpenDeactivatedBalancedOverdue interest
Inst. plan category
Installment Plan Parameters
1
3
4
5
2
6
7
The installment plan parameters can be predefined if you define a repayment plan in Customizing. You can create an installment plan or define a repayment plan in Customizing with either a fixed installment amount or with the parameters for the number of payments, payment interval / interval type and rounding amount.
A charge can be levied when an installment plan is created. This charge can also be set in Customizing. Status administration takes place in the installment plan.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-11
SAP AG 2003
EnterSelection parametersPosting parametersInstallment plan parameters (default values)Installment plan charges
Select open items Change installment amounts and due datesAdd installmentsDelete installmentsChange installment plan parameters
Print letter Interest Calculation
Charges
Create Installment Plan: Workflow
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-12
SAP AG 2003
OPBEL WHGRPOPUPK BETRW
4711 1 Sample1 (repaym.) 10.00
OPBEL WHGRP FAEDN
4711
4711
4711
1
2
12
1
1. Due date
2. Due date
12. Due date
01/01/
02/01/
12/01/1
1
Repetition items
1 Sample record
e.g. 12 Installments
Installment Plan: Document Structure
Business partner items
OPUPW
A reference business partner item is created. Key:
- OPBEL: Number of the document in contract accounts receivable and payable (FI-CA) - OPUPK: Item number in the FI-CA document - WHGRP: Repetition group - BETRW: Amount in transaction currency with +/- sign - OPUPW: Repetition item in the FI-CA document - FAEDN: Net due date
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-13
SAP AG 2003
4711 12 12. Due date 12/01/1
OPBEL WHGRPOPUPK BETRW ABWTP ABWBL
4710
4711
1
1 1
Source receivable
Sample1 (repaym.)
120.00
10.00
4711
OPBEL WHGRPOPUPW FAEDN
4711
4711
1
2 1
1. Due date
2. Due date
01/01/
02/01/
1
Repetition items
Business partner items
R
Example
There is a source receivable to the amount of USD 120.00. This has the document number 4710. An installment plan with the installment plan number 4711 is created. An open item is created as reference item and a repetition item is created for each due date.
Source receivable 4710 is linked to installment plan 4711 via the installment plan number entered in the "Installment plan" field.
Key: - OPBEL: Number of the document in contract accounts receivable and payable (FI-CA) - OPUPK: Item number in the FI-CA document - WHGRP: Repetition group - BETRW: Amount in transaction currency with +/- sign - OPUPW: Repetition item in the FI-CA document - ABWBL: Number of the substitute FI-CA document (in the document: installment plan number) - ABWTP: Category of the substitute document from FI-CA - FAEDN: Net due date - AUGBL: Number of the clearing document from contract accounts receivable and payable
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-14
SAP AG 2003
Post item Due item
Time
1st Inst.
2nd Inst.
3rd Inst.
4th Inst.
5th Inst.
Start date of installment plan
Installment plan
Due date of 1st installmentDue date of 2nd installment
...
Customer calls and requests payment in installmentsInstallment is createdItem is replaced by installment plan
Interest on items in arrearsInterest on interval of installment plan
500 USD
10 USD
10 USD
10 USD
10 USD
10 USD
Source items
Installment Plan: Interest Calculation
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-15
SAP AG 2003
Deferral/Installment Plan: Customizing
Deferral
Installment Plan
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-16
SAP AG 2003
Installment Plan: Customizing
IMG Contract Accounts Receivable and Payable
Business Transactions
Deferral and Installment Plan
Categories for Installment Plan
Define Default Values for Installment Plan
Define Installment Plan Category
Define Default Values for Installment Plan Charges
Define Interest Key
Define Default Values for Interest on the Installment Plan
Deactivation Reasons for Installment Plan
In the Customizing settings for transactions, you must set the installment plan transactions, the allocation to internal transactions, assignment of the statistical transactions for installment plan charges, and account determination.
The Installment Plan Used indicator and the Documents with Repetitions Are Possible indicator must be set in the posting settings (Contract Accounts Receivable and Payable -> Postings and Documents -> Basic Settings -> Maintain Central Settings for Posting).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-17
SAP AG 2003
You can defer open items manually or automatically in returns processing.
The installment plan distributes open receivables over several installments in the future.
Interest can be calculated as part of the installment plan.
You can deactivate an installment plan.
You can deactivate an installment plan manually or automatically through a dunning activity.
Deferral/Installment Plan: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-18
Deferral / Installment Plan - Exercises
Unit: Deferral / Installment Plan Topic: Deferring Documents, Creating an Installment Plan
At the conclusion of these exercises, you will be able to:
Use the installment plan functionality in FI-CA.
Include interest and charges in installment plans.
One of your business partners calls. He cannot pay his bills at the present time and asks you to defer his payment. You defer one item that has a small amount. For the larger amount, you offer him the opportunity of paying using to an installment plan. The customer accepts.
1 Deferral and Installment Plan
1-1 Manual deferral of an open item.
1-1-1 Defer the oldest open receivable for business partner PICA1110## (PI1101C0##).
Use the following information:
Deferral date: 15th of the following month
Save your entries.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-19
1-2 Creating an installment plan.
1-2-1 Now create an installment plan for the open and due items from this business partner’s consumption bill.
Use the following information:
Business partner: PICA1110## (PI1101C0##) Contract account: PICA1110## (PI1101C0##) Currency: EUR (USD) Posting date Today’s date
Use the function for displaying the account balances and select the required item. Create an installment plan with installment plan category E002 (0002).
Start date: Today’s date
Now use the “Installment plan” function to go to the next screen. Change the installments here (for example, due date and installment amounts). When you change the amounts, make sure the total of the installments corresponds to the source receivable. Do not post the installment plan yet. Use the “Calculate interest” function to calculate the interest for the installment plan. Enter today’s date as the date for starting interest calculation.
Post the installment plan.
Write down the installment plan number: ___________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 12-20
Deferral / Installment Plan - Solutions
Unit: Deferral / Installment Plan Topic: Deferring Documents, Creating an Installment Plan
1 Deferral and Installment Plan
1-1 Manual deferral of an open item.
1-1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance.
Position the cursor on the document that you want to change (defer) and choose Environment → Document → Change. In the business partner item, navigate to the deferral date and implement the deferral.
1-2 Creating an installment plan.
1-2-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Installment Plan → Create.
Select Display account balances and press Enter to go to the item selection. Enter installment plan category E002 (0002) and specify the start date. Then select the items that you want to include in the installment plan and choose the Installment plan function. When you change the amounts, make sure the total of the installments corresponds to the source receivable. Do not post the installment plan yet. Now calculate the interest for the installment plan with the “Calculate interest” function.
Press Save to save the installment plan.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-1
SAP AG 2003
Contents:
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Mark as doubtful / Individual Value Adjustment
Write-Off
Customizing
Other Business Transactions
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-2
SAP AG 2003
The options in account maintenance
The reversal of documents
Clearing reset
Transfer posting of documents
Marking documents as doubtful entries and individual value adjustment
Writing off documents
Other Business Transactions: Overview
This unit will provide you with an overview of the following for subledger accounting in FI-CA:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Describe how account maintenance is used
Describe the options for reversing documents within sub-ledger accounting
Be familiar with the functions for uncollectible receivables
Specify and configure the basic system settings
Other Business Transactions: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-4
SAP AG 2003
Other Business Transactions: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-5
SAP AG 2003
During processing, the agent notices that a business partner has credit as well as receivables in his/her contract account.
Furthermore, a payment has been incorrectly allocated.
The credit is cleared against the receivable.
The payment that was allocated incorrectly is reversed and posted as a payment on account.
Other Business Transactions: Business Scenario (1)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-6
SAP AG 2003
Based on the list of open items and their due dates in the due date grid, you determine that certain items have been open for more than 180 days.
The accounting clerk implements the steps for marking these items as doubtful.
Other Business Transactions: Business Scenario (2)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-7
SAP AG 2003
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Other Business Transactions: Account Maintenance
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-8
SAP AG 2003
Automatic
Open items:
Clearing
05/10/03 150.00 150.00
05/08/03 70.00 50.00
05/22/03 200.00 - 200.00 -
05/19/03 123.00 -
Difference: 0.00
Acct Maintenancegeneral
Cash desk
Invoicing
Incoming lot
Manual
Clearing
Control
Account Maintenance in FI-CA
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-9
SAP AG 2003
Business partner: 1740Contract account:Due: 05/28/05
Open items:Clearing
150.00 150.00
70.00 50.00
200.00 - 200.00 -
Difference: 0.00
Open items
Proposal
Clearingcontrol
Account Maintenance: Process
You can select open items in the initial screen for account maintenance. In the processing screen, you can change or add items to this selection, as well as include other contract accounts or business partners.
Items allocated to the proposal from clearing control are already active. However, you can change the allocation and ignore the proposal.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-10
SAP AG 2003
Automatic Clearing: Parameters
Date identifierIdentification
General Restrictions
Business Partner
Contract acct
Company code
Net due date
Technicalsettings
Postingparameters
Logs
Number of jobs Problem classClearing reason
Doc. type
Posting date
Document date
Reconciliation key
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-11
SAP AG 2003
Other Business Transactions: Reversal of Documents
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-12
SAP AG 2003
Invoicing documents
Installment/budget billingdocuments
Documents for which interest has been calculated
Externalbilling documents
Reversal not
possible
SDdocuments
Reversal of Documents: Restrictions
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-13
SAP AG 2003
Reversal of Documents
Document header
G/L Account Items/Tax Items
Business partner items
CCODE G/L Acc. BA Cost Cent. AmntU300 800000 200.00U300 175000 30.00
BPART CCODE Due Amount4711 U100 02/22/03 230.00Clearing doc: 102345678 AG: 05
CCODE G/L Acc. BA Cost Cent. AmntU100 800000 200.00 -U100 175000 30.00 -
Document no.: 102345678Posting date: 03/05/03Doc. type: S1 Currency: USDReconciliation key: 03022201/SK1Reversal doc. for: 010000234591
Cleared itemsBPART CCODE Division Amount4711 U100 01 230.00 -
Reversal
Document no: 010000234591Posting date: 02/22/03Doc. type: F1 Currency: USDReconciliation key: 03022201/SK1Reversed with: 102345678
Document to be reversed: After reversal, the business partner items have the clearing document number of the reverse document.
Indicator: reverse document: Reference to the reversed document using the document number from the reversed document in the document header.
In the reversal document, an item is created for every G/L. These items have the opposite +/- sign to the G/L item.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-14
SAP AG 2003
Massreversal
Activ
ities
Count documents
Reverse documents
Mass Reversal: Parameters
Display documents
Reconciliation keyDocument No.
Reference documentPosting date
Document dateDoc. type
Selection:
AgentEntry date
Reconciliation keyReversal date
Doc. typeClearing reason
Posting parameters:
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-15
SAP AG 2003
Other Business Transactions: Clearing Reset
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-16
SAP AG 2003
Bill:100.00 USD
Payment:-100.00 USD
Bill outstanding:100.00 USD
Payment on account:-100.00 USD
Clearingreset
Clearing Reset
Allocationand clearing
When you reset the clearing, you reopen the paid item. In addition, a credit item is created automatically. The credit transaction, such as a payment on account, is defined in Customizing.
If you reset clearing that resulted from a payment to a customer, a debit transaction must be defined in Customizing so that the system can create a receivable for the business partner who received the payment.
Instead of the resetting the complete clearing, you can also reset parts of clearing. Clearing reset can be set for every combination of the following data that occurs during clearing:
- Business partner - Contract account - Contract - Company code - Business area - Division - Collective bill number
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-17
SAP AG 2003
Other Business Transactions: Transfer of Documents
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-18
SAP AG 2003
Document Transfer
Business PartnerContract accountContractDocument numberReference document no.
Target of transfer posting
Receivables account, due date, transaction descriptionDunning and interest information are copied
Open Cleared Open
Business partnerContract accountContract
Selection specifications
You can only transfer open receivables or credits. You can transfer the following: Individual items - receivables and credit All items of a business partner All items of a contract account All items of a contract Items that are still contained in an installment plan. Existing installment plans are automatically deactivated and a new installment plan is created for the amount of the source receivable(s) still open.
Items that belong to a collective bill. The collective bill is automatically updated. The transfer posting document can be reversed. When transfer posting a customer account, you can allocate documents that already refer to contracts (account assignment) to a target contract account without having to specify a target contract. In doing so the transfer posting document is not longer assigned to a contract. Contracts should not already be allocated to the target contract account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-19
SAP AG 2003
Other Business Transactions: Mark as Doubtful / Individual Value Adjustment
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-20
SAP AG 2003
Mark as doubtful:38.--
Individual valueadjustment50% net16.38--
FI doc:: #0815
38.--16.38
38.--16.38
FI-CA doc.
FI-CA DocumentsSummary Records FI document
Mark as doubtful / Individual Value Adjustment
FKKZW
Document: 4711Amount 58Open: 38
Mass runtransfer posting
of correctedreceivables
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-21
SAP AG 2003
Mark as Doubtful/Individual Value Adjustment: Posting
FI
FI-CAContract acct
[1] 58.- 20.- [3]
Example:Receivable 58 Tax rate: 16%Partial payment: 20 USD50% value adjustment
Tax account
Bank[2] 20.--
[1] 58.--
[3] 20.-- 20.-- [2]
8.-- [1]50.-- [1]20.-- [3]Receivables
Cash clearing
Revenue
Doubtful receivable DR correctionAdjustment account
Individual value adjustment IVA expense[4] 38.-- 38.-- [4] 16.38 [5] [5] 16.38
Posting records: 1. Issuing a bill 2. Posting incoming payment in general ledger accounting (bank statement) 3. Payment posting in sub-ledger accounting and allocation of the payment 4. Marking the receivable as doubtful 5. Individual value adjustment
Steps 4 and 5 generate FI-CA documents that are only relevant for General Ledger Accounting. This means that they do not have any business partner items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-22
SAP AG 2003
Mass Run for Automatic Doubtful Entries and Individual Value Adjustment: Parameters
Date identifierIdentification
General Restrictions
Business partner
Contract acct
Company code
Simulation
Technicalsettings
Selection Logs
Number of jobs Problem classSelect open/adjusted items
Delimitationdate
Posting date
Reason forMAD/IVA
Value adjustment variant
Value adjustment reversal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-23
SAP AG 2003
Other Business Transactions: Write-Off
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-24
SAP AG 2003
- No creditavailable
...
Special authorization:Check rules not used
Event: 5010Release for collection
Manual Write-Off: Process
Expense account
50
8Tax account
Check level
Check rules ?
optional
BP
Account ...
Doc. ... ...
Contract ... ...
With the appropriate authorization, you can set the indicator that determines that the check rules are not used.
Open items can be written off completely, or, partially if the customer is to be let off part of his or her open items. You can specify the partial amount to be written off in the Write-Off Items transaction. Partial write-offs must be explicitly permitted in Customizing along with a write-off reason. When an item is written off, the written-off document items are cleared and a write-off document is created. The system automatically posts the expense or revenue accounts defined in Customizing. Write-off documents can be reversed. If this is done, receivables or payables are open again. You must define rules for adjusting tax during write-offs. If the posted expense account is tax-relevant, the system also adjusts the posted tax during write-off.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-25
SAP AG 2003
Automatic Write-Off: Parameters
Date identifierIdentification
General Selections
Business partner
Contract account
Company code
Document no.
Reference document no.
Simulation run
Technicalsettings
AdditionalSelections
Logs
Number of jobs Problem class
Extra log
Proration
Amount
dunning level
Dunning procedure
Dunning level category
Net due date
Transaction
Executionvariant
Posting date
Company code
Currency
Clearing reason
Write-off reason
Doc. type
Further details
Posting parameters
You can use an execution variant to implement further company-specific restrictions, for example, the items to be submitted can be selected by division. In order to do this, you must program a function module that restricts items based on the desired criteria. This function module must be defined at event 5015.
Other entries include: - Do not use check rules - Release receivables for submission to collection agencies - Do not update write-off history - Do not update creditworthiness - Final bill must exist
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-26
SAP AG 2003
Write-Off: Posting 1
FI
FI-CAContract acct
[1] 58.-- 20.-- [3]38.-- [4]
Example:Receivable 58 Tax rate: 16%Partial payment: 20 USD50% value adjustmentWrite off receivable
Tax account
Bank[2] 20.--
[1] 58.--
[3] 20.-- 20.-- [2]
8.-- [1]50.-- [1]
Receivables
Cash clearing
Revenue
20.-- [3]38.-- [4]
[4] 5.24
Sales deduction[4] 32.76
Posting records: 1. Issue a bill 2. Post incoming payment in general ledger accounting 3. Post payment in sub-ledger accounting and allocate the payment 4. Write off the open item
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-27
SAP AG 2003
Write-Off: Posting 2
FI
FI-CAContract acct
[1] 58.-- 20.-- [3]38.-- [6]
Doubtful receivable DR correctionIndividual value
adjustment IVA expense[4] 38.-- 38.-- [4] 16.38 [5] [5] 16.38
Example:Receivable: 58 Tax rate: 16%Partial payment: 20 USD50% value adjustmentWrite off receivable
Tax account
Bank[2] 20,--
[1] 58.--
[3] 20.-- 20.-- [2]
8.-- [1]50.-- [1]
Receivables
Cash clearing
Revenue
20.-- [3]38.-- [4]
[6] 5.24
Sales deduction[6] 32.76
38.-- [7] [7] 38.-- [8] 16.38 16.38 [8]
Posting records: 1. Issue a bill 2. Post incoming payment in general ledger accounting (bank statement) 3. Post payment in sub-ledger accounting and allocate the payment 4. Mark the receivable as doubtful 5. Individual value adjustment
Steps 4 and 5 generate FI-CA documents that are only relevant for General Ledger Accounting. This means that they do not have any business partner items. 6. Write off the open item 7. Reset doubtful entry 8. Reset IVA
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-28
SAP AG 2003
WrOffdoc. Doc. ... Amnt WrO STAKZ ReversalDate Srce
8711 4711 300 01 06/13/2003 16
8712 4721 700 04 06/13/2003 17
8717 4751 20 03 06/13/2003 G 16
8722 4766 600 01 06/13/2003 G 16
...
Display variant
Selection options- No reversed items- No statistical items
Write-Off History
X
Write-off history is automatically updated during write-off. It can also be automatically updated during mass write-off depending on authorization. The reversal of a write-off document is also recorded in the write-off history.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-29
SAP AG 2003
Other Business Transactions: Customizing
Mark as Doubtful / Individual Value Adjustment
Write-Off
Customizing
Account Maintenance
Reversal of Documents
Clearing Reset
Document Transfer
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-30
SAP AG 2003
Account Maintenance - Customizing
IMG Contract Accounts Receivable and Payable
Basic Functions
Define Default Values for Automatic Clearing
Open Item Management
Define Default Values for Account Maintenance
Define Grouping Variants
Define Grouping Characteristics
Define Specifications for Automatic Clearing
Business Transactions
Clearing Control
Grouping Variants
Automatic Clearing
The aim of grouping for automatic clearing is to group the open items into logical units. The system can then analyze how each unit can be cleared. A clearing document is posted for every unit that is cleared. The clearing analysis is executed using the clearing algorithm defined for an automatic clearing run in Clearing Control.
Grouping is an enhancement of the clearing control functionality. In contrast to clearing control, maintaining a group is optional and only makes sense if you always want to post the clearing of certain item groups from a business partner / contract account in an individual clearing document.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-31
SAP AG 2003
Reverse / Reset Clearing: Customizing
IMG Contract Accounts Receivable and Payable
Basic Functions
Define Default for Resetting Clearing
Open Item Management
Define Default Values for Resetting Clearing
Define Default Values for ReversalDefine Alternative Accounts for Reversal in Following Year
Business Transactions
Reversal
Define Specifications for Clearing Item
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-32
SAP AG 2003
Transfers - Customizing
IMG Contract Accounts Receivable and Payable
Define Specifications and Default Values for Transfer
Business Transactions
Transfers
Define Transactions for Transferring items
Define Transfer Reasons
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-33
SAP AG 2003
Mark as Doubtful/Individual Value Adjustment: Customizing
IMG Contract Accounts Receivable and Payable
Basic Functions
Particular Aspects of Taxation Procedure
Define Tax Calc. Types Write-Offs and Ind. Val Adj.
Business Transactions
Maintain Account Determination for Doubtful Item EntriesMaintain Exceptions for Adjustments
Maintain Value Adjustment Variants for Automatic AdjustmentsMaintain Account Determination for Ind. Value Adjustment
Maintain Processing Methods for User Exits for Automatic Adjustments
Maintain Default Values for Transfer Posting Run
Maintain Correction Reasons
Maintain Correction Reset Reasons
Doubtful Items and Individual Value Adjustment
Exceptions for Adjustment: In this activity you define, for each application area, the main and subtransactions that create postings that you want to exclude from a doubtful entry or value adjustment. You can define the scope of the exception as follows: Manual doubtful entry or value adjustment Automatic doubtful entry or value adjustment Manual and automatic doubtful entry or value adjustment
User Exits: In this activity you can define methods to be used for making value adjustments for the items. You can enter the method on the initial screen for the Adjust receivables according to age mass activity. You must define the special features for the methods in event 2950. In this event you can implement customer-specific checks as well as value adjustment methods.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-34
SAP AG 2003
Write-Off: Customizing
IMG Contract Accounts Receivable and Payable
Define Tax Calc. Types Write-Offs and Ind. Val Adj.
Basic Functions
Particular Aspects of Taxation Procedure
Define Change in Tax Code with Write-Offs
Tax Adjustment for Write Off
Business Transactions
Automatic G/L Account Determination for Write-OffsDefine Specifications and Defaults for Mass Write-Offs
Define Execution Variants for Mass Write-Offs
Define Write-Off Reasons
Define Specifications and Default Values for Write-Off
Write-Off
You should only enter an execution variant if the event 5015 has been defined.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-35
SAP AG 2003
Account maintenance enables you to clear credits against open receivables.
You can reverse incorrect documents.
You can use the "reset clearing" function to process payments that have been allocated incorrectly.
You can transfer receivables and credits to another business partner.
You can mark uncollectable receivables as doubtful, adjust the individual value and then finally write it off.
Other Business Transactions: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-36
Other Business Transactions - Exercises
Unit: Other Business Transactions Topic: Clearing Credit and Receivables
At the conclusion of these exercises, you will be able to:
Clear credits and receivables within account maintenance.
Write off receivables that cannot be collected.
In addition to receivables, one of your business partners also has credit from a payment on account. You clear the credit against the receivables. The remaining receivables have to be written off later.
1-1 Account Maintenance
Clear the receivable using the payment on account in contract account PICA1210## (PI1201C0##) of the business partner with the same number. Use the following information:
Business partner: PICA1210## (PI1201C0##) Contract account: PICA1210## (PI1201C0##) Company code: U100 (U300) Currency: EUR (USD) Posting date Today’s date
Instruct the system to generate a clearing proposal.
Check the proposal and post the clearing.
Write down the document number: ______________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-37
1-2 Writing off receivables
1-2-1 Once account maintenance has been executed, you determine that another receivable from business partner PICA1210## (PI1201C0##) cannot be collected. Use the following information:
Business partner: PICA1210## (PI1201C0##) Contract account: PICA1210## (PI1201C0##) Posting date: Today’s date Currency: EUR (USD) Clearing reason: 04 Write-off reason: 04 ‚Uncollectable’
Write off the receivable. Write down the document number of the write-off document: _______________________________________________
1-2-2 Check the write-off in the account display and navigate to the write-off history.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 13-38
Other Business Transactions - Solutions
Unit: Other Business Transactions Topic: Clearing Credit and Receivables
1-1 Account Maintenance
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Maintain
Set the “Create proposal” field and choose function Open items.
Check the proposal and post the clearing with function Account → Post.
1-2 Writing off receivables
1-2-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Write Off Items
Maintain the input fields as described in the exercise: ....... Write-off reason: 04 ‚Uncollectable’ .......
Pressing Enter takes you to the selection screen in which you can select the receivables for write off and choose the appropriate icon to write them off. Save your entries to execute the write-off.
1-2-2 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance with a list variant that also displays cleared items.
Use Environment → Account → Write-offs to display information for the write-off history.
Alternatively, you can display this information using the following path:
Utilities Industry → Contract Accounts Receivable and Payable → Account → Further Information → Write-Off History Select your business partner and press Execute to start the analysis.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-1
SAP AG 2003
Contents:
Cash and non-cash security deposits
Customizing
Security Deposits
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-2
SAP AG 2003
This unit will provide you with an overview of:
The request for cash and non-cash security deposits
Non-cash security deposits
The request, payment and settlement of cash security deposits
Security Deposits: Overview
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-3
SAP AG 2003
At the conclusion of this unit, you will be able to:
Enter non-cash security deposits in the system
Request cash security deposits in the system
Post incoming payment to requests for cash security deposits
Explain how a cash security deposit is settled against other receivables
Security Deposits: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-4
SAP AG 2003
Security Deposits: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-5
SAP AG 2003
You assess the credit rating of your business partner such, that you agree on cash security deposits for this business partner.
Security Deposits: Business Scenario
A request for cash security deposit is created for the business partner in the system.
After the incoming payment, the request for cash security deposit is cleared and accounted for as a down payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-6
SAP AG 2003
Security Deposits: Cash and Non-Cash Security Deposits
Cash and non-cash security deposits
Customizing
Cash and non-cash security deposits
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-7
SAP AG 2003
FIFI-CA
Security depositrequest
Security depositpayment
Receivedsecurity deposits
Non-cashsecurity deposit
Guarantee of payment
Security Deposits 1
0000015090012131400 67291500 11
CityBank
To
Der vorg edruckt e Sch eckt ext d arf n icht geän dn.Account No.X X X X
€ - 400,-Four hundred
The system supports the request and handling of cash and non-cash securities of business partners. Non-cash security deposits can be bank guarantees, mortgage bonds, or savings accounts that are stored as security deposits.
Cash security deposits are managed as payables, which can be settled according to certain criteria. Requests for cash security deposits, or changes to cash security deposits, can take place automatically when registering a business partner in IS-U move-in processing, or by using a function module in event 1025 when changing the payment method in the contract account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-8
SAP AG 2003
Receivedsecurity deposits
Request
Security deposit
Security depositpayment
Receivablefrom (final)
bill
Inte
rest
C
alcu
latio
nInterest
payables
FIFI-CA
Cash Security Deposits
Release or IS-U
invoicing
In IS-U, a cash security deposit is cleared with the final bill. Otherwise, cash security deposits can be payed out or cleared as long as the cash security deposit is released. The program RFKK_SECURITY_RELEASE is available for releasing security deposits (menu: Periodic Processing -> For Contract Accounts -> Security Deposits -> Release). Non-cash security deposits can be returned or cashed.
Interest must be calculated for cash security deposits.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-9
SAP AG 2003
Security Deposits: Posting - 1
FI
FI-CAContract account
Receivables
Bank
Sec. deposits received
Tax account
Cash clearing
Revenue account
[1] 50.--
[1] Posting the request for the cash security deposit in FI-CA: The cash security deposit is posted statistically so that no transaction relevant to the general ledger is generated.
A notification containing the requested amount, the terms and methods of payment, etc. for a security deposit can be generated.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-10
SAP AG 2003
Security Deposits: Posting - 2
FI
FI-CAContract account[1] 50.--
Receivables
Bank
Sec. deposits received
Tax account
Cash clearing
Revenue account
[2] 50.-- 50.-- [2]
[2] Posting incoming payment in FI. The business partner pays by bank transfer.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-11
SAP AG 2003
Security Deposits: Posting - 3
FI
FI-CAContract account
Receivables
Bank
Sec. deposits received
Tax account
Cash clearing
Revenue account
([1] 50.--0.--)
50.-- [3]
[2] 50.-- [3] 50.-- 50.-- [2]
50.-- [3]
[3] Allocation of the payment in FI-CA and FI. When payment is allocated to the request for the cash security deposit, credit corresponding to the payment amount is posted. The statistical request is cleared.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-12
SAP AG 2003
Security Deposits: Posting - 4
FI
FI-CAContract account
Receivables
Bank
Sec. deposits received
Tax account
Cash clearing
Revenue account
([1] 50.--0.--)
[4] 116.--
50.-- [3]50.-- [4]
[2] 50.-- [3] 50.-- 50.-- [2]
50.-- [3][4] 50.--
50.-- [4][4] 116.--
100.-- [4]
16.-- [4]
[4] Posting the final bill in FI-CA and FI with settlement of the payable resulting from the payment of the cash security deposit. In this example, the remaining amount after settlement is USD 66.00.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-13
SAP AG 2003
Security Deposits: Customizing
Cash and non-cash security deposits
Customizing
Cash and non-cash security deposits
Customizing
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-14
SAP AG 2003
Security Deposits: Customizing
IMG Contract Accounts Receivable and Payable
Business Transactions
Security deposits
Define General Parameters for Security DepositsDefine Number Ranges for Security Deposits
Create Special Definitions for Security Deposits
Define Status of Non-Cash Security Deposits
Define Request Reasons for Security Deposits
Define Non-Cash Security Deposit Categories
Define Default Values for Cash Security Deposit Interest (dialog) Define Reversal Reasons for Security Deposits
Define Types of Notes for Security Deposits
Maintain Specifications for Transfer of Security DepositsMaintain Specifications for Reversing Transfer of Sec. Dep.
Define Specifications for Cash Security Deposit Interest (Mass Processing)Assign Withholding Tax Code to Main and Sub-Transactions
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-15
SAP AG 2003
In contract accounts receivable and payable, a distinction is made between cash and non-cash security deposits.
You can only enter a cash security deposit if a request for a security deposit has been created.
Payment to a cash security deposit request results in a payable charged to the business partner. This is normally settled against the final bill in IS-U, or after the security deposit has been released.
Security Deposits: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-16
Security Deposits: Exercises
Unit: Security Deposits Subject: Cash Security Deposits
At the conclusion of these exercises, you will be able to:
Create and further process a cash security deposit.
One of your business partners has not made the payments that are due. You agree that your partner will submit a security deposit.
When terminating the business relationship with this business partner, you release the security deposit payment and clear it using open receivables.
1 Security deposits
1-1 Creating a cash security deposit.
1-1-1 Create a cash security deposit request. Use the following information:
Contract: PICA1210## (PI1301C0##) Contract account: PICA1310## (PI1301C0##) Type of security deposit: Cash security deposit Reason for request: Payment history Requested amount: 500.00 EUR (USD) Start date: 1st April.2004
Post the request for the cash security deposit.
During this activity, the system creates a security deposit and a security deposit request.
Write down the number of the security deposit: _________________
Write down the document number of the security deposit request:___________________________
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-17
1-1-2 Now pay the cash security deposit request at the cash desk. Use the following information:
Amount: 500.00 EUR (USD) Company code: U100 (U300) Bank clearing account: 113100 Fixed value date: 2nd April.2004 Posting date: 2nd April 2004 Document date: 02.04.2004
Select the variant Post Item Online, deactivate the invoice documents allocated using clearing control, and activate the cash security deposit request. Post the payment.
Write down the document number: ______________________________
Display the account balance and make sure the request for cash security deposit has been updated properly. What is the status of the security deposit? What is the transaction of the down payment? Which clearing restrictions does the security deposit payment have?
1-1-3 Release the security deposit payment. What happens to the security deposit payment? Clear the security deposit payment with open receivables. What is the status of the security deposit now?
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-18
Security Deposits: Solutions
Unit: Security Deposits Subject: Cash Security Deposits
1 Security deposits
1-1 Creating a cash security deposit.
1-1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Security Deposits → Enter.
Under Type of security deposit select the Cash security deposit radio button Confirm with Enter.
Fill in the fields according to the information described and save your entries.
1-1-2 Select Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal and choose To Cash Desk.
Enter the data specified in the task for the payment. Select Post Item Online, deactivate the invoice documents allocated using clearing control, and activate the cash security deposit request. Use the Post function to post the payment.
Display the account balance and make sure that you choose list category All items. The payment clears the cash security deposit request, which is then put under down payments. Position the cursor on the request for cash security deposit and choose Environment → Document → Cash Security Deposits. The security deposit now has status Paid. Go back to the account display and press the hotspot Down payments. Double-click on cash security deposit payment to determine transaction 0020 / 0010. In the Payment Data tab page, you see clearing restriction 2, Security deposit: Clearing not allowed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 14-19
1-1-3 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Security Deposits → Change. Select the Release…button (F6) to release the security deposit for payment or clearing. Confirm the information. In the account balance display, you can see that the security deposit is no longer displayed under Down Payments, but as an open credit item. The clearing restriction was removed. Select Environment → Account → Account Maintenance and clear the payment completely with the open receivables. Position the cursor on the request for cash security deposit and choose Environment → Document → Cash Security Deposits. The security deposit now has status Returned.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-1
SAP AG 2003
Contents:
FI-CA Integration in SAP Applications
Customizing
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-2
SAP AG 2003
At the conclusion of this unit, you will be able to:
Describe the embedding of the contract accounts receivable and payable in the SAP Business Suite applications
Integration: Unit Objectives
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-3
SAP AG 2003
Integration: Overview Diagram
Course Overview
Introduction
Account Balance Display
Transactions and Account Determination
Payment
Documents
Returns Processing
Incoming Payments / Clarification Processing
Clearing Control
Dunning and Collections
Deferral/Installment Plan
Other Business Transactions
Security Deposits
Interest Calculation
Integration
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-4
SAP AG 2003
Your company wishes to carry out reporting and analysis in SAP Business Warehouse.
You also want to make certain Internet Self Services available to your customers.
You find out which standard interfaces exist for FI-CA.
Integration: Business Scenario
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-5
SAP AG 2003
Integration: Overview
Business Information Warehouse
mySAPFinancials
FICOECIMRETM
BillerConsole-
dator
BillerDirect
DisputeMgmnt.
CreditMgmnt.
In-HouseCash
Treasury & Risk Mgmnt
FSCM
FI-GL
CO-PA
TR-CM
COIS-UInvoicing
SDInvoicing
FI-CAFI-CA
Customer RelationshipManagement
Ext.Billing
Systems
You can transfer SD invoices directly to the FI-CA subledger accounting. Under certain conditions it is also possible to post SD invoices as invoicing requests, together with an IS-U invoice.
You can use a standardized IDoc interface to import billing documents from external billing systems into FI-CA, and to process them there.
Postings to FI-CA contract accounts trigger immediate posting in the Cash Management (TR-CM) application component.
Postings from subledger accounting are transferred regularly (for example, daily) to the general ledger. Additional account assignments from cost accounting are included, and forwarded to the specified account assignment object. The CO-PA component is supplied with the necessary information from the IS-U invoicing component for different update types. This information is transferred regularly using transfer reports, which are triggered in FI-CA or IS-U.
The integration in Financial Supply Chain Management improves customer-oriented processes. Business partners can use the Biller Direct component to check invoices and initiate payments (as well as other functions) on the Internet. Companies can use this information channel to interact with their customers.
Extractors for open and cleared FI-CA items, and for other debit-relevant information, were developed for the Business Information Warehouse (BW).
Integrating FI-CA in Customer Relationship Management (CRM) makes it possible to efficiently process transactions in the Call Center.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-6
SAP AG 2003
FI-CA Doc.FI-CA Doc. FIFIPlanning group
Classifies planned revenues and expenditures for updates in the Cash Management (TR-CM) application component.
Business partners are assigned to a planning group at the contract account level. The allocation only applies to the business partner of the relevant contract account.
Additional days for cash management and forecast
Integration with Treasury: Planning Group
In Cash Management, you allocate your business partner to a planning group that reflects certain characteristics and risks, or the type of business relationship, such as: Included in the debit memo procedure Potential delinquent payer
You allocate your business partner to a planning group through entries in the contract account fields for the planning group and additional days for financial planning.
In this way, it is possible to break down short-term financial planning into the probability of cash inflow or cash outflow.
Additional days for financial planning: These days are included in the due date of the open item. The due date for financial planning is obtained by adding the due date and the additional days.
Additional days provide a reference value for deviation from the due date.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-7
SAP AG 2003
Planninglevel
Alternativeplanninglevel for
transaction
Alternativeplanninglevel for
payment block
Determining the planning level:
Treasury: Determination of Planning Level
Contract accountMaster record Planning
group
FI-CAtransaction
Paymentlock
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-8
SAP AG 2003
Business Partner: SD Customer and BP in FI-CA
When you create a contract partner in FI-CA, it is possible to create an SD customer in the background at the same time. The standard customer can:
Take advantages of services
Purchase goods
A standard customer is created based on a predefined reference customer
Different integration scenarios are possible:You can post SD invoices in FI-CA
SD invoicing requests can be integrated in an IS-U invoice
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-9
SAP AG 2003
SD InvoiceFI-AR
FI-SLEC-PCA
...
FI-GLFI-GL
CO-...
CO-PA
FI-CAFI-CAEC-PCA
...
FI-GLFI-GL
CO-PA
CO-PAFI
/CO
Inte
rfac
eFI
/CO
Inte
rfac
eCO-...
Synch
rono
us
FI / SD Integration: Standard Process
Async
hron
ous
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-10
SAP AG 2003
SDInvoice
IS-UBilling
IS-UInvoice
SD In
voic
e typ
e
Acco
unt g
roup
Doc. typePosAr 1210
SD Invoicing Category "U"
Integration: SD Invoicing Document
IS-U
Invoicing request
Doc. typePosAr R400
FI customer
Contract account
FI-AR
FI-CA
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-11
SAP AG 2003
Account
SAP FSCM: Biller Direct
Bill
Account
Customer
WWWWWWWWWE-MailEE--MailMail
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-12
SAP AG 2003
Business Information Warehouse (BW)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-13
SAP AG 2003
BW: Data Extraction, Transformation, and Presentation
DataSource
Data extract
InfoCube
Update rules
Operative data
Transfer rules
InfoSource
Transfer structure Mass run
Customer enhancement
BW
OLTP
BEx
DataSource
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-14
SAP AG 2003
BW: Business Content FI-CA
Open items
Cleared items
Installment plans
Submission to collection agencies
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-15
SAP AG 2003
CRM Integration: Business Agreement
Master data at business partner level for controlling accountingprocesses in FI-CA
Resembles the contract account in FI-CA (less data)
The data is:Terms of payment
Dunning control
Correspondence control
Tax
You can determine the maximum number of business partner agreements for each business partner in Customizing
You can group different types of business agreements in business agreement classes
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-16
SAP AG 2003
CRM – CFM: What is Financial Customer Care?
Customer Relationship Management
Customer Financials
Management
Billing
ReceivablesManagement
Credit Management
ProfitabilityAnalysis
Marketing & Sales
Service &Customer Care
Contract Management
……
Dispute Management
Collections Management
Seamless integration of all finance-relevant data in communication with customers
Based on standard Interaction Center functionality
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-17
SAP AG 2003
Contents of Financial Customer Care
Business partner data (name, address,...)
Contract account data (such as, payment method, disconnections, correspondence settings)
Account balances
Open items
Bills
Payments
Carry forward balance
Dunning notices
Installment plans
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-18
SAP AG 2003
Integration: Customizing
IMG
Financial Accounting
Contract Accounts Receivable and PayableIntegration
SDCustomer Relationship ManagementFinancial Supply Chain Management
General Ledger AccountingControllingCash ManagementBusiness Information Warehouse
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 15-19
SAP AG 2003
Integration: Summary
Contract accounts receivable and payable is integrated in all classic SAP components, as well as the Web-based SAP applications.
Further development of these components include the integration for FI-CA.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 16-1
SAP AG 2003
Contents:
Appendix 1: IS-M Special Features
Appendix 2: IS-T Special Features
Appendix 3: IS-U/CCS Special Features
Appendix
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-1
SAP AG 2003
Contents:
IS-M/SD Connection to IS-M/CA
Renewal Subscriptions
Service Settlement
Appendix 1: IS-M Special Features
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-2
SAP AG 2003
IS-M: Contract Accounts Receivable and Payable IS-M/CA: IS-M/SD Connection to IS-M/CA
IS-M/SD Connection to IS-M/CA
Renewal Subscriptions
Service Settlement
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-3
SAP AG 2003
IS-M/SD Connection to IS-M/CA: Overview
Contract Accounts Receivable and Payable
Media Sales and Distribution
TransferDoc.Type
Doc.
General Ledger
FI-GLFI-GL
Source:Media Sales
and Distribution
Transaction Transfer
OrderItem
Invoice
Account Assign-ment Data
Item
Receivables AccountContract
Account
One FI-CA document is created for each M/SD invoice transferred. The resulting FI-CA documents are created with the origin M1, and are recognized as separate documents.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-4
SAP AG 2003
Contract Account Determination in Order I
Contract account 2
Contract account determination
Contract account 1
Contract account 2
Contract account 3
Input help
Contract account 1
Contract account 3
Business Partner
GP1tract account determinationPayer: GP1
Order
In the SD order for media sales and distribution, the 'contract account' field was included as a new input field for contract accounts receivable and payable. It is included in the order header and items. The SD business partner, for whom the contract account is specified, is the order payer. If precisely one contract account exists for the payer, then this is automatically transferred to the order. If more than one contract account exists, then a selection list appears when you create the order. In this way it is possible to specify a payer / contract account combination for each order item. In the invoice, the invoices are then split for different contract accounts. The contract account from accounting is entered in the order header.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-5
SAP AG 2003
Contract Account Determination in Order II
Order
Automatic allocation
Controlled by
user exit
Contract account 2
Contract account 1
Contract account 3
Business Partner
GP1
Contract account determination
Payer: GP1
You can use the user exit SAMJ45A_015 and enhancement J45A0012 to adjust the contract account determination to meet your requirements. In addition to the aforementioned options, you also have the following alternatives:
- The contract account is selected automatically. - All contract accounts existing for the payer are discarded, and a new contract account is created
automatically. - All contract accounts existing for the payer are discarded. You manually create a contract account
in the dialog.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-6
SAP AG 2003
Order
Create contract accountContract account 2
Contract account 1
Contract account 3
Business Partner
GP1
Contract account determination
Payer: GP1
Contract Account Determination in Order III
If no contract account exists for the payer, you can create a contract account in the dialog.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-7
SAP AG 2003
Contract Accounts Receivable and Payable
Media Sales and Distribution
OrderItem
InvoiceItem
Contract Account
Automatic Debit
Automatic Debit
Payment Methods in Contract Account
Automatic Debitwith Bank Details
Payment RunAutomatic Debitwith Bank Details
Transfer
Doc.
You define the payment method and the additional payment method data (such as bank details and payment card data) in contract account. Note that, unlike for other procedures in media sales and distribution, you do not enter a value for the payment method Bill in contract account.
When entering the order, the payment method is transferred to the order from contract account. It can then be used in pricing. The additional data, such as bank details and payment card data, is not transferred to the order.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-8
SAP AG 2003
Contract Accounts Receivable and Payable
Media Sales and Distribution
Different Payment Methods in Order
OrderItem
InvoiceItem
Transfer
Contract Account
Automatic Debit
Bill
Automatic Debit
Automatic Debit
Automatic Debit
Payment Run
Doc.
In media sales and distribution, you can use the function Payment Different from Contract Acct. to change the payment method and additional data. You have the following options: You select a payment method different to the contract account. You select bank details or payment card data for the payment method that differ from contract accounts receivable and payable.
The differing data is transferred to the invoice and the FI-CA document. Due to the payment controls in contract accounts receivable and payable (cash discount deadline + cash discount % / due date for net payment), you cannot use all standard FI terms of payment. The following restrictions apply: You can only define one cash discount period. The second cash discount period is interpreted as the net payment due date, and must have the cash discount percentage 0.00.
The the terms of payment must be defined and valid for the whole month. Installment payment conditions are not supported. The system does not support the inclusion of a factory calendar during the conversion of terms of payment into corresponding due dates, which is possible in IS-U.
The check to see whether a term of payment is suitable for use with FI-CA takes place when allocating the term of payment in the sales area data - customer invoicing - and during entry in the SD order.
You can use the function Pyt According to Contract Acct to cancel the changed data.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-9
SAP AG 2003
Payment Method: Cash Payer
Contract Account
Contract Accounts Receivable and Payable
Media Sales and Distribution
OrderItem
InvoiceHeader Transfer
Bill
Payment Form Table
Payment Form Number
+ Payment Form Number
Payment Form
Cash payer
• Document No.• Payment
Form Number
Doc.Document No.
When you create an invoice for orders without a payment method (bill), a payment form number is determined and transferred to the invoicing document. You can print the payment form number on the payment medium during the bill print . During the invoice transfer, the payment form number is transferred to the IS-M/CA document, and the payment form table is updated. Clearing takes place automatically through the payment form table when the payment is received in IS-M/CA.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-10
SAP AG 2003
Deriving Transactions from IS-M/SD Information
Transaction
Sub-transaction
Represents a business transaction
Main Transaction
Item Type
Debit / Credit Indicator
Account Key
Sales Document Type
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-11
SAP AG 2003
Deriving the Receivables Account
Contract Accounts
Receivable and Payable
Media Sales and Distribution
TransferBusiness Partner
Deriving the Receivables
Account+ User Exit
Receivables Account
Doc.
Receivables Account
(BP Item)
The account determination is not carried on in IS/M-CA. The accounts are determined in M/SD and transferred to IS-M/CA. The account determination only takes place in IS-M/CA for manual and automatic postings that are initiated in IS-M/CA itself, such as the posting of dunning charges and return charges.
The customer line items from the SD invoicing document transferred to the accounting interface are enhanced with the following information:
- General information (for example, reference specifications) - Information from the contract account (for example, account determination ID) - Information on main transactions and subtransactions for each company code and division (for
example, dunnings, interest, payment) The business partner items are determined from the customer line items. This takes place in contract accounts receivable and payable.
The information is derived using event 4000, which is called to enhance customer line items and G/L account items.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-12
SAP AG 2003
IS-M/SD Connection to IS-M/CA: Revenue Deferral
Contract Accounts
Receivable and Payable
Media Sales and Distribution
TransferDoc.Type
Source:Media Revenue
Deferral
(Summarized) Deferred
Revenues
Doc.
General Ledger
FI-GLTransfer
FI-GLPure G/L Account
Document
For the revenue deferral, the system determines the revenues that have not yet been realised. The deferred revenues are posted to the G/L accounts, which are determined on the basis of conditions (Customizing for account assignment in Media Sales and Distribution) when creating the invoicing documents.
For the general ledger accounting to be explained and reconciled by contract accounts receivable and payable, all pure G/L account transfer postings required for the revenue deferral must also be posted in contract accounts receivable and payable. These IS-M/CA documents are created with the origin indicator M2.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-13
SAP AG 2003
IS-M: Contract Accounts Receivable and Payable IS-M/CA: Renewal Subscriptions
IS-M/SD Connection to IS-M/CA
Renewal Subscriptions
Service Settlement
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-14
SAP AG 2003
Renewal Subscription - Customer Driven Payments
Period covered by payment amount
IS-M/SD IS-M/CA
FirstExpiry Date Contract
AccountOrder
Billing
t
Period covered by new payment amount
Monitoring Period
Renewal offerReminders
Levels
Payment
Tolerance periods
SuspensionTerminationResumption
Liability acctPayment Amort. Payment Amort.
Open Item
CheckCash PaymentBank Transfer
NewExpiry Date
Liability acctBilling
1
2
3
1. Incoming Payment Incoming payments for renewal subscriptions are automatically allocated to order items, and thus trigger
the subscription renewal. Incoming payments in IS-M/CA can be made by check, bank transfer, and cash payment.
The incoming payment is made by specifying the assignment number and the amount. The system uses this to post a payment on account, which is indicated as a down payment and is given a payment block reason. This is to prevent a refund by bank transfer through the payment run.
2. Invoice Data Transfer The renewal offer is accepted in IS-M/SD when posting the payment document. An invoice index is
generated, which leads to the creation of the invoice in IS-M/SD. Transferring the invoice to IS-M/CA generates a receivable item. In the document, corresponding references to the IS-M/SD fields are set.
3. Automatic Clearing and Account Maintenance The clearing of the payment document using the receivable item is carried out using the automatic
clearing (clearing type 04) or account maintenance in dialog (clearing type 03). Both the automatic settlement and the account maintenance use the clearing control functionality. For this a new clearing variant with corresponding clearing steps is necessary. Clearing variant 002 is provided, which primarily uses the company code and assignment number to execute the clearing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-15
SAP AG 2003
Cancellation of Customer Driven Payments
Period covered by payment amount
IS-M/SD IS-M/CA
FirstExpiry Date Contract
AccountOrder
Billing
t
Period covered by new payment amount
Monitoring period
Renewal offerReminders
Levels
Payment
Toleranceperiods
SuspensionTerminationResumption
Liability acctPayment Amort. Payment Amort.
Open Item
CheckCash PaymentBank Transfer
NewExpiry Date
Liability acct Billing
Cancellation Item
Cancellation
Refunding
3
2
X1
4
There are different methods for reversing an incoming payment in IS-M/CA: - Outgoing payment by payment run, with reference to down payment document - Outgoing payment by cash payment at cash desk, with reference to down payment document - Reversal of down payment document
When posting the outgoing payment document or reversal document, the corresponding clearing document is cleared first (1), if the down payment document has already been settled with the receivable from the invoice transfer. In IS-M/SD the renewal offer is rejected again. The invoice is then cancelled and a cancellation invoice is created (3), which can be settled with the invoice receivable item (4).
If the outgoing payment (2) is to take place by payment run, the payment block must be reversed in the down payment document. If the outgoing payment is at the cash desk, this is not necessary.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-16
SAP AG 2003
Renewal Subscription - Company-Driven Payment
Period covered by payment amount
IS-M/SD IS-M/CA
Firstexpiry date Contract
AccountOrder
Billing
t
Period covered by new paymentamount
Monitoring period
Renewal offerReminders
Levels
Payment
Toleranceperiods
SuspensionTerminationResumption
Liability acctPayment Amort. Payment Amort.
Open item
Credit cardDirect debit
Newexpiry date
Liability acctBilling
2
1
3
If a customer pays for a subscription renewal by payment card or automatic debit, the renewal offer is accepted immediately when the incoming payment is generated, and the subscription renewal is extended. When this happens, the system creates a billing document index, which triggers the creation of billing documents.
Once the billing documents have been created, the payment process can be divided chronologically in the following way:
1. Billing Document Transfer Transferring the billing document to IS-M/CA generates a receivable item. Corresponding references to
the IS-M/SD fields are set in the document. 2. Incoming Payment The incoming payment refers to the item that was created when the billing data was transferred from
IS-M/SD. In IS-M/CA, the incoming payment is made by payment card or automatic debit. 3. Clearing Clearing receivables items is triggered automatically by the payment run.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-17
SAP AG 2003
Cancellation of Company-Driven Payment –Change to Check / Cash
Period covered by payment amount
IS-M/SD IS-M/CA
Firstexpiry date Contract
accountOrder
Billing
t
Periods covered by new payment amount
Monitoring period
Renewal offerReminders
Levels
Payment
Toleranceperiods
SuspensionTerminationResumption
Liability acctPayment Amort. Payment Amort.
Open items
Credit cardDirect debit
Newexpiry date
Liability acct Billing
Cancellation item
Cancellation
Return
3
2
X1
4
If an automatic debit is unsuccessful, a returns document is posted in IS-M/CA (2). When this happens, the system interprets returns activities in Customizing. When the returns document is posted, the clearing of the receivables item is reversed (1).
a) Returns with the same payment method If the returns activity has been defined in such a way that the payment method is retained in IS-M/CA,
recalculation does not take place in IS-M/SD when the returns document is posted, and the subscription renewal remains accepted.
b) Returns without payment method When the returns document is posted, the acceptance of the subscription renewal is reversed in IS-M/SD. The billing document is reversed and a cancellation billing document is created (3). The billing data transfer of the cancellation billing document, automatic clearing (4) and account maintenance for returns all correspond to the procedures described in the 'Other Business Transactions' unit. As result of this procedure, the customer is converted to an invoice payer. He or she receives a renewal offer that contains information from the returns document. The corresponding print program and form have to be created for each individual customer.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-18
SAP AG 2003
Payment Amount Reduced by Credit Note
IS-M/SD IS-M/CA
Firstexpiry date Contract
accountOrder
Billing
t
Monitoring period
Renewal offer
Levels
Billing
Payment
Toleranceperiods
SuspensionTerminationResumption
Liability acctPayment Amort.
2b
3
4Clearing
CheckCash PaymentBank Transfer
Newexpiry date
Complaintsuspension
Credititem
1bBilling of credit note
Open item60.00 -5.00
-55.00
Offer60.00-5.0055.00
1a
2a
In the case of a complaint with monetary credit (1a), the expiry date of the subscription is not extended. A credit memo is generated in IS-M/CA. However, this is not paid out immediately. Instead it is used to reduce the payment amount for the subsequent renewal offer.
To prevent the amount being paid out, you must set a payment lock reason (1b) for the corresponding transaction during billing data transfer.
In the renewal offer, the customer is informed that the amount to be paid has been reduced by the amount in the complaint credit memo (2a). When the customer makes the payment, the system determines the credit item. The amount from credit item and the payment amount is accepted for the subscription renewal (2b).
Once the invoice has been created, the open invoice item is created for the complete invoice amount (3). The payment is cleared against the invoice and credit document (4).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-19
SAP AG 2003
IS-M: Contract Accounts Receivable and Payable IS-M/CA: Service Settlement
IS-M/SD Connection to IS-M/CA
Renewal Subscriptions
Service Settlement
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-20
SAP AG 2003
IS-M/SD Connection to IS-M/CA: Service Settlement
Contract Accounts
Receivable and Payable
Media Sales and Distribution
Document
General Ledger
FI-GLFI-GL
Source:Service
settlement
Transfer
Employment relationship orservice company
Service settlement
Contract account
Account Assignment Data
Transfer+ Doc. type+ Transaction+ Receivables
account
An FI-CA document is created for each transferred M/SD service settlement. The resulting FI-CA documents are created with the origin M3, and are recognized as separate documents.
During employee settlement, the contract account is allocated in the employment relationship, in the case of service company settlement it is allocated in the settlement data for the service company. When an employment relationship is created, the contract account can be automatically generated and allocated using the SAP enhancement JG050002.
The contract account is determined and recorded in the billing header when the service settlement is created. It is then transferred to the document.
The receivables account is determined at event 1101. The standard module defined there determines the receivables account using the settings in main or subtransaction account assignment.
In addition to the data in the service settlement, the following information is also determined and transferred to the IS-M/CA document:
- Type of the IS-M/CA document - Main transaction and subtransaction
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 17-21
SAP AG 2003
The IS-M Media Sales and Distribution component processes sales of periodic publications (newspapers and magazines). The emphasis here is on processing subscriptions.
In IS-M/SD, it is also possible to settle services from employees or service companies.
Subscription and service settlement can be transferred to contract accounts receivable and payable. You can use media-specific functions to process debit/credit activities.
IS- M Special Features: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-1
SAP AG 2003
Contents:
Data storage in RM-CA
Transfer of invoices from external billing systems
Disconnection/Reconnection Files
Appendix 2: IS-T Special Features
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-2
SAP AG 2003
IS-T: RMCA: Data Storage in RM-CA
Data Storage in RM-CA
Invoices from EBS
Disconnection/Reconnection Files
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-3
SAP AG 2003
Database Table IST_TDATA
CRM(optional)
Telephone number
management
EBS
R/3 (RM-CA)
Table IST-TDATA Table DFKKOP
ActivationBilling
OBJECT_ID
SERVICE
VALID_FROM
GROUP_ID
...
ADD_REFOBJ
ADD_REFOBJID
...
Service data(incl. disconnection infos)are replicated
Disconnection/reconnection files
Invoice items
Disconnection infos
Service data
Table IST_TDATA contains all RM-CA data for the telecommunication services that originates from the mySAP CRM telephone number management or an external system.
This includes the following data from the telecommunication services: Object key (OBJECT_ID): This field is used to uniquely identify every entry in a service at a particular event. You can, for example, use the complete telephone number (country code + area code + number), the SIM card number (for cellular network providers), or the IP address (for internet service).
Service (SERVICE): This field determines the telecommunication service (for example, telephony) the object key belongs to.
Validity (VALID_FROM): This field contains the date from when an entry is valid. You can allocate, for example, a telephone number (telephony service) to two different contract accounts with different validity periods.
Grouping information (GROUP_ID): For the telephony service, every entry is a telephone number. In the case of multi-line connections, it must be possible to group together telephone numbers. This is because the billing system can cumulate individual call data records as document items for each telephone number and transfer them to RM-CA. In some cases, data can even refer to several telephone numbers (such as a basic charge). The GROUP_ID guarantees the unique relationship of document item - telephone number.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-4
SAP AG 2003
IS-T: RMCA: Invoices from EBS
Data Storage in RM-CA
Invoices from EBS
Disconnection/Reconnection Files
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-5
SAP AG 2003
IDoc Interface
An IDoc interface is used to transfer business data to and from an external system. Scenarios include:
Electronic data interchange (EDI)
Application Link Enabling (ALE)
Connect of any number of other business application systems (for example, pc applications, external workflow tools) using IDoc.
The IDoc interface is made up of the definition of a data structure and a processing logic for this data structure.
Information
(SAP library – Basis -> Basis-Services -> Communication Interface -> IDoc Interface)
Tools → Business Communication → IDoc → IDoc Basis
Services are billed in an external billing system. However, the resulting receivables are managed in contract accounts receivable and payable. As a result, invoice items must transferred to contract accounts receivable and payable. The data is transferred via the interface for billing documents. In contract accounts receivable and payable, the invoice lines are automatically posted as open items to the corresponding contract accounts and business partners. If necessary, you can also enter additional account assignments for profitability analysis (CO-PA) in the interface or add them via Customizing, and transfer the accounting information to profitability segments.
For further information on the invoice interface for IS-T, see the online documentation for the Telecommunications industry component.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-6
SAP AG 2003
IS-T/IS-U IDOC Interfaces
1. Invoice document transfer + optional CO-PA update2. Archive link to optical invoice archive3. Mass reversal
Optical archive2
Doc.No. Invoice No. Amount… … …0000815 4709 xx.xx0000816 4710 xx.xx0000817 4711 Reversal0000818 4712 xx.xx0000819 4713 xx.xx… … …
Invoice4711
xx.xx
3
FI-CA
Bill 4711
xx.xx
Bill 4711
xx.xx
Bill 4711
xx.xx
Invoice4711
xx.xx
FI-CADoc.No. Invoice No. Amount… … …0000815 4709 xx.xx0000816 4710 xx.xx0000817 4711 xx.xx0000818 4712 xx.xx0000819 4713 xx.xx… … …1
EBS
FIAccount Amount880000 …175000 xx.xx
CO-PADivision Quantity AmountFixedNet. xxxx xx.xxCell. xxxx xx.xxInternet xxxx xx.xx
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-7
SAP AG 2003
Invoice Document Transfer (Business Scenario)
Doc. no. Item G/LAccount Amount Quantity4711 1 175000 8.00-4711 1 080000 50.00- 20 4711 2 175000 8.00-4711 2 080000 50.00- 104711 3 175000 16.00-4711 3 080000 100.00- 5
General ledger items (tax and revenue posting)
Doc. number Currency Date4711 USD 07/21/2003
Doc. header
Business partner items
Doc. no. Item Bus. partner Contr.Acct G/L Account Amount4711 1 Smith MM01 140000 58.004711 2 Smith MM01 140000 58.004711 3 Smith MM01 140000 116.00
IS-T/IS-U FI-CA
Invoice
transfer
Open item
Total 200.00 32.00
Martin Mustermann
Invoice no. 4711
Quantity Rate Price Tax
Total: 232.00
Value fields
Characteristics
CharacteristicsRate Quantity RevenueLocal call 20 50.00National 10 50.00International 5 100.00
CO-PA
20 local calls 50.00 8.0010 national 50.00 8.0005 international 100.00 16.00
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-8
SAP AG 2003
Mass Reversal Interface
RM-CA
Open items
The interface for transferring the invoice document generates open items in RM-CA. The key is created in the document header and is made up of the fields
AWSYS, AWKEY and AWTYP.
OPBEL...
10000001
AWSYS
LogSys
AWKEY
0004711
AWTYP
ISTBS
...
Document header data (table DFKKKO)
...
LogSys 0004712
LogSys 0004713
10000002
10000003
ISTBS
ISTBS
EBS
Mass reversal
The mass reversal interface only transfers the filed AWKEY. This field is enough to map the whole key,
as well as identify and reverse the corresponding invoice document
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-9
SAP AG 2003
Possible Processing Runs
Status "64"(IDoc ready for transfer
to application)
Status "64"(IDoc ready for transfer
to application)
Data sent from EBS to RM-CA
Data sent from EBS to RM-CA
Very high error rate(e.g. due to incorrect Customizing settings)
Very high error rate(e.g. due to incorrect Customizing settings)
Processing by mass activity
Processing by mass activity
Status "53"(Application document
posted)
Status "53"(Application document
posted)
Low error rate(Manual correction)
Low error rate(Manual correction)
Status "69"(IDoc edited)Status "69"
(IDoc edited)
Status "53"(application document
posted)
Status "53"(application document
posted)
Error processing (for example, change Customizing settings) and scheduling using
mass processing
Error processing (for example, change Customizing settings) and scheduling using
mass processing
Scheduling using mass processing
(ONLY STATUS "69")
Scheduling using mass processing
(ONLY STATUS "69")
Status "51"(Application document
not posted)
Status "51"(Application document
not posted)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-10
SAP AG 2003
IS-T: RMCA: Disconnection/Reconnection Files
Data Storage in RM-CA
Invoices from EBS
Disconnection/Reconnection Files
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-11
SAP AG 2003
External Billing System
Mail / escalation processing
Disconnection file
Dunning history
Disconnection File for Telephone Numbers
Dunning activity run
In this function, the Disconnect Services activity is triggered in a dunning run of unpaid items once a certain dunning level has been reached.
The disconnection is executed in an external system, such as an external billing system (EBS). This system has to know which service is to be disconnected. The information for disconnecting a service is generated as a disconnection file in RM-CA and transferred to the external billing system. The disconnection file from RM-CA only contains a disconnection proposal. The external billing service actually disconnects the service.
A service disconnection is executed in the following steps: 1.The dunning activity Disconnect Service is triggered in the dunning run. 2. The disconnection file is generated. An entry is generated in the disconnection file for each open item. In addition to the standard fields, you can also include further document fields in the table structure. You can use the SAP enhancement ISTDUNN1 with the function module EXIT_SAPLIST_CA_DUNEVENT_001 to maintain your own fields.
The disconnection files have the following naming conventions: Disconnection file from dunning activity run: BTnnnnnnn Disconnection file from simulation run: BBnnnnnnn
The file is transferred to an external system (for example, an external billing system). At the end of the dunning run, the file must be transferred to your billing system using your own interface program. You have to define your interface program in the function module Transfer (Dis)Connection File for Services Via User Exit (EXIT_SAPLIST_DUNEVENT_001) of SAP enhancement ISTDUNN1.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-12
SAP AG 2003
Payment lotCash DeskAccount maintenanceCredit
Externalbilling system
Mail / escalation processing
Reconnection file
File
Account balance
Reconnection File for Telephone Numbers
Payment
Mass activity
A BXX XX
Posting
Once the necessary payments have been made, the telecommunication services for the dunned open item that was responsible for the disconnection are reconnected or released.
The release is executed in an external system, such as an external billing system (EBS). This system has to know which disconnected service is to be reconnected.
The information for reconnecting the service is transferred to the external billing system as reconnection file, or it can be directly transferred using a SAP enhancement (user exit). However, the reconnection file only contains a reconnection proposal from RM-CA, the external billing system executes the actual reconnection.
The services are reconnected in the Generate Reconnection File mass activity (ISTCAXT910). The reconnection files have the following naming conventions: Reconnection file from an update run: UTnnnnnnn Reconnection file from a simulation run: UUnnnnnnn
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 18-13
SAP AG 2003
In IS-T, telecommunication data can be stored in documents.
Billing documents from telecommunication services are transferred from the external billing system via a specific interface for invoicing documents to contract accounts receivable and payable.
You can use the dunning procedure to initiate the disconnection of telecommunication services if items are not paid. Once the items have been paid or cleared, you can reconnect the services.
IS-T Special Features: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-1
SAP AG 2003
Contents:
Budget billing procedure - Postings
Payment in a deregulated environment - Postings
Appendix 3: IS-U/CCS Special Features
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-2
SAP AG 2003
Budget Billing Procedures: Overview
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-3
SAP AG 2003
Statistical procedure
Debit entry procedure
(partial bills)
AMB - Average monthly billing
BBP - Budget billing plan
Implemented Budget Billing Procedures
In the statistical procedure, the budget billing amounts are managed in IS-U statistically. They are not posted to the general ledger until payment has been received.
In the partial bill procedure, the individual amounts are posted directly as debits. In the budget billing plan, an average amount is determined either by simulation or manually. The customer pays this average amount for a period of 12 months. At the end of this period, a new simulation is run for the next period. In addition, actual consumption is calculated monthly, and the results are printed on the bill. In addition, the difference between the customer's actual consumption and the average amount is calculated, updated monthly, and printed on the bill. In the last month of the billing period, the actual amount and the accumulated difference are billed.
In average monthly billing/equalized billing, the customer is charged an average amount based on billings over the last 12 months (or less in the case of new customers). In addition, actual consumption is calculated monthly, and the results are printed on the bill. The amounts due for later months are calculated using the average of the previous (maximum 11) months plus the current bill and the accumulated difference. This difference is updated monthly and is also printed on the bill. In final billing, the amount due is derived from the actual consumption and the accumulated difference.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-4
SAP AG 2003
BB amt. nBB amt 2
BB amt 1
BB plan
Invo
icin
g
Invo
icin
g
BB amt. nBB amt 2
BB amt 1
BB planBB
payment nBBpayment 2
ReceivedBB
amounts
ReceivablefromYAP
ReceivablefromYAP
FIIS-U
Budget Billing Requests: Statistical Procedure
BBpayment 1
You can choose from various procedures for budget billing collection, which differ in terms of financial accounting.
If you select the statistical procedure, the budget billing requests are managed as statistical items in FI-CA and do not initially affect the general ledger.
The payable is not posted to the general ledger and tax is not cleared until payment for the statistical budget billing plan item has been received. The budget billing payments are cleared with the next annual consumption billing.
In this procedure, tax is not posted in FI and paid to the tax authorities until the budget billing is paid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-5
SAP AG 2003
BB amt. nBB amt 2
BB amt 1
BB plan
Invo
icin
g
Invo
icin
g
BB amt. nBB amt 2
BB amt 1
BB planBB
payment nBBpayment 2
ReceivablefromYAP
ReceivablefromYAP
FIIS-U
Budget Billing Requests: Debit Entry Procedure
Part
ial b
illin
g
Partial billingreceivable
BBpayment
BBpayment 1
If you select the debit entry procedure, the budget billing requests are posted as partial bills. This makes them relevant to the general ledger.
When a partial bill is posted, the due budget billing is posted as a debit both in subledger accounting and general ledger accounting. The partial bills posted as debits are then cleared with the next annual consumption billing.
Unpaid partial bills are subject to the normal dunning procedure. In this procedure, tax is posted to the general ledger and paid to the tax authorities when the budget billings are entered as debits.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-6
SAP AG 2003
Budget Billing Procedure: Statistical Budget Billing Procedure
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-7
SAP AG 2003
This example displays the statistical procedure.
Example I: - Electricity division- Tax rate: 16%- Budget billing amount: 58.00- Consumption billing: 69.60
Statistical Procedure: Example
To simplify the example, only one budget billing is requested and paid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-8
SAP AG 2003
FI
Tax account
Bank
Contract account IS-U[1] 58.--
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax clearing
Budget billing amounts received
Budget Billing Payments: Postings 1
IS-U
1. (Statistical) posting of the budget billing request in IS-U.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-9
SAP AG 2003
FI
Tax account
Bank
Contract account IS-U
[2] 58.--
[1] 58.--
58.-- [2]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax clearing
Budget billing amounts received
Budget Billing Payments: Postings 2
IS-U
2. Posting of incoming payment in general ledger accounting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-10
SAP AG 2003
FI
Tax account
Bank
Contract account IS-U
[3] 8.--
([1] 58.--0.--)
[3] 58.-- 58.-- [2] 58.-- [3]
8.-- [3]
58.-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax clearing
Budget billing amounts received
Budget Billing Payments: Postings 3
[2] 58.--
IS-U
3. Payment posting in sub-ledger accounting and allocation of the budget billing payment to the due date in the budget billing plan.
This clears the statistical budget billing request. In addition, the posting for general ledger accounting is generated. In the case of the statistical budget billing procedure represented here, the gross procedure is used.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-11
SAP AG 2003
FI
Tax account
Bank
Contract account IS-U
[2] 58,--
([1] 58.--0.--)
[4] 69.60
[4] 69.60
[3] 58.-- 58.-- [2] 58.-- [3]
9.60 [4]8.-- [3]
60.-- [4]
58.-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax clearing
Budget billing amounts received
Budget Billing Payments: Postings 4
[3] 8.--
IS-U
4. Posting consumption billing in IS-U using IS-U invoicing. The debit entry of the receivable is made available for general ledger accounting.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-12
SAP AG 2003
FI
IS-U
Tax account
Bank
Contract account IS-U
[3] 8.-- 8.-- [5]
[5] 58.--
([1] 58.--0.--)
[4.5] 11.60
[4] 69.60
[5] 8.--
[3] 58.-- 58.-- [2] 58.-- [3]
9.60 [4]8.-- [3]
60.-- [4]58.-- [5]
58.-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax clearing
Budget billing amounts received
Budget Billing Payments: Postings 5
[2] 58.--
5. Budget billing transfer posting in IS-U. In general ledger accounting, transfer posting takes place in conjunction with a tax adjustment posting. Steps 4 and 5 are performed internally in one step, so that only the balance between the amount of the invoice and the budget billing payments is open after invoicing.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-13
SAP AG 2003
This example displays the statistical procedure.
Example 2: Electricity - Tax rate: 16%- Budget billing amount 60.00- Billing 46.40
Water - Tax rate: 7%- Budget billing amount 50.00- Billing 53.50
Budget Billing Payments: Overpayment - 1
To simplify the example, only one budget billing is requested and paid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-14
SAP AG 2003
FI
IS-U
Tax account
BB received - Elec.Bank
Revenue account -Electricity
Receivables -Electricity
Tax clearing
Bank clearing BB received - Water
Receivables - WaterRevenue account -
Water
Electricity Water - IS-U Contr. Acct - Electricity Water50.--[1] 60.-- 110.--
Budget Billing Payments: Overpayment - 2
1. (Statistical) posting of the budget billing request in IS-U.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-15
SAP AG 2003
Budget Billing Payments: Overpayment - 3
FI
IS-U
Tax account
BB received - Elec.Bank
Revenue account -Electricity
Receivables -Electricity
Tax clearing
Bank clearing BB received - Water
Receivables - WaterRevenue account -
Water
Electricity Water - IS-U Contr. Acct - Electricity Water50.--[1] 60.-- 110.--
[2] 110.-- 110.-- [2]
2. Posting of the incoming payment to the general ledger.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-16
SAP AG 2003
Budget Billing Payments: Overpayment - 4
FI
IS-U
Tax account
BB received - Elec.Bank
Revenue account -Electricity
Receivables -Electricity
Tax clearing
Bank clearing BB received - Water
Receivables - WaterRevenue account -
Water
Electricity Water - IS-U Contr. Acct - Electricity Water50.--[1] 60.-- 110.--
110.-- [2]
60.--110.-- 50.-- [3]
[3] 11.55
50.-- [3]60.-- [3][3] 110.--
11.55 [3]
[2] 110.--
3. Allocation of the budget billing payment in IS-U by means of incoming payment processing. Posting of the budget billing payment and tax to the general ledger.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-17
SAP AG 2003
Budget Billing Payments: Overpayment - 5
FI
IS-U
Tax account
BB received - Elec.Bank
Revenue account -Electricity
Receivables -Electricity
Tax clearing
Bank clearing BB received - Water
Receivables - WaterRevenue account -
Water
Electricity Water - IS-U Contr. Acct - Electricity Water50.--[1] 60.-- 110.--
[2] 110.-- 110.-- [2]
60.--110.-- 50.-- [3]
[3] 11.55
50.-- [3]
11.55 [3]
50.-- [5]99,90[4] 46.40 60.--110.--53.50
[F] 3.50 [G] 13.6010.10
60.-- [5] 50.-- [4][4] 46.40 40.-- [4][4] 53.50 50.-- [5]
60.-- [3][5] 60.-- [5] 50.--[3] 110.--
[5] 11.55 11.55 [5]9.90 [4]
4. Posting of consumption billing using IS-U invoicing. 5. Budget billing transfer posting in IS-U. Tax adjustment posting to the general ledger. (Steps 4 and 5 are performed internally in one step)
The consumption billing and budget billing amounts produce a credit (C) of 13.60 in the electricity division and an outstanding receivable (R) of 3.50 in the water division. This results in remaining credit of 10.10 for the customer.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-18
SAP AG 2003
Managing outstanding credit (in the additional function 'Account Maintenance' in IS-U Invoicing)
Cleared against outstanding receivables from other divisions
Cleared against the first budget billing amount
Distributed among budget billing amounts from different divisions
Division priorities
Percentage weighting of individual divisions
Budget Billing Payments: Overpayment/Underpayment
IS-UElectricity Water - IS-U Contr. Acct - Electricity Water50.--[1] 60.-- 110.-- 60.--110.-- 50.-- [3]
50.-- [5]99.90[4] 46.40 60.--110.--53.50
[F] 3.50 [G] 13.6010.10
The way in which remaining credit from consumption billing is cleared against other receivables or future due budget billings is specified in clearing control.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-19
SAP AG 2003
Budget Billing Procedure: Partial Bill Procedure
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-20
SAP AG 2003
This example presents the partial bill procedure.
Example: Electricity - Tax rate: 16%- Budget billing amount 58.00- Billing 232.00
Partial Billing Procedure: Example
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-21
SAP AG 2003
FI
IS-U
Partial bill receivables
Bank
Contract account IS-U
8.-- [1]
[1] 58.--
[1] 58.--
[3] 58.-- 58.-- [2] 50.-- [1]
58.-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax account
Partial bill revenues
58.-- [3]
Partial Billing Procedure: Postings 1
[2] 58.--
1. Posting of the budget billing receivable as a partial bill in IS-U Debit entry of a budget billing due date in conjunction with tax posting to the general ledger.
2. Posting of the incoming payment to the general ledger. 3. Allocation of the budget billing payment in IS-U using IS-U incoming payments.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-22
SAP AG 2003
Partial Billing Procedure: Postings 2
FI
IS-U
Partial bill receivables
Bank
Contract account IS-U
8.-- [1]8.-- [1a]
[1] 58.--[1a] 58.--
[1] 58,--[1a] 58.--
[3] 58.-- 50.-- [1]50.-- [1a]
58,-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax account
Partial bill revenues
58.-- [3]
[2] 58.-- 58.-- [2]
1. Posting of the budget billing receivable in IS-U 1a. Posting of an additional budget billing receivable in IS-U
1. Debit entry of a budget billing due date in conjunction with tax posting to the general ledger 1a. New debit entry of an additional budget billing due date in conjunction with tax posting
2. Posting of the incoming payment to the general ledger. Only one partial bill was paid. 3. Allocation of the budget billing payment in IS-U using IS-U incoming payments.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-23
SAP AG 2003
Partial Billing Procedure: Postings 3
FI
IS-U
Partial bill receivables
Bank
Contract account IS-U[1] 58.--[1a] 58.--[4,5] 116.--
[1] 58.--[1a] 58.--
[3] 58.-- 58.-- [2] 50.-- [1]50.-- [1a]
58.-- [3]
Receivables - Electricity
Bank clearing
Revenue account - Electricity
Tax account
Partial bill revenues
58.-- [3]
[2] 58.--
[4] 232.-- 58.-- [5]58.-- [5]
200.-- [4]
[5] 50.--[5] 50.--
16.-- [1+1a]32.-- [4]
[5] 16.--
1. Posting of the budget billing receivable in IS-U 1a. Posting of an additional budget billing receivable in IS-U
1. Debit entry of a budget billing due date in conjunction with tax posting to the general ledger 1a. New debit entry of an additional budget billing due date in conjunction with tax posting
2. Posting of the incoming payment to the general ledger. Only one partial bill was paid. 3. Allocation of the budget billing payment in IS-U through IS-U incoming payments. 4. Posting of the annual consumption billing through IS-U invoicing 5. In annual consumption billing, all partial bills posted as debits are cleared against the bill amount. In this
way, all partial bills posted as debits are transferred. Steps 4 and 5 are performed in one step, so that only the balance between the amount of the invoice and the requested partial bills as well as the unpaid partial bill are open on the contract account after invoicing.
The unpaid partial bill (1a) is subject to the normal dunning procedure.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-24
SAP AG 2003
Budget Billing Procedures: Payment Plan
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-25
SAP AG 2003
This example represents a payment plan procedure.
Example: Electricity - Tax rate: 16%- Payment plan amt 50.00 - Billing 1 55.11- Billing 2: 65.12
Payment Plan: Example
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-26
SAP AG 2003
BalanceForward
11/01/12/03/01/02/02/03/03/04/04/05/05/05/06/01/07/02/08/03/09/03/10/01/
50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--
Nov.Dec.Jan.Feb.Mar.Apr.MayJuneJulyAug.Sep.Oct.
Payment Plan
55.1165.1251.4550.3450.9849.9948.8749.0145.9845.5650.0952.98
55.11 - 50 65.12 - 50+ 5.11
Bill 10/1550.00
+ 15.4865.48
11/01/12/03/....02/03
52.--52.--....52.--
Nov.Dec.....Oct.
50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--50.--
Actual billing amount
Payment planamount
Newpayment plan
Budget Billing Procedures: Payment Plan
5.1120.2321.6822.0223.0022.9921.8620.8716.8512.4112.5015.48
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-27
SAP AG 2003
Payment Plan: Postings
FI
IS-U
Tax account
Bank
Contract account IS-U
[4] 50.--[4a] 20.23
[1] 55.11[4] 65.12
[3] 50.-- 50.-- [2]
7.60 [1+1a]8.93 [4+4a]
47.51 [1+1a]56.14 [4+4a]
50.-- [3]
G/L account -Electricity
Bank clearing
Revenue account -Electricity
[1] 50.--[1a] 5.11
[2] 50.--
5.11 [4a]
50.-- [3]
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-28
SAP AG 2003
Budget Billing Procedure: Budget Billing Advance Payment
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-29
SAP AG 2003
04/01/ 100.--
07/01/ 100.--
10/01/ 100.--
01/01/ 100.--
Budget billing plan frominvoicing (*):
Budget billing plan after activation of advance payment:
04/01/ 100.--
07/01/ 100.--
07/01/ 100.--
10/01/ 100.--
01/01/ 100.--
X
X
L
Activation dateof advance payment:On 05/01/03
New
New
Jan. - Mar.
Apr. - Jun.
July - Sep.
Oct. - Dec.
Jan.- Mar.
Consumption/advance payment period
Jan.- Mar.
Apr. - June
July - Sep.
Oct. - Dec.
(*) Billing period 1/2 – 1/14 BB amounts/year
Agenda: X = Advance payment flagL = Last due date of an advance payment
If necessary, a new budget billing due date is generated for the end of the budget billing period
Budget Billing Advance Payment
If you want to activate the advance payment function for a budget billing plan, call this function in the change transaction (EA62) using the path Edit -> Activate Advance Payment. Enter the date from which the budget billing plan is to be identified as an advance payment plan. The first due date when the print date /debit entry date is larger than or equal to the start date is doubled, all others are give the indicator X (normal advance payment) in the Advance Payment column. The last due date of an advance payment is flagged with 'L'. The print/debit entry date of the first due date is entered in the header data of the budget billing plan as the start date of the advance payment. When the advance payment is activated, the system also checks if the following requirement is fulfilled:
Budget billing cycle * number of due dates = length of period (for example, 12 months = 12) If it is not fulfilled, an additional due date is added to the last day of the budget billing period.
You must always initially activate the advance payment functionality in a budget billing plan manually. When create new budget billing plans for subsequent periods, you must always make sure that the advance payment is activated.
Important: If the advance payment is activated in a budget billing plan of a mandatory group for an individual contract, the advance payment is active for all mandatory contracts.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-30
SAP AG 2003
Budget Billing Procedure: Yearly Advance Payment
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-31
SAP AG 2003
Yearly Advance Payment: Acceptance
Cash payer Direct debitpayer
YAP participant 1 YAP participant 2
01/15/ 99.-02/15/ 99.-03/15/ 99.-04/15/ 99.-
.
.
.
12/15/ 99.-
ActiveActive
YAPBase1,089.00Bonus
9.07Amount1,079.93
01/15/ 99.-02/15/ 99.-03/15/ 99.-04/15/ 99.-
.
.
.
12/15/ 99.-
Active
YAPBase1,089.00Bonus
9.07Amount1,079.93
01/15/ 99.-02/15/ 99.-03/15/ 99.-04/15/ 99.-
.
.
.
12/15/ 99.-
Active
YAPBase1,089.00Bonus
9.07Amount1,079.93
Acceptance by payingBB or YAP amountby payment block date
Explicit acceptanceby customeror manual switch
Manual switch possible
Account Account
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-32
SAP AG 2003
Yearly Advance Payment
Functions
• Clearing control controls the payment process for cash payers
• YAP is only possible in connection with the statistical budget billing procedure
• Bonuses can be processed during final billing in move-out processing event R991
Restrictions
• No YAP procedure for collective bills
• No workflow support for disputed cases (late payment, overpayment)
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-33
SAP AG 2003
Budget Billing Procedures: Customizing
Statistical Budget Billing Procedure
Customizing
Partial Billing Procedure
Payment Plan
Budget Billing Advance Payment
Yearly Advance Payment
Overview of Budget Billing Procedures
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-34
SAP AG 2003
Budget Billing: Customizing
IMG Contract Accounts Receivable and Payable
Define Budget Billing Procedures
Financial Accounting
Contract Accounts Receivable and PayableBasic Functions
ISU: Define Acct Assmt Data Relevant to Main TransactionsDefine Accounts for Down Payment Tax Clearing
Define Accounts for Budget Billing Down Payments
Allocate Interest Calculation Rule for Yearly Advance Payment
Yearly Advance PaymentDefine Control Parameters for Yearly Advance Payment
Postings and DocumentsDocuments
Define Account Assignments for Automatic PostingsAutomatic G/L Account Determination
SAP UtilitiesInvoicing
Budget Billing Plan
In general Customizing: - Specify main and sub-transactions, and also transactions - Allocation to the internal main and sub-transactions - Specify the document type and the number range - Specify the accounts for the corresponding budget billing procedure
When you define the account assignment of the down payments and charges, you have to specify the transaction used, for example, to clear a budget billing request and how the budget billing can be cleared.
The budget billing procedure is defined in IS-U invoicing. Other settings relevant for budget billing are also made there.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-35
SAP AG 2003
There are different options for charging budget billing amounts in IS-U.
There is a distinction between actual debit entry and the statistical budget billing request.
When statistical budget billing requests are used, tax clearing is posted when incoming payment is received. In invoicing, the budget billing payments received are balanced against the bill amount.
Budget Billing Procedure: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-36
SAP AG 2003
Payment in a Deregulated Environment: Overview
Overview
Budget Billing Request and Payment
Periodic Billing and Invoicing
Individual Reversal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-37
SAP AG 2003
Business Scenario: Grid Usage Processing 1
Create bills/budget billing receivables for
externally supplied points of delivery
Create bills/budget billing receivables for
externally supplied points of delivery
Send bills to supplierSend bills to supplier
Data exchange
Data exchange
Paper printoutPaper
printout
Post aggregated receivables for
supplier to contract account
Post aggregated receivables for
supplier to contract account
Create aggregated bill
Create aggregated bill
Paper printoutPaper
printout
INVOIC
Save incoming billsin the system
Save incoming billsin the system
Data exchange
Data exchange
Identification and check
Identification and check
DistributorDistributor SupplierSupplier
Settings in service provider agreement
In the deregulated energy market, the distributor bills the supplier for grid usage and budget billing receivables. These have to be cleared. The procedure is made up of the following individual processes: Process Short description Billing party Bill processing - Bill and invoice grid usage at individual customer level (Distributor) - Post aggregated receivable to supplier account - Send bill to supplier ____________________________________________________________________________ Incoming payment - Process incoming payment from supplier - Process bill complaints
Bill recipient Incoming bill - Process incoming bill (supplier) processing - Check bills (formal and content) - Transfer data for own billing
Outgoing payment - Post bills - Initiate payment to distributor - Send payment advice note - Communicate bill complaint
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-38
SAP AG 2003
Business Scenario: Grid Usage Processing 2
DistributorDistributor SupplierSupplier
Save payment advice note/ complaint data in system
Save payment advice note/ complaint data in system
Data exchange
Data exchange
Post incoming payment to supplier's
contract account
Post incoming payment to supplier's
contract account
Check complaints, if
necessary bill again
Check complaints, if
necessary bill again
Use payment advice data to
distribute incoming payment among individual
accounts
Use payment advice data to
distribute incoming payment among individual
accounts
Paper printoutPaper
printout
Data exchange
Data exchange
REMADV
Aggreg., post and pay
receivables for supplier
Aggreg., post and pay
receivables for supplier
The following examples are a step-by-step explanation of postings in the distributor processes of bill processing and incoming payments
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-39
SAP AG 2003
Payment in a Deregulated Environment: Budget Billing Request and Payment
Overview
Budget Billing Request and Payment
Periodic Billing and Invoicing
Individual Reversal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-40
SAP AG 2003
This example displays the budget billing request procedure.
Example I: - Tax rate: 16%- Two individual accounts- Two budget billing due dates, only the first budget billing plan is paid
Payment in a Deregulated Environment: Example
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-41
SAP AG 2003
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Payment in a Deregulated Environment -Postings 1
Contract account customer 2
[1] 80.00[1a] 80.00
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-42
SAP AG 2003
Payment in a Deregulated Environment -Postings 2
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--
[2] 110.--[2a] 110.--
110.-- [2]110.-- [2a]
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account.
The aggregated posting to the supplier's contract account is not a statistical posting. The items are
posted in the general ledger using two clearing accounts that have to be balanced at year-end closing. Aggregated posting is gross. Tax is posted with the posting to the individual customer account. You should not include the aggregated postings when open item lists are created, since this would distort the actual amounts.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-43
SAP AG 2003
Payment in a Deregulated Environment -Postings 3
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--
[2] 110.--[2a] 110.--
110.-- [2]110.-- [2a]
[3] 110.-- 110.-- [3]
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-44
SAP AG 2003
Payment in a Deregulated Environment -Postings 4
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--
[2] 110.--[2a] 110.--
110.-- [2]110.-- [2a]
[3] 110.-- 110.-- [3][4] 110.--
110.-- [4]
110.-- [4]
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2, 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-45
SAP AG 2003
Payment in a Deregulated Environment -Postings 5
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--
[2] 110.--[2a] 110.--
110.-- [2]110.-- [2a]
[3] 110.-- 110.-- [3][4] 110.--
110.-- [4]
110.-- [4]
[5] 110.--
80.-- [5] 30.-- [5]
15.17 [5] [5] 15.17
110.-- [5]
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-46
SAP AG 2003
Payment in a Deregulated Environment: Periodic Billing and Invoicing
Overview
Budget Billing Request and Payment
Periodic Billing and Invoicing
Individual Reversal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-47
SAP AG 2003
This example displays the periodic billing procedure.
Example I: - Tax rate: 16%- Two individual accounts- Transfer posting of paid budget billing
amount - Reversal of open budget billing requests
Payment in a Deregulated Environment: Example
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-48
SAP AG 2003
Payment in a Deregulated Environment -Postings 6
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--[6] 40.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--[6] 90.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--
[2] 110.--[2a] 110.--
110.-- [2]110.-- [2a]
[3] 110.-- 110.-- [3][4] 110.--
110.-- [4]
110.-- [4]
[5] 110.--
80.-- [5]80.-- [6]
30.-- [5]30.-- [6]
15.17 [5]33.10 [6]
[5] 15.17
110.-- [5]
[6] 240.-- 206.90 [6]110.-- [6]
[6] 110.--
15.17 [6] [6] 15.17
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2, 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-49
SAP AG 2003
Payment in a Deregulated Environment -Postings 7
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--[6] 40.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--[6] 90.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--[7] 130.--
[2] 110.--[2a] 110.--[7] 130.--
110.-- [2]110.-- [2a]130.-- [7]
[3] 110.-- 110.-- [3][4] 110.--
110.-- [4]110.-- [7]
110.-- [4]110.-- [7]
[5] 110.--[7] 110,--
80.-- [5]80.-- [6]
30.-- [5]30.-- [6]
15.17 [5]33.10 [6]
[5] 15.17
110.-- [5]
[6] 240.-- 206.90 [6]110.-- [6]
[6] 110.--
15.17 [6] [6] 15.17
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
7. Aggregated posting of periodic bills from individual accounts and the reversal of the unpaid aggregated posting for the second budget billing amount.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-50
SAP AG 2003
Payment in a Deregulated Environment -Postings 8
FI
Tax account
Contract account customer 1
[1] 30.--[1a] 30.--[6] 40.--
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
[1] 80.--[1a] 80.--[6] 90.--
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U[2] 110.--[2a] 110.--[7] 130.--
[2] 110.--[2a] 110.--[7] 130.--
110.-- [2]110.-- [2a]130.-- [7]
[3] 110.--[8] 130.--
110.-- [3]130.-- [8]
[4] 110.--[8] 130.--
110.-- [4]110.-- [7]130.-- [8]
110.-- [4]110.-- [7]130.-- [8]
[5] 110.--[7] 110.--[8] 130.--
80.-- [5]80.-- [6]90.-- [8]
30.-- [5]30.-- [6]40.-- [8]
15.17 [5]33.10 [6]
[5] 15.17
110.-- [5]
[6] 240.-- 206.90 [6]110.-- [6]130.-- [8]
[6] 110.--
15.17 [6] [6] 15.17
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
7. Aggregated posting of periodic bills from individual accounts, and the reversal of the unpaid aggregated posting for the second budget billing amount.
8. Money paid into the bank for the aggregated bill, service provider account cleared against the first budget billing payment. Bill receivables from individual accounts cleared using a distribution lot (created from payment advice note for the service provider, or from billing data).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-51
SAP AG 2003
Payment in a Deregulated Environment: Individual Reversal
Overview
Budget Billing Request and Payment
Periodic Billing and Invoicing
Individual Reversal
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-52
SAP AG 2003
Payment in a Deregulated Environment -Postings 9
FI
Tax account
Contract account customer 1
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U
[2] 110.--[2a] 110.--[7] 130.--
[3] 110.--[8] 130.--
110.-- [3]130.-- [8]
[4] 110.--[8] 130.--
110.-- [4]110.-- [7]130.-- 8]
110.-- [4]110.-- [7]130.-- [8]
30.-- [5]30.-- [6]40.-- [8]40.-- [9]
15.17 [5]33.10 [6]4.14 [9]
[5] 15.17[9] 4.14
110.-- [5]30.-- [9]
[6] 240.--[9] 30.--
206.90 [6]110,-- [6]130.-- [8]70.-- [9]
[6] 110.--
15.17 [6] [6] 15.17[9] 9.66
[1] 30.--[1a] 30.--[6] 40.--
110.-- [2]110.-- [2a]130.-- [7]
[5] 110.--[7] 110.--[8] 130.--
[1] 80.--[1a] 80.--[6] 90.--
80.-- [5]80.-- [6]90.-- [8]
[9] 60.34
[2] 110.--[2a] 110.--[7] 130.--
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
7. Aggregated posting of periodic bills from individual accounts, and the reversal of the unpaid aggregated posting for the second budget billing amount.
8. Money paid into the bank for the aggregated bill, service provider account cleared against the first budget billing payment. Bill receivables from individual accounts cleared using a distribution lot (created from payment advice note for the service provider, or from billing data).
9. The periodic bill for an individual account is reversed (budget billing amount 30.00 in the individual contract account represents a down payment again).
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-53
SAP AG 2003
Payment in a Deregulated Environment -Postings 10
FI
Tax account
Contract account customer 1
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U
[2] 110.--[2a] 110.--[7] 130.--
[3] 110.--[8] 130.--
110.-- [3]130.-- [8]
[4] 110.--[8] 130.--
110.-- [4]110.-- [7]130.-- [8]40.-- [10]
110.-- [4]110.-- [7]130.-- [8]40.-- [10]
30.-- [5]30.-- [6]40.-- [8]40.-- [9]
15.17 [5]33.10 [6]4.14 [9]
[5] 15.17[9] 4.14
110.-- [5]30.-- [9]
[6] 240.--[9] 30.--
206.90 [6]110.-- [6]130.-- [8]70.-- [9]
[6] 110.--
15.17 [6] [6] 15.17[9] 9.66
[1] 30.--[1a] 30.--[6] 40.--
110.-- [2]110.-- [2a]130.-- [7]
[5] 110.--[7] 110.--[8] 130.--[10] 40.--
[1] 80.--[1a] 80.--[6] 90.--
80.-- [5]80.-- [6]90.-- [8]
[9] 60.34
[2] 110.--[2a] 110.--[7] 130.--
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing). The second budget billing amount remains unpaid.
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
7. Aggregated posting of periodic bills from individual accounts, and the reversal of the unpaid aggregated posting for the second budget billing amount.
8. Money paid into the bank for the aggregated bill, service provider account cleared against the first budget billing payment. Bill receivables from individual accounts cleared using a distribution lot (created from payment advice note for the service provider, or from billing data).
9. The periodic bill for an individual account is reversed (budget billing amount 30.00 in the individual contract account represents a down payment again).
10. Aggregated posting creates a credit memo for the supplier account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-54
SAP AG 2003
Payment in a Deregulated Environment -Postings 11
FI
Tax account
Contract account customer 1
Receivables
Bank Bank clearing
Revenue
Tax clearing
Contract account customer 2
Contract accountSupplier
Supplier clearing
Clearing
Budget billing amounts received
IS-U
[2] 110.--[2a] 110.--[7] 130.--[11] 40.--
[3] 110.--[8] 130.--
110.-- [3]130.-- [8]40.-- [11]
[4] 110.--[8] 130.--[11b] 40.--
110.-- [4]110.-- [7]130.-- [8]40.-- [10]
110.-- [4]110.-- [7]130.-- [8]40.-- [10]
30.-- [5]30.-- [6]40.-- [8]40.-- [9]
15.17 [5]33.10 [6]4.14 [9]
[5] 15.17[9] 4.14
110.-- [5]30.-- [9]
[6] 240.--[9] 30.--[11a] 40.--
206.90 [6]110.-- [6]130.-- [8]70.-- [9]
[6] 110.--
15.17 [6] [6] 15.17[9] 9.66
[1] 30.--[1a] 30.--[6] 40.--[11a] 40.--
110.-- [2]110.-- [2a]130.-- [7]40.-- [11a]
[5] 110.--[7] 110.--[8] 130.--[10] 40.--
[1] 80.--[1a] 80.--[6] 90.--
80.-- [5]80.-- [6]90.-- [8]
[9] 60.34
[2] 110.--[2a] 110.--[7] 130.--[11] 40.--
40.-- [11b]
1. First budget billing request is posted (statistically) to the individual customer in IS-U. 1a. Second budget billing request is posted to the individual customer. 2. 2a Aggregated posting of budget billing amounts to service provider's (supplier's) contract account. 3. Money paid into the bank for the first budget billing amount. 4. Service provider account cleared with the first budget billing payment. 5. Budget billing amounts from individual accounts are cleared using the distribution lot (created from payment advice notes for the service provider or from billing).
6. Individual accounts are invoiced, paid budget billing amounts are transfer posted and unpaid budget billing amounts are reversed.
7. Aggregated posting of periodic bills from individual accounts, and the reversal of the unpaid aggregated posting for the second budget billing amount.
8. Money paid into the bank for the aggregated bill, service provider account cleared against the first budget billing payment. Bill receivables from individual accounts cleared using a distribution lot (created from payment advice note for the service provider, or from billing data).
9. The periodic bill for an individual account is reversed (budget billing amount 30.00 in the individual contract account represents a down payment again).
10. Aggregated posting creates a credit memo for the supplier account. 11. Credit payment for the supplier account is created. 11a. Payment posting is transferred to the individual account. 11b. Posting of outgoing payments from bank account.
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
© SAP AG IUT240 19-55
SAP AG 2003
Deregulation has made it necessary to adjust bill processing and payment processes to meet the requirements of the new deregulated processes.
Distributors bill with suppliers on the basis of individual account billing.
Clearing accounts are posted for the aggregated posting and complete processing of an incoming payment.
Payment with VV2: Summary
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly
Fo
r
in
te
rn
al
u
se
b
y
CS
C
on
ly