IUT240 Contract Accounts Receivable and Payable
IUT240
Contract Accounts Receivable and Payable
THE BEST-RUN BUSINESSES RUN SAP SAP AG 2003 SAP AG©2003
SAP IS-Utilities/Customer Care Service 472 2005/Q1 Material number: 50072720
Copyright
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.
SAP AG 2003
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
several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies
Prerequisites
Recommended: z IUT210: Master Data and Basic Functions z Basic knowledge of the Windows environment
SAP AG 2003
Target Group
z Participants
Project managers responsible for implementing contract accounts receivable and payable
The project team in charge of modeling the business processes
Administrators responsible for optimizing processes
Consultants preparing for implementation
z Duration: 5 days
SAP AG 2003
Course Objectives
This course enables you to: z Understand the concept of contract accounts receivable and payable z Describe the options for customizing customerspecific requirements z Know how to use the Contract Accounts Receivable and Payable component efficiently
SAP AG 2003
Course Overview
Contents: z Course goals z Course objectives z Course content z Course overview diagram z Main business scenario
SAP AG 2003
© SAP AG
IUT240
1-1
Course goals
This course will enable you to: z Get to know the conceptual characteristics of the component FI-CA Contract Accounts Receivable z Execute the basic business processes z Make the necessary settings for configuring FI-CA z Understand the integration of FI-CA with other R/3 components and web-based SAP applications
SAP AG 2003
© SAP AG
IUT240
1-2
Course Objectives
At the conclusion of this course, you will be able to: z Modify FI-CA business processes to meet your individual needs z Execute and check these business processes z Describe the integration with other components and applications
SAP AG 2003
© SAP AG
IUT240
1-3
Table of Contents IUT240
Preface Unit 1
Course overview
Unit 9
Clearing Control
Unit 2
Introduction
Unit 10
Dunning / Collections
Unit 3
Documents
Unit 11
Interest Calculation
Unit 4
Account Balance Display
Unit 12
Deferral / Installment Plan
Unit 5
Transactions and Account Determination
Unit 13
Other Business Transactions
Unit 14
Security Deposits
Unit 6
Payment Unit 15
Integration
Unit 7
Returns Processing Appendix
Industry-Specific Functions
Unit 8
Incoming Payments/ Clarification Processing
SAP AG 2003
© SAP AG
IUT240
1-4
Overview Diagram IUT240 Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
1-5
Main Business Scenario
z The accounts receivable accounting department in your company has to process a large amount of postings. z All business processes, such as payment processing, dunning notices, collection transfers and interest calculation must be executed as efficiently and correctly as possible. z The subledger also has to be transferred to the general ledger.
SAP AG 2003
© SAP AG
IUT240
1-6
Introduction
This unit will provide you with an overview of the following technical specifications in the subledger accounting component: Contract accounts receivable and payable: z The life cycle of an open item z Accounting transactions z Master data z Customizing
SAP AG 2003
© SAP AG
IUT240
2-1
Introduction: Objectives
At the conclusion of this unit, you will be able to: z Understand the objects involved in contract accounts receivable and payable z Understand the most important functions z Define the basic system settings z Understand the special features of the technical concept
SAP AG 2003
© SAP AG
IUT240
2-2
Introduction: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
2-3
Introduction: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
2-4
Invoicing
Account display
OI (not due)
-
OI (due)
- Item (cleared)
Time
General Ledger
The Life Cycle of an Open Item (1)
Archiving
SAP AG 2003
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.
© SAP AG
IUT240
2-5
The Life Cycle of an Open Item (2)
Invoicing
Account display
OI (not due)
-
OI (due)
- Item (cleared)
Time
General Ledger
Payment (Cash or Direct Debit)
Archiving
SAP AG 2003
Payments are initiated either by the business partner (cash payer) or via payment runs (direct debit). Payments usually clear open items.
© SAP AG
IUT240
2-6
The Life Cycle of an Open Item (3)
-
Source open item/charges
OI (not due)
OI (due)
- Item (cleared)
Time
Source open item
Invoicing
Account display
General Ledger
Payment (Cash or Direct Debit)
Archiving
Returns SAP AG 2003
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.
© SAP AG
IUT240
2-7
The Life Cycle of an Open Item (4)
-
Charges
Source open item/charges
OI (not due)
OI (due)
- Item (cleared)
Time
Source open item
Invoicing
Account display
General Ledger
Payment (Cash or Direct Debit)
Dunning Archiving
Returns SAP AG 2003
Overdue items for cash payers or blocked items from direct debit payers can be dunned. Dunning charges or interest on arrears can be posted.
© SAP AG
IUT240
2-8
The Life Cycle of an Open Item (5)
-
interest
Charges
Source open item/charges
OI (not due)
Interest Calculation
OI (due)
- Item (cleared)
Time
Source open item
Invoicing
Account display
General Ledger
Payment (Cash or Direct Debit)
Dunning
Archiving
Returns SAP AG 2003
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.
© SAP AG
IUT240
2-9
The Life Cycle of an Open Item (6)
-
OI (due)
interest
Charges
New due date
Source open item/charges
OI (not due)
- Item (cleared)
Time
Source open item
Invoicing
Account display
General Ledger
Payment (Cash or Direct Debit)
Interest Calculation Dunning Archiving
Deferral Returns SAP AG 2003
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.
© SAP AG
IUT240
2-10
The Life Cycle of an Open Item (7)
-
OI (due)
Several OIs
interest
Charges
New due date
Source open item/charges
OI (not due)
- Item (cleared)
Time
Source open item
Invoicing
Account display
General Ledger
Payment (Cash or Direct Debit)
Inst. plan Interest Calculation Dunning
Archiving
Deferral Returns SAP AG 2003
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.
© SAP AG
IUT240
2-11
The Life Cycle of an Open Item (8)
-
OI (due)
Several OIs
interest
Charges
New due date
Source open item/charges
OI (not due)
Inst. plan Interest calculation
- Item (cleared)
Source open item
Invoicing
Account display
Time
General Ledger
Payment (Cash or Direct Debit)
Doubtful flags Indiv. value adj. Write off
Dunning Archiving
Deferral Returns SAP AG 2003
Overdue items can be entered as doubtful, adjusted individually or written off.
© SAP AG
IUT240
2-12
The Life Cycle of an Open Item (9)
-
OI (due)
Several OIs
interest
Charges
New due date
Source open item/charges
OI (not due)
- Item (cleared)
Source open item
Invoicing
Account display
inst. plan
Time
General Ledger
Payment (Cash or Direct Debit)
Doubtful flags Indiv. value adj. Write off
Interest calculation Submit to coll. agency
Dunning
Archiving
Deferral Returns SAP AG 2003
Items can be submitted to external collection agencies.
© SAP AG
IUT240
2-13
Why Contract Accounts Receivable and Payable as the Subledger? 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 SAP AG 2003
© SAP AG
IUT240
2-14
Applications for Contract Accounts Receivable and Payable Current applications z Utilities (IS-U) z Insurance (IS-IS-CD) z Telecommunications (IS-T) z Waste disposal (IS-Waste) z Media (IS-M) z Public services and authorities (Public Sector)
z Non-industry based FI-CA (FI-CAX)
SAP AG 2003
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
© SAP AG
IUT240
2-15
Central Objects z Business partner
Account
Electricity
Contains 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
z Contract account
Contains 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)
z Contract (division-specific) z Document (items)
BP Account
FI-CA Account
Contract Contract Contract
IS-U SAP AG 2003
© SAP AG
IUT240
2-16
Elements of the Customer Profile
Payment terms Creditworthiness
Clearing category
(automatic/manual)
Interest key
Dunning procedure Account class
Account determination ID
Tolerance group
SAP AG 2003
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.
© SAP AG
IUT240
2-17
Company Codes in the Contract Account
Different entities in FI-CA ¾ Company code group Contains all company codes that can be used to post items to a contract account ¾ Standard company code 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
¾ Paying company code A paying company code is allocated to a company code group. It is responsible for payment processing SAP AG 2003
© SAP AG
IUT240
2-18
Terms of Payment
Contract account creditworthiness
Payment Payment terms terms
(automatic/manual)
Payment term: CA01
Interest key Dunning procedure
Account determination characteristic
Account class Tolerance group
FI-CA terms of payment CA01 Receivables Credit memos
FI terms of payment
: FI01
FI01 Payment term 1
: FI02
FI02 Payment term 2
SAP AG 2003
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.
© SAP AG
IUT240
2-19
Creditworthiness 1
Dunning notices
Write offs
[ ∑ (Dunning * Weighting) + ∑ (Returns * Weighting) + ∑ (Write-offs * Weighting) + ∑ (Manual entry * Weighting) + ∑ Device locks IS-U] * credit worthiness factor / business partner
Manual points
Dunning activities
+ =
Automatic Creditworthiness
Returns activities
Device locks IS-U Returns
Manual entries
Influencing factors
Effects
SAP AG 2003
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.
© SAP AG
IUT240
2-20
Creditworthiness 2 Creditworthiness
Edit
Goto
Business Partner Man. Creditworthiness Creditw.Factor Creditworthiness Date
Extras
Display Business Partner's Creditworthiness System Help
4711 Fixed Creditworthiness Date of Fixing Release Date
100 75 04.01.2003
Creditworthiness records
Year JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC 2003 2002 .....
0 0
5 0
15 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
Creditworthiness history
Year
Number
2003 2003 2003 .....
2 1 1
Origin Reminder Reminder Ret. paym.
Date 03/17/03 03/03/03 02/17/03
Creditw 10 5 5
Cont. acct.
Revers.
1000045 1000045 1000044
SAP AG 2003
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
© SAP AG
IUT240
2-21
Lock Concept
Account
Calendar
Posting lock
Account
Calendar
OI
Dunning
Account
Calendar
OI
Interest Calculation
Account
Calendar
OI
Payment run
SAP AG 2003
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.
© SAP AG
IUT240
2-22
Basic Customizing
IMG Financial Accounting -> Contract Accounts Receivable and Payable Organizational Units Set Up Company Codes for Contract Accounts Receivable and Payable Define Company Code Groups Assign Company Codes to Company Code Groups Basic Functions Application Area Contract Accounts Define Account Determination Characteristics Postings and Documents Document Maintain Payment Terms Open Item Management Maintain Tolerance Groups SAP AG 2003
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".
© SAP AG
IUT240
2-23
Technology: Event Concept (1) FI-CA program (Event)
CustomerSpecific
Allows flexibility without modifying SAP programs Yes
No Industryspecific
Yes
No Standard program
IS program
Customer program
FI-CA program (Continuation) SAP AG 2003
© SAP AG
IUT240
2-24
Technology: Event Concept (2) SAPxxxxx program. ... event 2000 ... ... event 0350 ... ... event 0260 ... ... ...
TFKFBM Standard functionality Event
Text
ABAP/4 modules
2000 Interest key determ. FKK_SAMPLE_2000 ... ... ... TFKFBS Industry...functionality ... ... ... Event ... Text ... ABAP/4 modules ... ... ... 0350 Dunning Activities ISU_0350 ... ... ... TFKFBC functionality ... Customer ... ... ... ... Event ... Text ABAP/4 modules ... ... ... ... ... ... ... ... ... 0260 Return charges FCS_0260 ... ... ... ... ... ...
SAP AG 2003
Events can be managed using transaction FQEVENTS.
© SAP AG
IUT240
2-25
Technology: Mass Processes in FI-CA Indicators of large data volumes: z Payment run z Mass calculation of interest z Dunning notices z Correspondence print z Generation of bills Target: Processing time can only be reduced if processes are split up
Parallel processing of the dataset SAP AG 2003
© SAP AG
IUT240
2-26
Technology: Splitting-Up Processes
End of runtime Not in parallel
Job 1
Business Business partner: partner: From From 100,000 100,000 to to 699,999 699,999
Job 1
Parallel runs
Business Business partner: partner: From From 100,000 100,000 to to 349,999 349,999
Job 1-3 end at nearly the same time
Job 2
Business Business partner: partner: From From 350,000 350,000 to to 401,000 401,000
Job 3
Interval separation is supported by the system
Business Business partner: partner: From From 400,001 400,001 to to 699,999 699,999
Runtime Runtime SAP AG 2003
© SAP AG
IUT240
2-27
Technology: Parallel Processing - Interval Creation
Interval_1
Interval size = 3
Interval_3
Interval number = 4
Interval_2
BP_1 BP_3
BP_4
BP_9
BP_5
Interval size = 4 Interval_1
Interval_4
BP_20
BP_40 BP_30
BP_19
BP_21
BP_35
BP_31
Interval_2 Interval_3
Interval number = 3
SAP AG 2003
© SAP AG
IUT240
2-28
Technology: Parallel Processing - Portioning z 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.
SAP AG 2003
© SAP AG
IUT240
2-29
Technology: Parallel Processing - Realization
Dispatcher for mass data program
Server A Job 1
Interval 1
m OIs
Interval 4
m OIs
m OIs
Server A Job 2
Interval 9
Interval 3
...
Interval 6
Server X Job n
Interval 2
Interval 10
...
m = Block value SAP AG 2003
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.
© SAP AG
IUT240
2-30
Introduction: Summary z Contract accounts receivable and payable is a subledger accounting component that manages mass data. z It is used for processing open items. z The business partner and the contract account are the required master data. z Open items are managed as documents. z Contracts are realized in industry solutions. z Event management enables you to integrate customer-specific requirements into the SAP System without modifying SAP programs. z Parallel processes drastically reduce the runtimes of mass runs such as payment or dunning processing. SAP AG 2003
© SAP AG
IUT240
2-31
Documents
Contents: Document types and number ranges Document structures Posting documents Clearing documents Integration with General Ledger accounting Customizing
SAP AG 2003
© SAP AG
IUT240
3-1
Documents: Overview
This unit will provide you with an overview of the following in FI-CA: 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
SAP AG 2003
© SAP AG
IUT240
3-2
Documents: Unit Objectives
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
SAP AG 2003
© SAP AG
IUT240
3-3
Documents: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
3-4
Documents: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
3-5
Documents: Document types and Number Ranges
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-6
Document Types for Single Processing
Document types Description
NR
B1
Receivable
01
Z2
Incoming payment
20
V3
Consumption billing 31
Z4
Payment
66
R5
Repayment
76
...
...
Number range
Ext.
010000000000 - 019999999999 200000000000 - 209999999999 310000000000 - 399999999999 660000000000 - 699999999999 760000000000 - 769999999999
. . .
SAP AG 2003
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.
© SAP AG
IUT240
3-7
Number Ranges for Mass Processing
Doc. type V3
NR Individual 31 NR Mass F1 F2 F3 ...
Number ranges
Ext.
31 310000000000 to 3199999999 35 350000000000 to 3599999999 36 360000000000 to 3699999999 .... F1 320000000000 to 3299999999 F2 330000000000 to 3399999999 F3 340000000000 to 3499999999 ....
NR Individual 35 36 ... SAP AG 2003
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.
© SAP AG
IUT240
3-8
Documents: Document Structures
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-9
Structure of a FI-CA Document (1) Document header Doc. number: 010023459101 Posting date: 02/22/2003 Doc. type: F1 Currency: USD Reconciliation key: 03032701/SK1
1 : n
010023459101
1 : n
General ledger items
Business partner items
BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 0100-0011 232.00 010023459101
Item 0001
CCODE U100 U100
G/L Acc. BA Cost Cent. Amount 800000 200.00 175000 32.00
010023459101
SAP AG 2003
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.
© SAP AG
IUT240
3-10
Structure of a FI-CA Document (2) Repetition item
Document header Document number: Posting date: Doc. type: F1 Reconciliation key:
010000234591 01/03/03 Currency: USD 03032701/SK1
Due: 01/03/2003 Due: 02/03/03 Due: 03/03/03
1:n
010000234591
1 : n
1
:
Repetition group 010000234591 Repetition item
n
Business partner items BPART CCODE Due Date Trans. Amount 4711 U100 03/01/03 0080-0011 116.00
010000234591
Item 0001
01 03
General ledger items CCODE G/L Acc. BA Cost Cent. Amount U100 800000 100.00 U100 175000 16.00 010000234591
SAP AG 2003
Repetition documents are put into repetition groups. Budget billing plans and installment plans are represented in IS-U as documents with repetition groups.
© SAP AG
IUT240
3-11
Structure of a Payment Document Source receivable Doc. number: Posting date: Doc. type: F1 Reconciliation key:
Payment Doc.number: Posting date: Doc. type: Z2 Reconcil. key:
010023459101 02/22/2003 Currency: USD 03032701/SK1
012204445552 03/05/03 Currency: USD ZE0503200302
012204445552 010023459101
Business partner item BPART CCODE DueDate Trans. Amount 4711 U100 02/22/03 0100-0011 232.00
010023459101
Item 0001
012204445552
Bank offsetting item
General ledger item CCODE U100 U100
G/L Acc. BA Cost Cent. Amount 800000 200.00 175000 32.00
CCODE U100
G/L Acc. BA Cost Cent. Amount 113100 232.00
012204445552
010023459101
Item 0001
SAP AG 2003
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.
© SAP AG
IUT240
3-12
Document Structure for Partial Payments Source receivable
Payment
Doc. number: 010023459101 Posting date: 02/22/03 Doc. type: F1 Currency: USD Reconciliation key: 03032701/SK1
Doc.number: Posting date: Doc. type: Z2 Reconcil. key:
010023459101
012204445552 03/05/03 Currency: USD ZE0503200102
012204445552
Business partner item Subitem BPART CCODE Due Date Amount 0 4711 U100 02/22/03 132.00 Subitem BPART CCODE Due Date Amount 1 4711 U100 02/22/03 100.00 Cl. doc 012204445552
Cl. date 03/05/2003
010023459101
Item 0001
Cl. amount 100.00
Offsetting item
Bank offsetting item
Item CCODE G/L Acct. Cost center Amount 0001 U100 800000 200.00 0002 U100 175000 32.00 010023459101
CCODE G/L Acc. BA Cost Cent. Amount 100.00 U100 113100 012204445552
Item 0001
Item 0001
SAP AG 2003
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.
© SAP AG
IUT240
3-13
Structure of a Statistical Document
Statistical receivable Doc.number: Posting date: Doc. type: F1 Reconciliation key:
010000234001 02/22/2003 Currency: USD 03032702/SK1
Only business partner items exist
010000234001
Statistical business partner item BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 0100-0011 10.00
010000234001
Item 0001
SAP AG 2003
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.
© SAP AG
IUT240
3-14
Payment for Statistical Items
Source receivable
Payment
Doc.number: Posting date: Doc. type: F1 Reconciliation key:
Doc.number: Posting date: Doc. type: Z2 Reconcil. key: Clearing info:
010000234001 02/22/2003 Currency: USD 03032702/SK1
Business partner item (before payment) Item BPART 0001 4711
Business partner item
Trans. Stat. key Amount 0010-0010 G 10.00
Business partner item (after payment) Item BPART 0001 4711
Trans. Stat. key Amount 0010-0010 G 10.00
Cl. doc Cl. date 012204445553 03/05/2003
012204445553 03/05/03 Currency: USD ZE0503200102 "Real items also cleared"
Cl. amount 10.00
Item BPART 0001 4711 Cl. doc 012204445553
Trans. Stat. key Amount 0010-0020 10.00 Cl. date 03/05/2003
Cl. amount 10.00
Offsetting items Item 0001 0002
CCODE G/L Account U100 113100 U100 800000
Amount 10.00 -10.00
Cleared items
Customizing Stat. key MTR STR => MTR STR Restr. G 0010 0010 0010 0020
Item 0001 0002
CCODE U100 U100
BPART 4711 4711
Amount 10.00 10.00
SAP AG 2003
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.
© SAP AG
IUT240
3-15
Documents:Posting documents
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-16
Goals of Document Entry
Fast entry of posting information Variable entry format Flexible, screen customizing Clear representation Integration of clearing logic No restrictions on posting logic
SAP AG 2003
© SAP AG
IUT240
3-17
Post Document: Entry Point
Posting date: 02/23/2003 Document type: 01 Currency: USD Document date: 02/23/03 Reconciliation key: 03033101/SK1 Screen Variant RECHNUNG Company code U100 Line layout: Business partner item: General ledger item: Tax: Manual entry Calculate automatically
SAP SAP Jurisdiction code Net receivables
Calculate automatically: Taxes are determined from the business partner item
Items
SAP AG 2003
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.
© SAP AG
IUT240
3-18
List Entry: Business Partner Items
Header data Document date: 02/23/03 Posting date: 02/23/03
Document type: Currency:
01 USD
Business partner items BPART CCODE Net due date CACCT Mtrans 1740
U100
03/23/03
634
6000
STrans Amount Contract 0020
232.00
531
...
Line layout o SAP Standard o ZAP line layout with text SAP AG 2003
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.
© SAP AG
IUT240
3-19
Tolerance Groups for Amount Limits Document header
Customizing:
Doc.number: 010000234592 Posting date: 02/22/2003 Doc. type: F1 Currency: USD Reconciliation key: 03033101/SK1
Tolerance group Company code Currency:
CA01 U100 USD
Upper limit for posting: Max. amount per document: 1000.00 Max. amount per item: 600.00
Business partner items Item 0001 BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 6000-0020 600.00
Amount check Item level 599.00 < 600.00 o.k.
Item 0002 BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 6000-0020 500.00
Document level
500.00 < 600.00 o.k.
599.00 + 500.00 1099.00
Posting not possible because amount limit exceeded SAP AG 2003
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.
© SAP AG
IUT240
3-20
Posting: Foreign Currency 100.00 USD
Specification of exchange rate
Determination of exchange rate
Amount in local currency
92.00 USD SAP AG 2003
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.
© SAP AG
IUT240
3-21
Cross-Company Code Posting
Business partner 4711 Contract account 1234
Payment - in CCODE U100 for: Contract 2 - CCODE U200
50.00 USD
Contract 1 - CCODE U100
-100.00 USD
Bank clearing in U100
(3a) 100.00
(2) 150.00
(3b) 50.00 Receivable Water
Contract 1 in CCODE U100
Contract 2 in CCODE U200
Payables for CCODE U200
(1) 100.00 100 (3a)
Receivable Waste Water
(1) 50.00
50 (3b)
50.00 (4)
Receivable for CCODE U100
(4) 50.00
SAP AG 2003
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.
© SAP AG
IUT240
3-22
Post Document: Additional Functions
Document header
DT blocked for manual posting
Doc. type: FA
Change / Display
010000234593
1 : n Business partner items
Alternative G/L account Alternative account
BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 6000-0020 232.00
X
Non-periodic posting
Billing period 010000234593
Expense Revenue
01/05/02 Item 0001
Alternative VAT determination
SAP AG 2003
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).
© SAP AG
IUT240
3-23
Documents: Clearing Documents
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-24
Clearing: Generation of Line Items
Charges receivable Clearing statistical charges Minor differences Write-off
Cash Discount Expense/Revenue
Tax after cash discount
clearing document
Exchange rate difference Foreign currencies
Down payment
SAP AG 2003
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.
© SAP AG
IUT240
3-25
Clearing: Different Currency
Source receivable
Payment
Document number: 010000234591 Posting date: 02/22/03
Doc.number: Posting date:
Doc. type: FA
Doc. type: Z2
Currency: EUR
012204445552 03/05/03 Currency: USD
012204445552
010000234591
SAP AG 2003
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.
© SAP AG
IUT240
3-26
Document Overview Header
Business partner item
General ledger item
Header data Document date: 02/23/03 Posting date: 02/23/03 Document no.: 123456789
Document type: Currency:
F1 USD
Summarized business partner items: CCODE Partner CACCT Contract MTrans STrans DueDate Amount U100 1740 634 531 6000 0020 02/22/03 232.00
Summarized general ledger items CCODE U100 U100
General Ledger Long Text 800000 Other receivables 175000 Tax 16%
Amount 200.00 32.00
SAP AG 2003
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.
© SAP AG
IUT240
3-27
Documents: Integration with General Ledger Accounting
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-28
Integration with FI General Ledger: Definitions Reconciliation key Key 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
Summary Records "Transfer unit" for postings from sub-ledger to general ledger accounting The documents from sub-ledger accounting are consolidated into summary records Summarization criteria include: Posting date Account assignment data (G/L account, cost center ...) SAP AG 2003
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.
© SAP AG
IUT240
3-29
Reconciliation Key Structures - Automatic Determination Lot (payment or returns lot) XXXXXXXXXXXX
Default: lot name
Payment run YY DDD NNNNN PP
03 101 PAY01 01
(PAY01: Na
03 101 INT01 01
(INT01: Name
03 101 R04 0003
(R04: fixed source)
Interest run YY DDD NNNNN PP
IS-U Invoicing YY DDD HHH LLL
YY/DDD = Year/day in year
LLLL = Run ID
SSS
PP
= Source
= Number of process
NNNNN = Name
SAP AG 2003
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.
© SAP AG
IUT240
3-30
Tools: Reconciliation Keys Mass closing User (group) dependent reconciliation key
SD010205 08-010803-05 11-010602-01 TK050201 TK050201 ...
Source: Yes/no? Event: 1113 03031101/SK1 Delete
Close
Itemization for gen. ledger documents Reconciliation key: 03031101/SK1 OI 4711 - BP1 - USD 2500.00 OI 4713 - BP2 - USD 800.00 OI 4811 - BP3 - USD 760.00 ... SAP AG 2003
The reconciliation key can be can be structured user (group) specifically for online postings. Userdependent 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.
© SAP AG
IUT240
3-31
FI-CA Document - Summary Record - FI Document
FI-CA Documents Reconciliation key 03040101/SK1 Doc. 12 Amount 116.00 Doc. 13 Amount 232.00
Post document
FI documents Reference key 03040101/SK1* Reference transaction FKKSU
Summary Records Reconciliation key 03040101/SK1 140000
D
348
800000 175000
C C
300 48
Transfer Reconciliation key
40
140000
348.00
50
800000
300.00
50
175000
48.00
SAP AG 2003
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)
© SAP AG
IUT240
3-32
Reference Documents: FI-CA - Summary - FI Document
10004711
Recon. key. PDATE CCODE
03041001/SK1 04/10/03 U100
Partner Amount
Rev. account
800003
Document
10004712
Recon. key. PDATE CCODE
Document
99000123 200.00 USD
03041001/SK1 04/10/03 U100
Partner Amount
99001148 300 USD
Rev. account
800003
Document
Recon. key. PDATE CCODE
10004713
03041001/SK1 04/11/03 U100
Partner Amount
99000129 600 USD
Rev. account
800003
Reference key: 03041001/SK1*
Reference key 03041001/SK1 PDATE 04/10/03 D 500.00 USD 140101 C 500.00 USD 800003 PDATE D 600 USD C 600 USD
120001234
04/11/03 140101 800003
PDATE 04/10/03 40 140101 500.00 50 800003 500.00 Document
120001235
Reference key: 03041001/SK1 * PDATE 04/11/03 40 140101 600.00 50 800003 600.00
SAP AG 2003
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.
© SAP AG
IUT240
3-33
Reconciliation: FI-CA with the General Ledger Docs. Subledger
Reconciliation Key
Docs. General Ledger
Σ RFKKGL00
RFKKABS1
Reconciliation
Transfer
RFKKGL20 RFKKOP04
Reconciliation
Open item list SAP AG 2003
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.
© SAP AG
IUT240
3-34
Reconciliation: General Ledger Documents FI-CA Documents
General ledger accounts
RFKKGL30
12/00 12/00 12/00 2/2003
Itemization for general ledger docs Reconciliation key: 03021101/SK1 OI 4711 - BP1 - USD 2500.00 OI 4713 - BP2 - USD 800.00 OI 4811 - BP3 - USD 760.00 ...
Balance/ Posting period
Reconciliation key
Σ
FI documents 12/00 12/00 12/00 2/2003
SAP AG 2003
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.
© SAP AG
IUT240
3-35
Reconciliation: Open Items
Balances Open items FI-CA
Balances Reconciliation key
+
Σ
Balances Reconciliation accounts
Not yet transferred
RFKKOP10
SAP AG 2003
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.
© SAP AG
IUT240
3-36
Documents: Customizing
Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing SAP AG 2003
© SAP AG
IUT240
3-37
Documents: Customizing (1)
IMG Contract Accounts Receivable and Payable Basic Functions Postings and Documents Basic Settings Maintain Central Settings for Posting Maintain User-Specific Posting Settings Maintain Document Number Ranges Document Maintain Document Assignments Maintain Document Types and Assign Number Ranges Maintain Default Document Types for..... Screen Preparations Select Fields to be Hidden (at client level) Define Screen Variants for Document Posting Select Screens to be Hidden for Screen Variants
... SAP AG 2003
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.
© SAP AG
IUT240
3-38
Documents: Customizing (2)
IMG Contract Accounts Receivable and Payable ... Include own Fields in Detail Screens Define Screen Variant for List Entry of Business Partner Items Define Screen Variant for List Entry of General Ledger Items Define Default Values Define Default Values for Document Entry Maintain Rules for Reconciliation Key Default Values Maintain Reconciliation Groups for Default Values
... Integration General Ledger Accounting Define Posting Specifications for General Ledger Transfer
SAP AG 2003
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).
© SAP AG
IUT240
3-39
Documents: Summary (1)
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.
SAP AG 2003
© SAP AG
IUT240
3-40
Documents: Summary (2)
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.
SAP AG 2003
© SAP AG
IUT240
3-41
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
© SAP AG
IUT240
3-42
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##)
© SAP AG
IUT240
3-43
Company code: List category: Line layout:
1-5
U100 (U300) All items Standard line layout – account display
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: Test run: List of layouted FI documents:
1-6
Proposed by system SPACE X
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? ____________________________________ _______________________________________________________________
© SAP AG
IUT240
3-44
© SAP AG
IUT240
3-45
Documents: Solutions
1-1
Unit:
Documents
Topic:
Entering Documents in the System
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.
© SAP AG
IUT240
3-46
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
© SAP AG
IUT240
3-47
1-7
Choose: Accounting Financial Accounting Display Document List
General Ledger
Document
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.
© SAP AG
IUT240
3-48
Account Balance Display
Contents: z Structure of the account balance display z Display and navigation options z Customizing
SAP AG 2003
© SAP AG
IUT240
4-1
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.: z The structure z The entry criteria z The functions and flexibility z Customizing
SAP AG 2003
© SAP AG
IUT240
4-2
Account Balance Display: Objectives
At the conclusion of this unit, you will be able to: z Analyze the contract accounts of business partners using the account balance display z Design your own line layout variants for effective use of the account balance display
SAP AG 2003
© SAP AG
IUT240
4-3
Account Balance Display: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
4-4
Account Balance Display: Business Scenario
z 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.
SAP AG 2003
© SAP AG
IUT240
4-5
Account Balance Display: Structure of Account Balance Display
Structure of Account Balance Display Display Options
Customizing
SAP AG 2003
© SAP AG
IUT240
4-6
Tasks of Account Balance Display
z Fast selection of individual items z Flexible, configurable display z User-specific views (agent, accountant, ...)
z Clear display z Can be called from other transactions (with selection criteria)
SAP AG 2003
© SAP AG
IUT240
4-7
Account Balance Display: Entry Business partner
Account balance role
Contract account Contract Company code Further Details Inst. plan
All items Open items Cleared items
Collective bill Reference
Statistical items (all/budget billing plan/charges/ ...)
List Type User-specific selection With archive Only due/partially paid budget billing amounts Line layout Sort Variant Initial screen SAP AG 2003
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,
© SAP AG
IUT240
4-8
Account Balance Display: List Type List Type
Selection of items
Statistical items All
Open items Cleared items
*)
Number of requests Charges Receivable
With postings of other partners
Budget billing plan
Non-statistical items
Installment plan Collective bill
Document category
Req. for cash security deposit
Standard items Original items for installment plans
.... *) Not used in IS-U / IS-T.
SAP AG 2003
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.
© SAP AG
IUT240
4-9
Account Balance Display: Line Display
Line layout
Sorting variant
Standard
Due date + amount
Traffic light
Due date
Document number
Amount in local currency
Main transaction Subtransaction Due date Amount Clearing document Attribute "decreasing"
SAP AG 2003
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.
© SAP AG
IUT240
4-10
Account Balance Display: Totals Variants Line layout for totals variant
Business partner Contract accounts Document number
D e t a i l
Level 1 Level 2 Level 3
Line item
Level 4
SAP AG 2003
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.
© SAP AG
IUT240
4-11
Account Balance Display: Structure of Totals Variant SAP Reference IMG Table view Edit Goto Selection Utilities System Help
Dialog structure
List class
M
Variants Fields of a V
Line layout
S03
Totals variant document
Text **** B partner Cont. acct
Document no. Due date Debit amount Credit am
A__B_______ C_________ D___________ E_______ F_________ G________ ount Still open Total amount S C Dl ____ H______________ I________________ J K L_ M Variant Fields E AMPEL C VKONT
B GPART D OPBEL
E FAEDN G HBTRW
F SBTRW H OBETH
I LBTRW K XZAHL
J STAKZ L MAHNS
M CNTPO
SAP AG 2003
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.
© SAP AG
IUT240
4-12
Account Balance Display: Display Options
Structure of Account Balance Display Display Options
Customizing
SAP AG 2003
© SAP AG
IUT240
4-13
Navigation & Functions I Business partners
Item Selection
Contract account
Item Display
Contract
Environment and settings
Item sorting
Totals
Send account information
Send payment form
Additional Fields Without reversals
Bill print document
SAP AG 2003
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.
© SAP AG
IUT240
4-14
Navigation & Functions II Mass change Account maintenance
Blocks
Installment plans
Creditworthiness
Security Deposits
Budget billing plans
Account
Dunning notices Installment plan history
Returns Submit for collection
Corrections Write-offs SAP AG 2003
© SAP AG
IUT240
4-15
Navigation & Functions III
Bank data
Document change
(Payment run, payment lot, returns)
Clearing reversal
Payment usage
Interest supplement
Document
Line item bundling
Budget billing plan
© SAP AG
Source receivables installment plan Line item Collective bill
Histories
SAP AG 2003
Document reversal
Cash security deposits
IUT240
4-16
Account Balance Display - Example Account Status
Edit
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
Goto
Account Status: Basic List Extras Environment System
001 Down paym.
**** Contr. acc.
Doc. no.
Total
Payment list
Transaction
Chronology
Due date
Amount 100.00
1000000
100001673
Incom. payment
04/28/03
1000000 100001673
100001671
Other receiv.
04/24/03
1000000
Receivables
Help
ISU Account Balance Display: Standard Display
Variants Receivables
Settings
100001671
Other receiv.
04/24/03
USD
Still open
DL Clearing doc 100001673
100.00 50.00
50.00
50.00
50.00
SAP AG 2003
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.
© SAP AG
IUT240
4-17
Account Balance Display - Example Account Status
Edit
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
Goto
Account Status: Basic List Extras Environment System
Help
ISU Account Balance Display: Standard Display
Variants Receivables
Settings
001 Down paym.
Totals
Payment list
Chronology
Business partner 000004711 Contract account 000001000000 USD
Total
Due
Receivables BB plan Down pay. req. CSD request Charges/inter. Quotations PoA/credit Payment req.
50.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
50.00
Inst. plan items Total
1237.47 1237.47
237.47 237.47
Down paym. CSD payment
0.00 0.00
SAP AG 2003
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.
© SAP AG
IUT240
4-18
Account Balance Display: Payment 1 Account Status
Edit
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
Goto
Account Status: Basic List Extras Environment System
Help
ISU Account Balance Display: Standard Display
Variants Receivables
Settings
001 Down paym.
Compressed
Total
Payment list
Chronology
Detailed
10000167324.10.00 man. check payment
100.00 USD
Cleared items (according to selection) 1000000
100001671
Other receiv.
04/24/03
100.00
100001673
General ledger items $ 100
U300 113100
Bank1 (check rec.)
100.00 USD
SAP AG 2003
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
© SAP AG
IUT240
4-19
Account Balance Display: Payment 2 Account Status: Basic List
Account Status
Edit
Goto
0000004711 / U300 ISU Claire Clemens 123 Main Street New York, NY 10101 Variants Receivables
Settings
... Payment usage
...
CTRL+F8
Down Payment paym. usage Total list Chronology / ClearingPayment analysis for document 100001673 Man. Check payment
Doc. no.
Clerk
Transaction
Amounts in USD
1000000
100001673
1000000
Pmnt
100001671 100001671
04/28/03 10:40:43
Due date
Amount
Amount Doc. No. Partner/Contract Acct Incom.Open payment 10/24/2000 100.00 100.00
Other receiv.
Bill PPmnt 100.00
Receivables
Environment System Help
001
**** Contr. acc.
1000000
Extras
Document Account Balance Display: Standard Display Payment data
50.00
Other receiv.
100001673
24.10.00
Still open Text
DL Clearing doc 100001673
100.00
100001673
100001671 TD- 005/000001000000
24.10.00
USD
50.00
50.00
50.00
50.00
SAP AG 2003
Payment usage shows the item cleared by a payment.
© SAP AG
IUT240
4-20
Account Balance Display: Payment 3 Account Status: Basic List
Account Status
Edit
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
Goto
Environment System Help
Down paym. Doc. no.
Total
Payment list
Chronology
History of Clearing and Reversal
Business partner 000004711 Transaction Due date Amount
Contract Acct Still open
1000000 DL Clearing doc
Document no.
100001671
Posting date
04/28/03
Item
1
Repetition Item
0
Currency
USD
1000000
100001673
Incom. payment
10/24/2000
100.00
1000000
100001671
Other receiv.
24.10.00
100.00
1000000
Receivables SAP AG 2003
Dunning History Clearing history Interest history
001
**** Contr. acc.
Extras
Histories
Variants Receivables
Settings
Document ISU Account Balance Display: Standard … Display ...
100001671
Amount
150.00
Clearing/Reversal History
Clearing date Reversal post. Amount 50.00 100.00
Other receiv. 24.10.00 04/28/2003
USD
100001673 100001673
Curr. USD
50,00 50.00
Clearing amount
50.00
50,00 50.00
Chronology
The clearing history displays the details of clearings and clearing reversals.
© SAP AG
IUT240
4-21
Account Balance Display: Find Account Status: Basic List Account StatusEdit ... Find ...
Goto
Extras
System Help
F5
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
ISU Account Balance Display: Standard Display
Variants Receivables
Settings
3
001 Down paym.
**** Contr. acc.
Doc. no.
Total
1
Payment list
Transaction
Chronology
Due date
Amount
Still open
DL Clearing amt
1000000
100001677
Inst. plan request 12/27/2002
100.00-
100.00
R
1000000
100001677
Inst. plan request 01/25/2001 2
100.00
100.00
R
1000000
100001677
Inst. plan request
100.00
100.00
R
Receivables
02/26/2003
USD
300.00
300.00
SAP AG 2003
The search function is cursor-sensitive: y 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. y 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. y 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.
© SAP AG
IUT240
4-22
Account Balance Display: Totals Display Account Status
Edit
0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
Goto
Settings
S01 Down paym.
**** B-Partner 000004711
Help
IS-U Account Balance Display - Total by Business Partner
Variants Receivables
Account Status: Basic List Extras Environment System
Debit amt
Totals
S02 S03 S04 Payment list
Credit amt
Chronology
Still open
Total amount
795.00
355.00-
440.00
440.00
9
795.00
355.00-
440.00
440.00
9
SAP AG 2003
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.
© SAP AG
IUT240
4-23
Account Balance Display: Additional Fields Account Status
Edit
Goto
Settings
Account Status: Basic List Extras Environment System
Help
+ STUDT 0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101
ISU Account Balance Display: Standard Display
Variants Receivables
001 Down paym.
**** Cont. acct.
Totals
Payment list
Document no. Trans. text Deferral
Chronology
Due date
Amount 100.00
1000000
100001673
00.00.0000 Incom. payment
04/28/03
1000000
100001674
Other 15.01.2003 receiv.
04/24/03
Other00.00.0000 receiv.
04/24/03
1000000
Receivables
100001671
USD
300.00
Open amount
100001673 300.00 100001673
100.00
300.00
DL Clearing doc
300.00
SAP AG 2003
Any document field can be inserted in single item variants with + (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.
© SAP AG
IUT240
4-24
Account Balance Display: Events In the account balance display events, you can make different installation-specific changes/enhancements: 1200 1201 1203 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1217 1230
Account Balance: Set Header Data Account Balance: Display Contract Data Account Balance: Status Icons / Colors Account Balance: Supplement Data Account Balance: Name and Execute Additional Functions Account Balance: Output Header Data Account Balance: Output Address Data Account Balance: Key Account Balance: Add Selection Specifications Account Balance: Change Hit List and Totals Account Balance: Change Chronology Account Balance: Chronology - Modify Output Account Balance: Navigation - List of Contracts Account Balance: Overview of Budget Billing Plans Account Balance: Output Header Data (ALV) Account Balance Short Form: Add Data
SAP AG 2003
© SAP AG
IUT240
4-25
Account Balance Display: Customizing
Structure of Account Balance Display Display Options
Customizing
SAP AG 2003
© SAP AG
IUT240
4-26
Documents: Customizing (1)
IMG Contract Accounts Receivable and Payable Basic Functions Account Balance Display Define List Category Define Line Layout for Account Balance Display Maintain Sorting Variants Define Proposal for Line Layout Select Fields for Search Function Choose Fields for Selection Function Select Fields for Sort Function Select Additional Fields to be Displayed Define Account Balance Roles Assign Transactions for Account Balance Display Set Budget Billing Display
SAP AG 2003
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.
© SAP AG
IUT240
4-27
Account Balance Display: Summary
z All account transactions for a business partner can be viewed using the account balance display. z The display can be freely configured. z Various views are available for a contract account. z It is possible to branch from the account balance display to the account environment, for example to documents and master data.
SAP AG 2003
© SAP AG
IUT240
4-28
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. _______________________________________________________________ _______________________________________________________________
© SAP AG
IUT240
4-29
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? _______________________________________________________________
© SAP AG
IUT240
4-30
Account Balance Display: Solutions Unit: Account Balance Display Topic: Analysis of Contract Accounts
1
Account display
1-1
1-2
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance. List Type:
Standard: All open items
Line Layout:
Standard line layout – acc. display
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.
© SAP AG
IUT240
4-31
Transactions and Account Determination
This unit will enable you to understand: z The structure of the transactions z The determination of general ledger accounts z The tax determination process z The Customizing of your accounting transactions
SAP AG 2003
© SAP AG
IUT240
5-1
Transaction and Account Determination: Unit Objectives
At the conclusion of this unit, you will be able to: z Tell the difference between internal and external transactions z Tell the difference between main transactions and sub-transactions z Define the main and sub-transactions within contract accounts receivable and payable z Design the account determination for the business transactions z Explain the structure and processes of tax determination
SAP AG 2003
© SAP AG
IUT240
5-2
Transaction and Account Determination: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
5-3
Transaction and Account Determination: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
5-4
Transactions and Account Determination: Structure and Conception of Transactions
Structure and Concept of Transactions Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
SAP AG 2003
© SAP AG
IUT240
5-5
Transactions
Main transactions
Allocation to internal transactions
SAP
Internal Main transactions
Allocation SAP
Subtransactions Account Determination Tax determination Additional account assignment
Transactions Attributes - Debit/credit - Interest key - Statistical/non-statistical
Internal Subtransactions Default setting by SAP
Transactions describe the business transaction upon which the posting of a document line item is based SAP AG 2003
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.
© SAP AG
IUT240
5-6
Main Transactions Consumption billing Returns Final billing
Charges
Manual credit note/ Backbilling
Interest
Collective bill
Cash security deposits
Main Transaction Budget billing request
Interest on cash security deposit
Payment on account
Installment plan Other postings
Down payment SAP AG 2003
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.
© SAP AG
IUT240
5-7
Subtransactions Returns charges Receivable 1
Returns charges Stat. receivable 2
Main Transaction Returns
Returns charges Receivable 2
Returns charges Stat. receivable 1 SAP AG 2003
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 debitcredit 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).
© SAP AG
IUT240
5-8
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.
SAP AG 2003
The posing areas are broken down into the following areas: y Posting areas for all application areas (for example, posting area used to identify a tax account based on the tax code) y 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. y 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.
© SAP AG
IUT240
5-9
Freely Defined Transactions Transactions for Main transaction Subtransactions Incoming payments, outgoing payments, account display Incoming payment R010, T010, M010...
Clearing item transactions 1090, 1091
clearing reversal, ... Account maintenance, invoicing account Account maintenance maintenance, write-off
Main transaction Subtransactions Incoming payment
Payment on account
Reversal
Reversal from returns
Transactions for Main transaction Subtransactions Other receivables, other credit memos other postings Other receivables ...
...
Transactions for Main transaction Subtransactions SD billing docs Household connection: Receivable, credit memo 1200
Electricity Subsidiary xyz
Receivable, credit memo
SAP AG 2003
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.
© SAP AG
IUT240
5-10
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. SAP AG 2003
Examples: y Customer-specific transactions: Other receivables for manual postings (6000 / 0020 in the training system) do not correspond to internal transactions. y 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. y 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.
© SAP AG
IUT240
5-11
Sub-Transactions in IS-U: Billing / Invoicing ⇒ Allocation to internal invoicing transactions / no account determination FI-CA Document
Receivable: Periodic bill
Credit memo: Periodic bill
Cumulative transactions
Receivable: Energy charge
FI-CA Document
Credit memo: Energy charge
Receivable: Service charge
Main transaction Periodic bill
Credit memo: Service charge Credit memo: Demand charge
Receivable: Demand charge .....
.....
⇒ Freely definable - No allocation / inclusion in rates / account determination SAP AG 2003
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).
© SAP AG
IUT240
5-12
Sub-Transactions in IS-U: Statistical Budget Billing Procedures
Budget billing payment Budget billing pay-out
Budget bill. paym. transfer posting
Budget billing plan Debit
Main transaction Statistical budget billing procedure
Budget billing plan credit
.....
Budget billing pay-out transfer posting
..... ⇒ Freely definable / inclusion in rates / account determination (budget billing)
⇒ Allocation to internal transactions / no account determination SAP AG 2003
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.
© SAP AG
IUT240
5-13
Transactions and Account Determination: Account Determination
Structure and Concept of Transactions Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
SAP AG 2003
© SAP AG
IUT240
5-14
Account Determination: Receivables Account Receivables account
Business transaction For example, interest:
Balance account
Main transaction 0040
Contract account/ Contract Company code U100 Division Account determination ID 01
140580
(Receivables)
Account Determination
Define account assignment data relevant for main transactions Posting area R000 / T000 / M000 SAP AG 2003
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.
© SAP AG
IUT240
5-15
Account Determination: Revenue Account Business transaction For example, interest: Main transaction 0040 Subtransaction 0020
Transaction determination
Profit/Loss account 800520
Transaction Contract account/ Contract Company code U100 Division Account determination ID 01
Sales revenue account
(Revenues)
0040/0020
Account Determination
Define account assignment data relevant for transactions Posting area R001 / T001 / M001 SAP AG 2003
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 contractdependent CO account assignment key that is defined in the IS-U contract.
© SAP AG
IUT240
5-16
Transactions and Account Determination: Tax determination
Structure and Concept of Transactions Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
SAP AG 2003
© SAP AG
IUT240
5-17
Tax: Tax Code Determination Business transaction For example, interest: Main transaction 0040 Subtransaction 0020
Transaction determination
Transaction Contract account/ Contract Company code U300 Division Account determination ID 01
Sales revenue account Profit/loss account 800520 Tax determination E1
0040/0020
Tax determination Account Determination
Define sales/purchase tax determination Accounts for sales/purchase tax 0010
Tax determination E1 From-date 04/01/1998 Sales/pur.tax cde (FI) A3
Tax determ. FI S/P tax code Tax rate
A3 16 %
SAP AG 2003
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.
© SAP AG
IUT240
5-18
Tax: Tax Change
Country DE DE DE US .....
Tax determination ID
TD
Valid-from Tax
Description
E1 E1 E2 E1
01/01/1995 04/01/1998 01/01/1995 01/01/1995
Output tax 15% Output tax 16 % Output tax 7% A/R Sales Tax, taxable
Start of validity period
A1 A3 A2 O1
Tax ID in FI
Long text for tax ID
Valid-to 03/31/1998 12/31/1999 12/31/1999 12/31/9999
End of validity period
SAP AG 2003
Example: Tax increase from 15% to 16%: y The sales/purchase tax determination code E1 is valid from 01/01/1995 to 03/31/1998. y The tax determination ID A1 is valid in general ledger accounting for this period. y The tax code (A3) resulting from the change of tax must be newly defined in general ledger accounting. y In FI-CA, a new validity period is specified, in which the new tax code is allocated.
© SAP AG
IUT240
5-19
Tax: Procedure for Changing Tax IS-U (1)
Specification of tax determination ID CCODE
Division
MTORG
STORG
KOFIZ
TAXDETID
U100
01
0100
0020 (AP)
01
E1
U100
01
0100
0030 (LP)
01
E1
Historical determination of tax code Country TAXDETID
FDATE
TAXID
DE
E1
01/01/95
A1
DE
E1
04/01/98
A3
DE
E2
01/01/95
A2
TE011 E1 A1 (15 %) E1 A3 (16 %) E2 A2 (7 %)
Billing SAP AG 2003
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.
© SAP AG
IUT240
5-20
Tax: Procedure for Changing Tax IS-U (2)
Proration for change date OPERAND
TRANS
NETAMNT
TODATE
TAXID
HTVB
0100 0020
100
FDATE 06/01/97
03/31/98
A1
HTVB
0100 0020
130
04/01/98
05/31/98
A3
NTVB
0100 0020
200
03/31/98
A1
NTVB
0100 0020
500
06/01/97 04/01/98
05/31/98
A3
Billing Determination of tax account and amount OPERAND NETAMNT HTVB ...
TAXID
100 ...
A1 ...
TAXAMNT TAXACNT 15 ...
175000 ...
Invoicing SAP AG 2003
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.
© SAP AG
IUT240
5-21
Transactions and Account Determination: USA Jurisdiction Code
Structure and Concept of Transactions Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
SAP AG 2003
© SAP AG
IUT240
5-22
Tax Calculation Based on Jurisdiction Code
z Standard SAP interface for internal or external tax calculation with jurisdiction code z Determination of tax code is the same as without jurisdiction code z Jurisdiction code assigned at contract level and contract account level z Tax rate changes maintained in table TE012 if tax calculation is executed in an external system
SAP AG 2003
© SAP AG
IUT240
5-23
Jurisdiction Code Assigned in Contract
Contract
Edit
Goto
Contract Division Company code Page 1
Change Contract: Page 2 4711 Extras Environment System Help
4711 01 U300
Page 2
Division electricity IBU Utility US Inc. 300
Page 3
Data relevant to billing
Jurisdict. code
101110001
Account assignment data Act. Determ. Code
01
SAP AG 2003
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.
© SAP AG
IUT240
5-24
Jurisdiction Code Assigned in Contract Account
Contract account
Edit
Contract acc. Partner/Address
Contract account Change: General data Goto Extras Environment System
4811 1000
Cont. acc. Rose Taylor
Help
01 IS-U Contract Account US/02100/Boston/Oxlade Drive
General data
Jurisdict. code
101110001
SAP AG 2003
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.
© SAP AG
IUT240
5-25
External System - Tax Rate Change
Jurisdiction Code
City US US
Product
101110001 101110001
Valid from 01/01/1995 04/01/1998
Valid to 03/31/1998 12/31/9999
.....
Jurisdiction Code
Product Code external System
Start date
End date
SAP AG 2003
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.
© SAP AG
IUT240
5-26
Tax Determination with Jurisdiction Code Business Transaction
e.g. Interest: MainTransaction 0040 SubTransaction 0020
Finding Transaction
Transaction Contract Account/ Contract
0040/0020
Company Code U300 Division Account Determination ID 01 JD Code 101110001
Account
Revenue Account P&L Account Tax Determination
800520 E1
Sales/Purchase Tax determination Determination
Tax Determination E1 From 04/01/1998 S/P key (FI) O1
Tax Determ. FI S/P key JD code S/P rate
01 101110001 8%, 3%, 1%
SAP AG 2003
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.
© SAP AG
IUT240
5-27
Transactions and Account Determination: Customizing
Structure and Concept of Transactions Account Determination
Tax Determination
USA: Jurisdiction Code
Customizing
SAP AG 2003
© SAP AG
IUT240
5-28
Transactions and Account Determination: Customizing
IMG Contract Accounts Receivable and Payable Basic Functions Postings and Documents Document Define Sales/Purchase Tax Determination Maintain......Transactions Perform Consistency Check for Transactions Define Account Assignments for Automatic Postings Define CO Short Account Assignments Store CO Short Account Assignments for IS-U Contracts Account Assignments for Down Payments/Charges Automatic G/L Account Determination Define Accounts for Sales/Purchase Tax Define Accounts for ......... ......Define account assignment data relevant for main transactions .... Define account assignment data relevant for transactions Define Accounts for Budget Billing Down Payments SAP AG 2003
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.
© SAP AG
IUT240
5-29
Transactions and Account Determination: Summary (1)
z The business transactions of FI-CA subledger accounting transactions can be illustrated by the definition of FI-CA transactions z 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
SAP AG 2003
© SAP AG
IUT240
5-30
Transactions and Account Determination: Summary (2)
z The receivables account that is relevant to a specific accounting transaction is determined by the main transaction. z 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.
SAP AG 2003
© SAP AG
IUT240
5-31
Transactions and Account Determination: Summary (3)
z The tax determination code is managed historically. z The tax determination code refers to the tax ID in general ledger accounting z The tax percentage rate is determined in Financial Accounting.
SAP AG 2003
© SAP AG
IUT240
5-32
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? ____________________________________________________________ ____________________________________________________________
© SAP AG
IUT240
5-33
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? ____________________________________________________________ ____________________________________________________________
© SAP AG
IUT240
5-34
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: © SAP AG
IUT240
5-35
Company Code: Division: Short text: Long text: Main trans.: Subtrans.: Debit/credit indicator: Manual posting allowed:
U100 (U300) othRec.## Other receivables ## SB## FO## Debit 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: Division: Act determ. ID: Main Trans.:
U100 (U300) 01 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: Division: Act determ. ID: Main Trans.: Subtrans.:
U100 (U300) 01 SB## 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.
© SAP AG
IUT240
5-36
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.
© SAP AG
IUT240
5-37
Payment
Contents: z Overview of the payment run z Payment Run - Procedures, Parameters, Program Flow z Payment methods z Payment Cards z Customizing
SAP AG 2003
© SAP AG
IUT240
6-1
Payment: Overview
This unit will enable you to understand: z The prerequisites for making payments z How to define payment methods and how they influence the payment process z How to customize your payment requirements
SAP AG 2003
© SAP AG
IUT240
6-2
Payment: Unit Objectives
At the conclusion of this unit, you will be able to: z Make payments in contract accounts receivable and payable z Carry out postings and repayments using the payment run z Make payments with credit cards
SAP AG 2003
© SAP AG
IUT240
6-3
Payment: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
6-4
Payment: Business Scenario
z During invoicing, receivables were posted to a business partner's contract account. Billing also created credit for several business partners. z The receivables are posted using the debit memo procedure and the credits are refunded during payment processing.
SAP AG 2003
© SAP AG
IUT240
6-5
Payment Run: Overview
Overview of Payments Payment Run - Program Flow and Parameters Payment Cards
Customizing
SAP AG 2003
© SAP AG
IUT240
6-6
Payment Program: Master Record z Business partner
Bank data
Payment card data
Address
z Contract Account Account
Responsible 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)
SAP AG 2003
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.
© SAP AG
IUT240
6-7
Payment: Posting 1 Contract Acct [1]
300.00 300.00
FI-CA
[2]
Receivables account [1]
300.00
300.00
Revenue account 261.00
[2]
[1]
Bank clearing
Bank [2]
300.00
Tax account 39.00
[1]
FI SAP AG 2003
[1] Debit position of a receivable [2] Payment in FI-CA by the payment run.
© SAP AG
IUT240
6-8
Payment: Posting 2 Contract Acct [1]
300.00 300.00
FI-CA
[2]
Receivables account [1]
300.00
300.00
Revenue account 261,--
[2]
Bank clearing
Bank [3]
300.00
[1]
[2]
300.00 300.00
[3]
Tax account 39.00
[1]
FI SAP AG 2003
[3] Incoming payments in General Ledger Accounting (posting the account statement).
© SAP AG
IUT240
6-9
Payment Run - Program Flow and Parameters
Overview of Payments Payment Run - Program Flow and Parameters Payment Cards
Customizing
SAP AG 2003
© SAP AG
IUT240
6-10
Payment Program: Procedure Determination of items to be paid
Grouping of due items
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 SAP AG 2003
© SAP AG
IUT240
6-11
Payment Program: Parameters
Date identifier Identification General selections
Free selections
Business partner Free selections Contract Account Company code Due date Payment methods
Bank selection
Tech. settings
Bank Company code
Number of jobs
selection Payment method Currency
Logs Problem class Additional log Selection
House bank Account ID Ranking order
Repayments Posting parameters
Simulation run SAP AG 2003
© SAP AG
IUT240
6-12
Payment Program: Parameters
Payment runs: Find payments Determination of payments in payment runs based on certain selection criteria: Bank data Payment card data Amounts Result: List with detailed information on each payment
SAP AG 2003
You can look for payments in the SAP applications menu under Contract Accounts Receivable and Payable -> Payments -> Payment Run -> Find Payment.
© SAP AG
IUT240
6-13
Payment Run
z Overview of Payments z Payment Run - Program Flow and Parameters z Payment methods z Payment Cards z Customizing
SAP AG 2003
© SAP AG
IUT240
6-14
Payment Program: Payment Methods 1
Contract account 4712
Contract account 5421
Bank trans.ref. - pymnt meth. 01 Bank no.: 10010000 - acct: 541237 Bank dir. debit - pymnt meth. 02 Bank no.: 10010000 - acct: 541237
DME
DME
Contract account 4711 123.45
Outg. check - pymnt meth. 03 69190 Walldorf, Astor Street 12
SAP AG 2003
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.
© SAP AG
IUT240
6-15
Payment Program: Payment Methods 2
Doc. 1230067 Doc. type 05
Direct debit- pymnt meth. 01 Bank no.: 10010000 - acct: 541237 Inc.pymnt method .....X Bank details................X
Format
Outg. check - pymnt meth. 03 69190 Walldorf, Astor Street 12
Doc. 600999 Doc. type 08
Create check…...........X Street. P.O. box...........X
Format
SAP AG 2003
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.
© SAP AG
IUT240
6-16
Payment Program: Document Data
Payment method
Doc. 0123456789 Amount: 112.67 USD Due: 05/22/03
Payment block reason Grouping
Due date
Deferral date
Alternative payer
SAP AG 2003
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.
© SAP AG
IUT240
6-17
Payments: Output Forms Karl Einstein
Date
Bank transfer
9.500
Karl Einstein
Bank transfer
Date
Data medium
9.500
Payment advice
Exception list Payment summary
DME DME
DME
Logs
?
Accompanying sheet DME
Clarification of payment exceptions
SAP AG 2003
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.
© SAP AG
IUT240
6-18
Cross-Business Partner Payments Business partner Father
Cont. acct: Father Bank details Payment method .... CA document
2 2
CA daughter pays via BP + CA father:
2
Payment Business partner Daughter
Cont. acct: Daughter Bank details Payment method Payer: BP father Paid by: CA father CA document CA document
1 1 ... 1 3
Bank details Payment method .... CA document CA document CA document Total
2 2 1 2 3
1,2,3
SAP AG 2003
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.
© SAP AG
IUT240
6-19
Payment Run: Payment Cards
Overview of Payments Payment Run - Program Flow and Parameters Payment Cards
Customizing
SAP AG 2003
© SAP AG
IUT240
6-20
Payment Cards Business partner with payment cards
Contract account
Payment run Payment method K
Bank details Payment method CA document
Receivables
Payment doc.
50 USD 70 USD
1 K 50
K
-50
Card account
Card account
120 USD
Billing
50 USD 70 USD
Clearing account 120 USD
1120
1120 DME DME
Items to be billed .....
DME Billed items .....
SAP AG 2003
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.
© SAP AG
IUT240
6-21
Payment Cards: Posting Process Contract account [1]
58.00 58.00
[1]
G/L account Electricity 58.00 58.00
Bank [4 ]
58.00
FI-CA
Example:
[2]
Card payment of an open receivable
Revenue account Electricity 50.00 [1]
[2]
Tax account 8.00
[1]
card reporting account [2] 58.00 58.00 [3] Card clearing account [3]
58.00 58.00
[4]
FI SAP AG 2003
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
© SAP AG
IUT240
6-22
Payment Run
Overview of Payments Payment Run - Program Flow and Parameters Payment Cards
Customizing
SAP AG 2003
© SAP AG
IUT240
6-23
Direct Debit/Repayments: Customizing
IMG Contract Accounts Receivable and Payable Business transactions Payments Incoming/Outgoing Payment Creation Maintain Note to Payee Type for Payment Medium Define Own Bank Details and User Numbers Define Parameters for Foreign Payment Transactions Define Payment Methods Define Specifications for Responsible Company Code Define Bank Nodes for Payment Program Maintain Bank Selection Define Payment Lock Reasons Select Item Indicator for Clarification Worklist Define Scope of Exception List Check Number Ranges for Payment Orders Payment Cards Define Accounts for Payment Card Institute Define Accounts for Posting Settlement Document SAP AG 2003
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.
© SAP AG
IUT240
6-24
Payment: Summary
z The payment run includes the direct debit of open receivables, the refund of credits, and the clearing of open items. z When credits and receivables exist, these are cleared and the balance is paid. z Different formats and output media are used depending on the payment method. z Payment via credit card takes place through a card reporting account. In this case, the data media are created separately.
SAP AG 2003
© SAP AG
IUT240
6-25
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. © SAP AG
IUT240
6-26
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: Posting date: Currency: Company code Taxes:
01.12.2004 01.12.2004 EUR (USD) U100 (U300) 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.
© SAP AG
IUT240
6-27
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.
© SAP AG
IUT240
6-28
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.
© SAP AG
IUT240
6-29
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.
© SAP AG
IUT240
6-30
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.
© SAP AG
IUT240
6-31
Returns Processing
Contents: z Overview of Returns Processing z Posting of Returns z Customizing
SAP AG 2003
© SAP AG
IUT240
7-1
Returns Processing: Overview
This unit will provide you with an overview of: z The procedure and functions z Postings z and Customizing of returns processing
SAP AG 2003
© SAP AG
IUT240
7-2
Returns Processing: Unit Objectives
At the conclusion of this unit, you will be able to: z Enter and post returns z Process return lots z Carry out the appropriate Customizing activities, for example:
Configure returns reasons
Pass on charges
Enter payment and dunning locks
z Create returns correspondence
SAP AG 2003
© SAP AG
IUT240
7-3
Returns Processing: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
7-4
Returns Processing: Business Scenario
z 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.
SAP AG 2003
© SAP AG
IUT240
7-5
Returns: Overview of Returns Processing
Overview of Returns Processing Posting Returns
Customizing
SAP AG 2003
© SAP AG
IUT240
7-6
Returns: Activities 1
Reverse OI clearing or post new receivable
Which items were paid?
Does the return include charges?
Trigger posting of charges
Pass on charges?
Own charges?
SAP AG 2003
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?
© SAP AG
IUT240
7-7
Returns: Activities 2 Further activities depend on: Returns reason, house bank, company code, number of returns, creditworthiness, tolerance group
Deferral days Set locks Dunning lock
Bill of exchange to cash payer Lock duration days Payment lock incoming/outgoing Item level Contract account level Item level Contract account level
Charges Pass charges on Calculate graduated charges Payment method Delete/change incoming/outgoing Delete / change item payment method Further activities Accounting clerk Returns correspondence/returns history
Post charges statistically
Workflow
SAP AG 2003
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.
© SAP AG
IUT240
7-8
Returns Lot: Processing Steps
New lot
Create
Close
Enter items
Post
Lot completed
Postprocessing
SAP AG 2003
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.
© SAP AG
IUT240
7-9
Returns: Returns History
12/15/2002 1234 01/01/2003 3678 01/15/2003 4112 01/30/2003 4711 Returns document Payment document Amount Bank charge 1 Bank charge 2 .... Returns charge ....
4711 56789 3,507.50 7.50 0.00
Every return has an entry in the returns history
0.00
SAP AG 2003
Updating the returns history: y Commercially applicable data - Amounts - Document numbers y 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.
© SAP AG
IUT240
7-10
Creation of Printout with Print Container Dunning notices
Installment plan letter
Print creation Print container
Bank statement
Returns letter
...
SAP AG 2003
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.
© SAP AG
IUT240
7-11
Returns: Posting Returns
Overview of Returns Processing Posting Returns
Customizing
SAP AG 2003
© SAP AG
IUT240
7-12
Posting: With Bank Charges 1 CAcct1 FI-CA [1] 100.- 100.- [2]
FI-CA
Bank clearing [2] 100.-
Receivables [1] 100.-
100.- [2]
Revenue 100.- [1]
FI SAP AG 2003
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection
© SAP AG
IUT240
7-13
Posting: With Bank Charges 2 Contract account [1] 100.- 100.- [2]
FI-CA
Bank clearing [2] 100.-
[3] 100.-
100.- [3]
Receivables [1] 100.-
Bank
100.- [2]
Revenue 100.- [1]
FI SAP AG 2003
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement)
© SAP AG
IUT240
7-14
Posting: With Bank Charges 3 Contract account [1] 100.- 100.- [2]
FI-CA
Bank clearing [2] 100.-
Bank [3] 100.-
100.- [3]
110.- [4]
Returns clearing acct [4] 110.-
Receivables [1] 100.-
100.- [2]
Revenue 100.- [1]
FI SAP AG 2003
[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement)
© SAP AG
IUT240
7-15
Posting: With Bank Charges 4 Contract account [1] 100.- 100.- [2]
FI-CA
[5] 100.-
Bank clearing [2] 100.-
Bank [3] 100.-
100.- [3]
110.- [4]
Returns Clearing account [4] 110.- 100.- [5]
Receivables [1] 100.-
100.- [2]
Revenue 100.- [1]
[5] 100.-
FI SAP AG 2003
[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)
© SAP AG
IUT240
7-16
Posting: With Bank Charges 5 Contract account [1] 100.- 100.- [2]
FI-CA
[5] 100.-
Bank clearing [2] 100.-
Bank [3] 100.-
100.- [3]
110.- [4]
Returns Clearing account [4] 110.- 100.- [5]
Expense [6] 10.-
10.- [6] Receivables [1] 100.-
100.- [2]
Revenue 100.- [1]
[5] 100.-
FI SAP AG 2003
[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
© SAP AG
IUT240
7-17
Posting: With Bank Charges 6 Contract account [1] 100.- 100.- [2]
FI-CA
[5] 100.[7,8] 17.Bank clearing [2] 100.-
100.- [3]
Receivables return
Bank [3] 100.-
[7] 10.-
110.- [4]
[8] 7.Expense [6] 10.-
Receivables [1] 100.-
100.- [2]
10.-
[7]
Returns Clearing account [4] 110.- 100.- [5]
7.-
[8]
10.- [6]
Revenue from returns
Revenue 100.- [1]
[5] 100.-
FI SAP AG 2003
[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.
© SAP AG
IUT240
7-18
Returns: Customizing
Overview of Returns Processing Posting Returns
Customizing
SAP AG 2003
© SAP AG
IUT240
7-19
Returns: Customizing 1
IMG Contract Accounts Receivable and Payable Business transactions Returns Configure Returns Reasons Assign Return Reasons to House Banks Define Bank Clearing Account for Returns Define Clarification Accounts for Returns Define Charges Accounts for Returns Define Account Assignments for New Items with Returns Determine Document Type and Clearing Reasons for Returns Define Field Selection Define Field Selection for Returns Define Transactions for Electronic Account Statement Transfer Define Time-Dependent Creditworthiness Ratings Define Correspondence Form
SAP AG 2003
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: y Charges/debiting of charges y Deferral days y Define locks and forms y Define information for accounting clerk y Amount limits, creditworthiness. y Clearing accounts, revenue and expense accounts, receivables account and clarification account. y Configuration of entry lines for the dialog processing returns lots y 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.
© SAP AG
IUT240
7-20
Returns Processing: Summary
z To process returns, you define return types and return reasons. z Depending on the cause and the origin of a return, some activities can be executed automatically. z The returns charges that can be passed on to customers can include your own charges (in addition to bank charges). z When processing a returns lot, the system updates the returns history.
SAP AG 2003
© SAP AG
IUT240
7-21
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: History days: Creditworthiness number
Bank return 30 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.
© SAP AG
IUT240
7-22
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: Search term: Currency: Company code Amounts contain bank charges: Calculate charges: Enter the returns item: B selection value:
RL06010## Returns group 0## EUR (USD) U100 (U300) X X Document number from the Payment unit G##
Return reason:
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
© SAP AG
IUT240
7-23
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: © SAP AG
IUT240
7-24
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.
© SAP AG
IUT240
7-25
Incoming Payments
Contents: z Payment Lot z Clarification Worklist z Credit Processing z Cash Journal / Cash desk z Customizing
SAP SAP AGAG 2003 2003
© SAP AG
IUT240
8-1
Incoming Payments: Unit Objectives
At the conclusion of this unit, you will be able to: z Use the payment lot functions for entering incoming payments z Enter incoming payments in the cash journal z Allocate or refund unclarified payments received from the clarification worklist
SAP SAP AG AG 2003 2003
© SAP AG
IUT240
8-2
Incoming Payments: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
8-3
Incoming Payments / Clarification Processing: Business Scenario
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. z You enter the incoming bank transfers in a payment lot. z You post cash payments in the cash journal. z You use a clarification worklist to manage payments that you cannot allocate.
SAP AG 2003
© SAP AG
IUT240
8-4
Incoming Payments: Functions Payment Lot 123.13 USD 43.45 USD 345.36 USD Payment card lot 85.00 USD 123.45 USD Check lot 345.34 USD 230.00 USD Payment order lot
Karl Einstein
Bank transfer
Date
9.500
34.00 USD 210.46 USD SAP AG 2003
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.
© SAP AG
IUT240
8-5
Incoming Payment: Payment Lot
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
SAP AG 2003
© SAP AG
IUT240
8-6
Payment Lot: Use
z 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.
SAP AG 2003
© SAP AG
IUT240
8-7
Incoming Lot: Processing Steps
New lot
Create
Close
Display/ change
Post
Lot processed
Clarification worklist
Postprocessing
SAP AG 2003
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.
© SAP AG
IUT240
8-8
Generate Payment Lot
DME
FF.5
DME
Read elec. bank statement
Bank data memory
FPB7
Transfer data from electronic bank statement
Display/change incorrect data records
FPB17 Transfer data from MultiCash
Display/change incorrect data records
123.13 USD 43.45 USD 345.36 USD
Doc. 123 123.13 USD
120.00 USD 349.90 USD
Doc. 126 120.00 USD
1250.45 USD 456.90 USD
Doc. 128 1250.45 USD
SAP AG 2003
The bank transfers from an account statement are stored in a payment lot. Payments are assigned when the payment lot is processed. Interfaces: y 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. y 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.
© SAP AG
IUT240
8-9
Interpretation Rules: Note to Payee
Note to payee
Customer number 10004711 Contract 0815, budg. bill. from 05/01/03
+
Business partner C acct Contract Other info
10004711
Interpretation rule for note to payee
Due by 05/10/03
2100.00
SAP AG 2003
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).
© SAP AG
IUT240
8-10
Incoming Payment: Postings 1 Contract account
FI-CA
[1] 50.-
Receivables [1] 50.-
Bank
Revenue 50.- [1]
Cash clearing
FI SAP AG 2003
Postings: 1. Debit entry from invoicing (shown without tax posting)
© SAP AG
IUT240
8-11
Incoming Payment: Postings 2 Contract account
FI-CA
[1] 50.-
Receivables [1] 50.-
Bank [2] 50.-
Revenue 50.- [1]
Cash clearing 50.- [2]
FI SAP AG 2003
Postings 2. Incoming payment at the bank (the account statement is posted in the general ledger)
© SAP AG
IUT240
8-12
Incoming Payment: Postings 3 Contract account [1] 50.-
50.- [3]
Receivables [1] 50.-
Revenue 50.- [1]
50.- [3]
Bank [2] 50.-
FI-CA
Cash clearing [3] 50.-
50.- [2]
FI SAP AG 2003
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
© SAP AG
IUT240
8-13
Payment Advice 1
2
Payment advice: 1004711 Customer: 10000815 Max Donaldson Corp. Bill no. Amount 2001234 120.45 3003461 349.90 ∑ 470.35
3 Max Donaldson Corp. Acct.: 0815
Lot 1 470.35 USD Z: 1004711
Doc.
Amount Open
2001234 120.45 120.45 3003461 700.35 349.90 4001234 600.87 600.87
Selection type: Payment advice
Payment Doc. 126 120.45 USD
Payment doc. 127 349.90 USD
1
Copy payment advice
2
Additional selection through payment advice
3
Payment allocation according to payment advice criteria (under/overpayment possible)
SAP AG 2003
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.
© SAP AG
IUT240
8-14
Contract account 4 Contract account 3 Contract account 2 Receivable Contract account 1 320.45 USD Receivable 220.45 USD LastReceivable recipient 520.45 USD XYZ Receivable Last recipient 120.45 USD XYZ Last recipient XYZ Last recipient XYZ
Incoming payment
Revenue Distribution
Contract account Last recipient XYZ
Distribute revenue
Post distribution RFKKRD00
∑ Credit 1,268.65 USD
SAP AG 2003
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.
© SAP AG
IUT240
8-15
Incoming Payment: Clarification Worklist
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
SAP AG 2003
© SAP AG
IUT240
8-16
Incoming Payment: Payment Allocation
Open items
Incoming payment Clearing Control Individual criteria Manual allocation
Payment form no. Business partner Document no. Contract account Contract Gross amount
Payment posting SAP AG 2003
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.
© SAP AG
IUT240
8-17
Incoming Payment: Tolerance Limits
Tolerance limit 3.50 USD
Receivable 273.50 USD
Receivable 273.50 USD Cleared Spec. difference acct: Posting 3.50 USD
Incoming payment 270 USD Tolerance limit < 3.50 USD
Receivable 270 USD Cleared Outstanding receivable 3.50 USD
SAP AG 2003
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.
© SAP AG
IUT240
8-18
Payment Lot: Clarification Worklist
DME
Doc. 126 120.00 USD
1
Lot 1
Doc. 127 456.90 USD
120.00 USD 349.90 USD
2 1
Lot 2 interface Transfer
Clarification worklist
250.45 USD 456.90 USD
2
1 2
250.45 USD 349.90 USD
3
Doc. 198 349.90 USD 3
3
Doc. 199 250.45 USD
Payment Allocation No payment allocation possible
SAP AG 2003
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.
© SAP AG
IUT240
8-19
Accounting Clerk Assignment
Payment lot
Total list of administrator
Doc. 4712 Not SB1, but SB2!!!
Clarif. Worklist Payment Lot
Accounting clerk determ.
Doc. 4711 Doc. 4712 Doc. 4713 Doc. 4811 Doc. 4812 ...
Clarif. Worklist Payment run
Payment run
SB1 List - Payment lot Doc. 4711 Doc. 4712 Doc. 4713 ...
SB2 List - Payment lot Doc. 4811 Doc. 4812
Doc. 4712 ...
SAP AG 2003
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: y 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. y 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.
© SAP AG
IUT240
8-20
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
Partial / clearing of open items Payment on account Transfer posting to a clearing account Initiate repayment of amount
+ Exception account for payment clarification (FP05_PROP)
+ Error-tolerant search
Due amounts Last payments SAP AG 2003
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.
© SAP AG
IUT240
8-21
Interpretation: Note to Payee Clarification Selection proposals Business partner CAcct Contract Other info
Amount
4711
100.00
Note to payee Customer number 10004711 Contract 0815
+
Interpretation rule for note to payee
Proposal Business partner CAcct Contract Other info
10004711 4711
Due by 05/10/03
2100.00 0.00
SAP AG 2003
© SAP AG
IUT240
8-22
Payment Lot: Postprocessing Clarif. account Incoming lot
Repayment
Payment on account
123.23 234.76
Clear
General ledger transfer posting
Payment run
SAP AG 2003
Causes: y No payment allocation possible y Posting to the clarification account in the payment lot Measures: y 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 y 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 y Business partner/contract account unknown - Repayment
© SAP AG
IUT240
8-23
Repayment Request
Repayment flag / payment method
Payment lot
Postprocessing
Clarif. worklist
Clarification
Repayment request
Repayment active
Payment run Payment method
Payment document
SAP AG 2003
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.
© SAP AG
IUT240
8-24
Posting Procedure: Repayment (1) Contract account [1] 50.-
50.- [3]
Receivables [1] 50.-
Revenue 50.- [1]
50.- [3]
Bank [2] 50.-
FI-CA
Cash clearing [3] 50.-
50.- [2]
FI SAP AG 2003
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
© SAP AG
IUT240
8-25
Posting Procedure: Repayment FI-CA Example: • Payment received: USD 20 • No payment allocation possible
No posting is made to a contract account
Unclarified payments received [3]
20.-- 20.--
PosAr 1040
[2] Bank clearing / Incoming payment
Bank [1]
20.--
20.--
[5]
[2]
20.-- 20.--
[1]
Repayment clearing account [4] 20.-20.-- [3]
PosAr 1061 Bank clearing / Payment Run [5] 20.--
20.--
[4]
PostAr 0130 Payment method - House bank
FI
SAP AG 2003
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
© SAP AG
IUT240
8-26
Incoming Payment: Credit Processing
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash desk
Customizing
SAP AG 2003
© SAP AG
IUT240
8-27
Credit Processing
Credit items BP 1 Doc. 101 -71.20Doc. USD128 -45.34 USD
Clarify Process credit FPTCRPO
Transfer Pay Clear
BP 2 Doc. 101 -82.20Doc. USD128 -23.74 USD
Transfer post Write-off Generate credit list
Clarification worklist FPCRPO
BP 3 Doc. 101 -53.20Doc. USD128 -68.55 USD
Remain Send letter
... SAP AG 2003
You can use the following functions if the credit use has to be clarified for your business partner's contract accounts: y Credit clarification y Credit processing The following types of credit can be processed with the credit clarification function: y Credit that was previously selected by the mass activity Generate Credit List and sent to clarification processing. y 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.
© SAP AG
IUT240
8-28
Cash Journal / Cash Desk
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash Desk
Customizing
SAP AG 2003
© SAP AG
IUT240
8-29
Cash Journal Functionality Basics CD Structure
Role Concept
Special functions Open/close cash desks in local branches
Cash desk closing
Environment Historical data
Lot display
Functions Call cash desk
Current cash balance
Cash desk deposit
Compare cash desks
Partial or full withdrawal
SAP AG 2003
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.
© SAP AG
IUT240
8-30
Cash Desk Structure
Double-level cash desk hierarchy Branch/local office
Cash desk 1
Cash desk 2
Cash desk ...
Cash desk n
Default values: Company code Bank clearing account Lot/payment category
Default values: Company code Bank clearing account Lot/payment category
Default values: Company code Bank clearing account Lot/payment category
Default values: Company code Bank clearing account Lot/payment category
SAP AG 2003
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.
© SAP AG
IUT240
8-31
Role Concept Role-specific activities Historical data
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
NO
NO
YES
YES
YES
YES NO
NO
Create and close lot
Cash balance
YES
Transfer responsibility
Cashier
Differences
YES
Deposit
Cashier with special tasks
e
Withdrawal
YES
Ro l
iv it y
Open and close
Call cash desk
Branch office manager
Ac t
SAP AG 2003
Role concept (optional - can be activated/deactivated in Customizing) y Branch office manager standard role 21000058 y Cashier with special tasks: Standard role 21000059 y 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 y 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. y Cashier with special tasks - All branch office manager activities except for closing cash desks in the branch office. y Cashier - Entry of incoming and outgoing payments in his or her cash desk and posting deposits.
© SAP AG
IUT240
8-32
Individual Enhancement of Cash Journal
Events Event 6120: Call additional menu functions Historical cash balance Cash movement Check withdrawal Postal 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
SAP AG 2003
Bar code reader y 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. y There are 5 additional customer functions that can be activated and used for event 6120.
© SAP AG
IUT240
8-33
Cash Desk
CityBank Pay to the or der of
CurrencyAmou nt
- 400,-
UNI
Four hundred Amou nt in wo rds
UNI CEF
an oder Ü ber brin ger
Ort
New York 1.4.1996
Date Signature Do n ot alter t he pr int ed tex t..
Check No.
00000150900
X
Account No.
X Amount
X
Bank C ode
12131400
X Text
67291500 11
Pleas e do not writ e in thi s area
Business partner
Post directly
Contract account Contract
Contract account
Document no.
Post online
Net due date
Post on account
Payment form no. Receipt
Check deposit list
You paid USD 123.45 on 05/15/2003....
SAP AG 2003
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.
© SAP AG
IUT240
8-34
Payment on Installment Plan Installment plan #0815
Source receivable No. Due #4711 08/30/2002 #6789 09/25/2002
50.00
50.00
No. 1 2 3 4
1. Clearing proposal Post item in dialog
Due 01/09/2003 02/09/2003 03/09/2003 04/09/2003
Amount 250.50 149.50 Inst. amount 100.00 100.00 100.00 100.00
2. Expand installment plan Clearing proposal #4711
08/30/2002
250.50
#6789
09/25/2002
149.50
50.00
SAP AG 2003
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.
© SAP AG
IUT240
8-35
Incoming Payment: Customizing
Payment Lot
Clarification Worklist
Credit Processing
Cash Journal / Cash Desk
Customizing
SAP AG 2003
© SAP AG
IUT240
8-36
Incoming Payments: Customizing (1)
IMG Contract Accounts Receivable and Payable Business transactions Payments Incoming/Outgoing Payment Processing Cash Desk Define Specifications for Cash Desk Define Short Acct Assignments for Transfer Posting to Cash Desk Cash Journal Define Master Data for Cash Journal Maintain Specifications for Cash Journal Define Accounts for Expense/Revenue from Cash Payments Default Values for Posting Cash Desk Deposits and Withdrawals Maintain Responsibilities for User of Cash Journal Maintain Authorizations for Branch Office Manager Maintain Authorizations for Cashier with Special Tasks Maintain Authorizations for Cashier Maintain Role-Specific Activities for Cash Journal Define Currency Units of Notes and Coins Sheet SAP AG 2003
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: y Prevent the cash desk from being called up directly by flagging the Cash Journ. Act. indicator in the activity: Maintain Specifications for Cash Journal. y 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.
© SAP AG
IUT240
8-37
Incoming Payments: Customizing (2)
IMG Contract Accounts Receivable and Payable Incoming/Outgoing Payment Processing Define Screen Variants for Payment Lot Define Default Values for ... Lot(s) Define Bank Clearing Accounts for Payment Lots Define Clarification Account Define Clearing Account for Check Deposit Define Specifications for Repayment of Incoming Payments Check Number Ranges for Repayment Requests Define Transactions for Electronic Bank Statement Transfer Define Programs for Converting Country-Spec. Formats into MultiCash Define Prefix for Created Lot IDs during Account Statement Transfer Check Procedure for Interpretation of Note to Payee Define Interpretation Rules for Note to Payee Test Interpretation Rules for Note to Payee Define Bank Accounts with Individual Clarification Proposal Define Short Account Assignments for Transfer Postings Define Forms for Check Deposit List SAP AG 2003
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.
© SAP AG
IUT240
8-38
Incoming Payments: Customizing (3)
IMG Contract Accounts Receivable and Payable Business Transactions Credit Define Selection Criteria for Credit Clarification Define Document Types for Credit Clarification Define Clearing Account for Transferring Credits Revenue Distribution Define Specifications for Deriving Final Recipient Define Specifications for Revenue Distribution Define Main and Subtransactions for Distribution Posting
SAP AG 2003
Selection criteria for clarifying credit. Field Immediately: y Ensures that a line item that fulfills the Customizing criteria is inserted directly in the credit list for clarifying credits. y If you do not set this indicator, the line items are inserted in the clarification worklist when you call the credit list.
© SAP AG
IUT240
8-39
Incoming Payments: Summary (1)
z You can use the payment lot and the cash desk function that is integrated in the cash journal for managing incoming payments. z 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. z You use a clarification worklist to manage payments that you could not be allocated. z you can use credit clarification to select and process credit and payments on account that have not been allocated.
SAP AG 2003
© SAP AG
IUT240
8-40
Incoming Payments: Summary (2)
z The cash journal and its integrated cash desk functionality enable you to log and evaluate postings made to a company's cash desk. z Incoming and outgoing payments can be made using different payment types in the cash desk. z You can print out a receipt for a payment made at the cash desk.
SAP AG 2003
© SAP AG
IUT240
8-41
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? ________________________________ © SAP AG
IUT240
8-42
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: © SAP AG
IUT240
8-43
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.
© SAP AG
IUT240
8-44
Incoming Payments / Clarification Processing - Solutions
1
Unit:
Incoming Payments
Topic:
Entering Payments
Incoming payments
1-1
Payment lot.
1-1-1 Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Payment Lot → Create. Reconciliation key:
1-2
ZS-## (## = Group number)
Status:
Postings made.
List Type:
All items
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.
© SAP AG
IUT240
8-45
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.
© SAP AG
IUT240
8-46
Clearing Control
Contents: Terminology and examples Customizing
SAP AG 2003
© SAP AG
IUT240
9-1
Clearing Control: Overview
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
SAP AG 2003
© SAP AG
IUT240
9-2
Clearing Control: Unit Objectives
At the conclusion of this unit, you will be able to: Map your company's automatic assignment and clearing strategy in the system
SAP AG 2003
© SAP AG
IUT240
9-3
Clearing Control: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
9-4
Clearing Control: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
9-5
Clearing Control: Terminology and examples
Terminology and Examples
Customizing
SAP AG 2003
© SAP AG
IUT240
9-6
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. SAP AG 2003
© SAP AG
IUT240
9-7
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.
SAP AG 2003
© SAP AG
IUT240
9-8
Clearing Control: Overview 1 DFKKOP
DFKKOP
Open items
Incoming payment Selection 1n
cl ea rin g
Business transaction Clearing type 05
st ep s
Clearing category
Contract account
Clearing entry SAP AG 2003
© SAP AG
IUT240
9-9
Example 1 - Payment Contract account 500.- 01/01/2003 600.- 02/01/2003 1000.- 03/01/2003
Payment 600.-
Clearing type Grouping
Clearing category
Due date clearing
Clearing exact amounts
Contract account 500.600.1000.- 600.-
01/01/2003 02/01/2003 03/01/2003 03/14/2003
SAP AG 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.
© SAP AG
IUT240
9-10
Example 2 - Account Maintenance Contract account 500.600.1000.- 300.-
Clearing type Grouping
01/01/2003 02/01/2003 03/01/2003 03/14/2003
01 01 03 01
Clearing category
Due date clearing
Clearing exact amounts
Contract account 300.200.600.1000.- 300.-
01/01/2003 01/01/2003 02/01/2003 03/01/2003 03/14/2003
01 01 01 03 01
SAP AG 2003
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.
© SAP AG
IUT240
9-11
Determination of Clearing Variants Clearing variants are determined depending on the clearing type of the underlying processes and, optionally, on the clearing category of the contract account. Business transaction Clearing type Payment lot 05 Cash desk 19 Automatic clearing 04
Clearing variant 05 19
0815
04 ⇒ AM1 04 + SAM ⇒ AM2
Contract account Clearing category Private C&I Collector
⇒ PY1 ⇒ PY1
STD SON SAM
Optional
SAP AG 2003
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).
© SAP AG
IUT240
9-12
Clearing Control: Clearing Types Overview of clearing types used in the standard processes (FI-CA) (Table TFK110, level 4.71) Clear Type
(*)
Description
Use
Inc_ Pymt X
01
Manual posting
1
03
Manual account maintenance
2
Use = Implementation area 1. incoming payment 2 Account maintenance 3 Distribute clearing amount amongst dependent items
04
Automatic account maintenance
2
05
Payment lot
1
06
Payment run
4
19
Cash desk: Payment
1
X
20
Cash Desk: Payment by Card
1
X
21
Cash Desk: Payment by Check
1
X
22
Cash Desk: Postal Order
1
X
25
Check Lot
1
X
45
Payment Order Lot
1
X
47
Electronic Bill Presentment and Payment
1
X
55
Credit Card Lot
1
X
20R
Distribute Payment to Installment Plan
3
X
20S
Distribute Payment to Collective Bill
3
X
30G
Distribute Payment to Summarization
3
X
4 Payment run X
Inc_Pymt: Assignment of available amount, for example,payment
(*) used in the configuration of enhanced grouping (event 0600) SAP AG 2003
© SAP AG
IUT240
9-13
Selection Restrictions Clearing type R41 Clearing category
Main trans.
Subtrans.
No clearing
STD STD
0050
STD
0020
Grace 14 21
0010
Clearing open items
No clearing
SAP AG 2003
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
© SAP AG
IUT240
9-14
Ranking and Grouping of Characteristics Characteristic 1 Such as company code
Characteristic 2 Such as Statistics indicator
Characteristic n: Such as due date
Characteristic attribute Such as U100 Characteristic attribute Such as U200
U100 U100
U200... U200... U200...
Characteristic attribute Such as R (inst. plan) Characteristic attribute Such as G (charges)
Characteristic attribute Such as 05/02 Characteristic attribute Such as 05/15
U100 R U100 R
U200 G U200 _ U200 _
U200 G U100 R 05/01/ U100 R 05/15/ 05/15/
...
SAP AG 2003
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.
© SAP AG
IUT240
9-15
Amount Check Groups
Group for joint clearing Credit or incoming payment
Receivable
Amount check group Currency From/to amount Absolute limits
Clearing: Credit/payment receivable
Percentage limit SAP AG 2003
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.
© SAP AG
IUT240
9-16
Clearing Variant
Next group
Form OI groups (from specifications for grouping string)
1-n clearing steps
Group processing Including: Sort sequence Amount-dependent grouping rule Splitting algorithm for partial clearing Customer-specific assignment rules
Follow-up processing specifications Tolerance handling for partial clearing Specifications for the next clearing step Specifications for ending the clearing process SAP AG 2003
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.
© SAP AG
IUT240
9-17
Clearing Step Grouping string Characteristic
Sorting string characteristic
Grouping rule
1.
1.
2.
2.
3.
3.
4.
4.
5.
5.
Amount rule
Customer module
Sort
End of clearing step
Group rule
Clearing rule
Ranking
Write off tolerance Clear. Var.
Paymt. rem var.
/
End of Assignment
/ SAP AG 2003
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.
© SAP AG
IUT240
9-18
Clearing Control: Customizing
Terminology and Examples Customizing
SAP AG 2003
© SAP AG
IUT240
9-19
Clearing Control: Group Rules
The amount rules specify the conditions under which an amount can be assigned to an item group (defined by grouping string) Examples: Partial clearing not permitted Clearing only with identical amounts Clearing only with 5% difference Clearing if within tolerance limits
Clearing rules specify how items in a group are cleared (presuming the amount rule for this group has been fulfilled) Examples: Assignment based on sort sequence During partial clearing, proportional distribution of amount available Assignment using customer module Assignment using alternative clearing variant/step SAP AG 2003
© SAP AG
IUT240
9-20
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. SAP AG 2003
© SAP AG
IUT240
9-21
Clearing Control: How Can I Test It?
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. 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. In the collective bill item In the installment plan item In the summarization item SAP AG 2003
© SAP AG
IUT240
9-22
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. 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.
SAP AG 2003
© SAP AG
IUT240
9-23
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 any subsequent processing (for example, down payments, actual requests for charges). 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(*) exist Write 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.
!
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.
SAP AG 2003
© SAP AG
IUT240
9-24
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. SAP AG 2003
© SAP AG
IUT240
9-25
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 becomes increasingly general with every subsequent step.
!
A clearing variant designed for payment assignment is not suitable for account maintenance.
SAP AG 2003
© SAP AG
IUT240
9-26
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.
SAP AG 2003
© SAP AG
IUT240
9-27
Clearing Control: Customizing
IMG Contract Accounts Receivable and Payable Basic Functions Open item management Clearing Control Clearing Variants Define Grouping and Sorting Features Define Amount Check Group Define Clearing Variants Define Clearing Categories Define Clearing Types Define Specifications for Clearing Types Define Defaults for Incoming Payments Define Defaults for Account Maintenance Define Defaults for Coll. Bill/Inst. Plan/ Summ. Group Define Specifications for Invoicing
SAP AG 2003
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.
© SAP AG
IUT240
9-28
Clearing Control: Summary (1)
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.
SAP AG 2003
© SAP AG
IUT240
9-29
Clearing Control: Summary (2)
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.
SAP AG 2003
© SAP AG
IUT240
9-30
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).
© SAP AG
IUT240
9-31
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##).
© SAP AG
IUT240
9-32
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
© SAP AG
Characteristic value: U100 (U300)
Ranking: 1
Characteristic value: U110 (U400)
Ranking: 2
IUT240
9-33
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.
© SAP AG
IUT240
9-34
Dunning and Collections
Contents: z Functions of the dunning procedure z Dunning history z Submission for collection z Customizing
SAP AG 2003
© SAP AG
IUT240
10-1
Dunning and Collections: Overview
This unit will provide you with an overview of the following in FI-CA: z The procedure and functions z The definition of dunning activities z The dunning history z Customizing of dunning in FI-CA z Submission of receivables for collection
SAP AG 2003
© SAP AG
IUT240
10-2
Dunning and Collections: Unit Objectives
z At the conclusion of this unit, you will be able to: z Perform a dunning and collection run z Establish the basic Customizing settings z Define the following terms:
Dunning charge category
Charges Schedule
Dunning grouping criteria
Dunning procedure
Collection submission
SAP AG 2003
© SAP AG
IUT240
10-3
Dunning and Collections: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
10-4
Dunning and Collections: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
10-5
Dunning and Collection: Dunning Procedure Functions
Dunning Procedure Functions Collection Processing
Customizing
SAP AG 2003
© SAP AG
IUT240
10-6
Dunning: Dunning Proposal and Dunning Activities
Amount limits Days in arrears Dunning frequency
Business partner Contract account Open items Dunning history
Determine dunning groups and the new dunning levels
Generate dunning proposal
Charges schedule Print forms
Generate dunning activities
Post interest and charges
SAP AG 2003
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.
© SAP AG
IUT240
10-7
Dunning Proposal Contract account 1 01/01/2003
100 USD
02/01/2003
100 USD
03/01/2003
100 USD
04/01/2003
100 USD
Business partner 1
Dunning run 02/03/03 Contract account 2 01/15/03
127 USD
01/15/03
232 USD
Dunning proposal business partner 1 01/01/03 CA1 100 USD 01/15/03 CA2 127 USD 02/01/03 CA1 100 USD
SAP AG 2003
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.
© SAP AG
IUT240
10-8
Determination of Dunning Levels
Contract account
Dunning procedure Dunning Grouping
Open items
Due date Deferral date Amount
Dunning history
Last dunning date Last dunning level
New dunning levels
SAP AG 2003
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.
© SAP AG
IUT240
10-9
Dunning Grouping Standard criteria
Alternative dunning recipient Business partner Dunning procedure Dunning group Resp. company code Currency
Grouping key: Additional criteria
Division 1
Dunning activity and dunning notice
Division 2
Dunning activity and dunning notice
SAP AG 2003
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.
© SAP AG
IUT240
10-10
Dunning: Configuration (1)
Dunning procedure
Factory calendar Alt. installment dunning procedure Alt. returns dunning procedure Behavior with last dunning level Dunning levels from other procedures Do not reduce dunning level Behavior with credit
SAP AG 2003
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.
© SAP AG
IUT240
10-11
Dunning: Configuration (2)
Dunning levels per dunning procedure
Charges Days in arrears Dunning frequency Dunning interval Set dunning level Interest key Update key Creditworthiness Optional dunning level Payment deadline Alt. days in arrears / dunning frequency
Amount limits per dunning level
Only items dunned in previous level
SAP AG 2003
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.
© SAP AG
IUT240
10-12
Dunning: Configuration (3)
Dunning charges
Dunning charges schedule Charge category Currency key Dunning amount limit Dunning charge Percentage rate Transaction Document types for dunning charges
SAP AG 2003
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.
© SAP AG
IUT240
10-13
Dunning: Document Type and Transaction Determination
Charges schedule 01
Interest doc. Charges cat. 01
Amount
Doc. type: G1 MnTr: 0010 SbTr: 0010
Charges cat. 02
Charges cat. 03
Amount
Doc. type: G2 MnTr: 0010 SbTr: 0020
Def. values Doc. type
Amount
Doc. type: SP MnTr: 0010 SbTr: 0025
Doc. type: Z1 MnTr IMTr SbTr ISTr
SAP AG 2003
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.
© SAP AG
IUT240
10-14
Dunning Program: Parameters Date identifier Identification General Restrictions
Dunning parameters
Technical settings
Logs
Business partner
Issue date
Number of jobs
Problem class
Contract account
Payments included
Contract Company code
Net due date Dunning procedure
Free selections
Reconciliation key Start activity run
SAP AG 2003
© SAP AG
IUT240
10-15
Dunning Activities
Generate telephone list
Dunning run
Log
Request cash security deposit
Print dunning notice (directly)
or
Print dunning notice (container)
Dunning charges Dunning interest
Set dunning block
Disc. document
Start a workflow
Release to collection agency
Reset Installment plan
SAP AG 2003
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.
© SAP AG
IUT240
10-16
Dunning: Telephone Lists
CRM or non SAP call center system Dunning run with activity: Telephone list
Telephone list
Process telephone list FPDUTL
SAP AG 2003
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.
© SAP AG
IUT240
10-17
Dunning History
01/15/2003 800 USD 01/01/2003 800 USD 01/15/2003 1200 USD 01/30/2003 1500 USD
Header item for each dunning notice sent
4711 08/01/02 DL 4 200 USD 4712 08/15/02 DL 4 150 USD Every dunning-relevant item has an entry in the dunning history
4713 09/01/02 DL 3 250 USD ... 4729 01/16/03 DL 1 120 USD
SAP AG 2003
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.
© SAP AG
IUT240
10-18
Creation of Printout with Print Container Dunning notices Installment plan letter
Print container
Bank statement
Printout creation
Returns letter
...
SAP AG 2003
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.
© SAP AG
IUT240
10-19
Dunning and Collections: Collection Processing
Dunning Procedure Functions Collection Processing
Customizing
SAP AG 2003
© SAP AG
IUT240
10-20
Collection - Release Receivables for Collection Collection agency XY
Mass run: Release (FP03M)
FP03
Dunning activity (event 0350)
Item 1 BP 1 Item 2 BP 2 Item 3 BP 3
(FKK_COLL_AGENCY_RELEASE_0350)
Item 4 BP 4 ...
Mass run: Write-off
Total: 205,488 USD
(FP04M)
FP03D / FP03DM (submission)
Write-off (FP04)
Manual release (FP03E)
Status: Released
DFKKCOLL
SubDME mission file
SAP AG 2003
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).
© SAP AG
IUT240
10-21
Collection - Automatic Release: Parameters Date identifier Identification General Selections Business partner
Additional Selections Net due date
Contract account
Dunning level
Company code
Amount
Document number
Currency
Simulation run
Technical settings Number of jobs
Logs Problem class
dunning procedure Dunning level category Execution variant Item selection: With statistical With write-off
SAP AG 2003
If you specify an execution variant, you can determine further company-specific accruals/deferrals. You can store these accruals/deferrals in user exit 5015.
© SAP AG
IUT240
10-22
Collection - Automatic Submission Parameters Date identifier Identification Submission parameters
Technical settings
Business partner Contract
Also statistical
Number of jobs Problem class
Contract account Document number Company code Net due date
Also written-off
General Selections
Additional Selections
Amount Simulation run
Collection agency Submission reason Submission status
Logs
Submit additional items To collection agency Write file Payment form ID Total receivables to be submitted
SAP AG 2003
© SAP AG
IUT240
10-23
Collection Agency Payment - Incoming Payment Doc.
INKPS
4711
001
4711
002
58.00
4712
001
116.00
Amnt 58.00
Payment form 2345 Payment form 2346
Payment reference
Submission RFKKCOL2
Payment form 2347
Submission file
Doc. 4711 58.00
Doc.No. Item Amnt 4711 1 58.00 4711 2 58.00 4712 1 116.00
Collection agency XY Clear, write off...
Selection category for payment lot NRZAS
Collection agency file
BETRW
OPBEL
INKPS
OPBEL
BETRW
GPART
VKONT
GPART
BETRW
VKONT
BETRW
BETRW
BETRW
Payment lot RFKKCOPM
SAP AG 2003
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.
© SAP AG
IUT240
10-24
Collection: Information for Collection Agency
Collection agency XY
Partner switch
X
Clearing
X
Callback
X
Reversal
X
Information for collection agencies FPCI
DME Information file
Clearing reversal Returns
X
SAP AG 2003
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.
© SAP AG
IUT240
10-25
Dunning and Collections: Customizing
Dunning Procedure Functions Collection Processing
Customizing
SAP AG 2003
© SAP AG
IUT240
10-26
Dunning: Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Dunning notices Define Charge Categories for Dunning Define Document Types for Dunning Charge Categories Configure Charge Schedules for Dunning Procedure Define Specifications for Interest on Arrears Configure Dunning Activities Configure Dunning Procedure Define Dunning Grouping Categories Define Dunning Lock Reasons Define Time-Dependent Creditworthiness Ratings Interaction with Other Business Transactions Specifications for Automatically Deactivating Installment Plans
SAP AG 2003
© SAP AG
IUT240
10-27
Collection: Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Submission of Receivables to Collection Agencies Define Collection Agencies Define Submission Status Define Specs for Submission to External Collection Agencies Define Specifications for Collection Agency Charges Define Reasons for Receivables Callback Define Default Value for Callback Reasons Specifications for Forwarding Information to Collection Agencies
SAP AG 2003
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.
© SAP AG
IUT240
10-28
Dunning and Collections: Summary
z Dunning is used to request payment of overdue receivables. z There are two steps in dunning: The dunning proposal and dunning activity run. z Different dunning activities can be carried out. z Items can be submitted to external collection agencies.
SAP AG 2003
© SAP AG
IUT240
10-29
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:
© SAP AG
Dunning level
01 Payment reminder group ##
Days in arrears
7 days
Dunning frequency
7 days IUT240
10-30
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 © SAP AG
EUR (USD) IUT240
10-31
Amount limit
10
Dunning activities: Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
0006
Dunning activities:
1-2
Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
2
Activity
R004
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: Identifier:
02.05.2004 MAH## (DUN##)
Enter the following parameters: Date of issue: Company code: © SAP AG
02.05.2004 U100 (U300) IUT240
10-32
Business partner: Start active run:
PICA0910## (PI0901C0##) 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: Identifier:
02.06.2004 MAX## (DUX##)
Enter the following parameters: Date of issue: Company code: Business partner: Start active run:
02.06.2004 U100 (U300) PICA0910## (PI0901C0##) 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
© SAP AG
Submit the receivables from business partner PICA0910## (PI0901C0##) to the collection agency GELDHER (COLLECT_IT). IUT240
10-33
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
1
Unit:
Dunning and Collections
Topic:
Create Dunning Notices / Submit Receivables to Collection Agencies
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. © SAP AG
IUT240
10-34
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
© SAP AG
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 IUT240
10-35
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).
© SAP AG
IUT240
10-36
Interest Calculation
Contents: z Interest calculation terminology z Interest calculation functions z Interest calculation display z Customizing
SAP AG 2003
© SAP AG
IUT240
11-1
Interest Calculation: Overview
This unit will provide you with an overview of: z Interest terms z The display of interest calculation in the interest supplement z Functions for calculating interest for items, and integration with other functional areas z and Customizing of interest in sub-ledger accounting for contract accounts receivable and payable.
SAP AG 2003
© SAP AG
IUT240
11-2
Interest Calculation: Unit Objectives
At the conclusion of this unit, you will be able to: z Describe the interest calculation process z Use the functions of interest calculation z Understand the integration of the interest calculation function with other functions
SAP AG 2003
© SAP AG
IUT240
11-3
Interest Calculation: Overview Diagram Course Overview
Clearing control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
11-4
Interest Calculation: Business Scenario
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. z You perform interest calculation. z This results in a statistical posting of an interest document and creation of a letter for the business partner.
SAP AG 2003
© SAP AG
IUT240
11-5
Interest Calculation: Terminology
Interest Calculation Terminology Interest Calculation Functions Interest Calculation Display Customizing
SAP AG 2003
© SAP AG
IUT240
11-6
Business Transactions for Posting Interest Customer info. Interest simulation
Calculate and post interest
Mass interest run Cash sec. dep. interest Create installm. plan Dunning run IS-U Invoicing Advance paymt bonus
Item selection
Post interest doc.
Debit interest General Ledger relevant or statistical? Credit interest (relevant for General Ledger ) Interest notification
SAP AG 2003
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.
© SAP AG
IUT240
11-7
Interest Parameters
Transaction
Contract account
Dunning level
Select items for interest calculation
items
Interest key Determination of interest key
Functions for calculating and posting interest
Reference interest rates
Interest Calculation Rule ()
% Σ
exp.
SAP AG 2003
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 y 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. y If interest is calculated for an item in the dunning procedure, an interest key can be stored in the dunning level. y 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: y The reference interest rates (optional) y The analysis period
© SAP AG
IUT240
11-8
Interest Key
z Transfer days
Take into account the duration of the payment process
Base date for interest calculation = due date + transfer days
z Tolerance days
Number 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.
z Interest period or interest calculation frequency
The 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.
SAP AG 2003
© SAP AG
IUT240
11-9
Interest Calculation Rule z Interest calculation method (calendar) z Interest category (scaled interest, scaled interest category)
% Σ exp()
z Interest interval z Monthly interest calculation z Settings for
Rounding interest calculation
Scaled interest refers to the total amount
Interest calculation with interest calculation numerators
z Interest rates are stored for each currency and debit/credit indicator z Interest rates can be based on a reference interest rate
SAP AG 2003
© SAP AG
IUT240
11-10
Amount Limit Check
Amount limits
Interest Items (after summarization)
Amount limit check
Items that cannot be posted according to the check
Items that can be posted
Functions for calculating and posting interest
SAP AG 2003
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.
© SAP AG
IUT240
11-11
Interest Calculation: Functions
Interest Calculation Terminology Interest Calculation Functions Interest Calculation Display Customizing
SAP AG 2003
© SAP AG
IUT240
11-12
Interest Calculation: Individual Processing
Enter Selection parameters (BP, contract acct)
Post interest
Posting parameters Letter Print
Item selection criteria (e.g. debit/credit item)
Line items Item selection screen
Display interest
Select items
Display variant Sort/total Save list ...
SAP AG 2003
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.
© SAP AG
IUT240
11-13
Automatic Interest Run: Parameters Date identifier Identification General Restrictions
Free Selections
Posting parameters
Business partner
Issue date
Contract acct
Posting date
Company code Interest Key Currency
Simulation run
Interest parameters Debit items Credit items
Technical settings
Logs
Number of jobs
Problem class
Debit and credit items
Doc. type Statistical key
Open items Cleared Items
Reconciliation All items key Calculate interest to Create corresp.
SAP AG 2003
© SAP AG
IUT240
11-14
Additional Functions
Print interest notification retrospectively
Interest on cash security deposits Clearing restrictions
Interest calculation Debit int. calc. CHECK: Credit items available?
Mass interest calculation Cash security deposits
SAP AG 2003
© SAP AG
IUT240
11-15
Interest Calculation: Installment Plan Interest calculation Enter Selection parameters Posting parameters Installment plan parameters (default values)
Print letter
Select open items
Determine interest amount, Create interest document, and include in installment plan
Change installment amounts and due dates Add installments Delete installments Change installment plan parameters
SAP AG 2003
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.
© SAP AG
IUT240
11-16
Integration In Other Functions z Interest calculation for cash security deposits
Own transaction / own mass run
Integrated into IS-U Invoicing
Implemented as credit interest calculation, but restricted to cash security deposits
z 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 moveout date, and the repayment/settlement of the cash security deposit payment and the cash security deposit interest is triggered.)
z Dunning run (only debit interest on open items)
No interest letter from the dunning run; interest is included on the dunning notice
SAP AG 2003
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.
© SAP AG
IUT240
11-17
Interest Calculation: Display
Interest Calculation Terminology Interest Calculation Functions Interest Calculation Display Customizing
SAP AG 2003
© SAP AG
IUT240
11-18
Interest Supplement Display the interest supplement from the items display screen
Document Display: Display Item Document
Edit
Goto
Settings
Extras
Environment
System
Help
Interest Supplement Interest History
Document no.:
Items charged interest and changes in interest
4711
Item 2 Display interest schedule for item 0002 of document 4711 Due date specifications Source doc. number Net due date 05/01/1998 From date Cash discount due date 04/15/1998
Currency Deferral to To date
05/20/1998Amount of item Int. rate
4712 01/01/2001
USD 05/01/2001
4.000000
4713 01/25/2001
USD 05/03/2001
3.000000
Int. amount
200.00 2.69 400.00 3.30
SAP AG 2003
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: y Interest rates y Periods y Source items y Interest amount
© SAP AG
IUT240
11-19
Interest Calculation: Customizing
Interest Calculation Terminology Interest Calculation Functions Interest Calculation Display Customizing
SAP AG 2003
© SAP AG
IUT240
11-20
Interest Calculation: Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Interest Calculation Item Interest Calculation Define Reference Interest Rates Define Percentage Rates for Reference Interest Rates Define Interest Calculation Rules Define Interest Key Maintain Amount Limits for Debit/Credit Interest Define Interest Lock Reasons Define Specifications for Interest Calculation Activate Additional Functions for Interest Calculation Define Clearing Reasons for Which Interest is not Calculated Define Specifications for the Mass Run
SAP AG 2003
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: y Interest calculation based on net amounts y 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.
© SAP AG
IUT240
11-21
Interest Calculation: Summary
z Interest calculation can be carried out for individual items. z The interest key and interest calculation rule are the most important parameters in interest calculation. z Interest calculation can be integrated into other business processes.
SAP AG 2003
© SAP AG
IUT240
11-22
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: Posting date: Business partner: Currency: Debit item: All items: Calculate interest to:
Today’s date Today’s date PICA1010## (PI1001C0##) EUR (USD) X X 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: ______________________________
© SAP AG
IUT240
11-23
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: Identifier: Business partner: Type of correspondence: Print parameters:
Today’s date K10## ## = Group number PICA1010## (PI1001C0##) 0007 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. © SAP AG
IUT240
11-24
© SAP AG
IUT240
11-25
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.
© SAP AG
IUT240
11-26
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: Correspondence selection: Correspondence type: Print parameters Output device: Logs Log class:
PICA1010## (PI1001C0##) 0007 LT0Q 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
© SAP AG
IUT240
11-27
Deferral/Installment Plan
Contents: z Deferral z Installment Plan z Customizing
SAP AG 2003
© SAP AG
IUT240
12-1
Deferral/Installment Plan: Overview
This unit will provide you with an overview of the following in FI-CA subledger accounting: z The deferral of open items z Installment plan agreements
SAP AG 2003
© SAP AG
IUT240
12-2
Deferral/Installment Plan: Unit Objectives
At the conclusion of this unit, you will be able to: z Defer open items z Create an installment plan z Deactivate an installment plan
SAP AG 2003
© SAP AG
IUT240
12-3
Deferral/Installment Plan: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
12-4
Deferral/Installment Plan: Business Scenario
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. z An open receivable for a small amount is deferred. z An installment plan is arranged for an open receivable for a larger amount; payments are distributed over different due dates in the future.
SAP AG 2003
© SAP AG
IUT240
12-5
Deferral/Installment Plan: Deferral
Deferral
Installment Plan
Customizing
SAP AG 2003
© SAP AG
IUT240
12-6
Deferral
Document - post Document - change
Manual
1400.00
Deferral Amount due: 1400
Returns activity Î Deferral days
Old due date 05/01/2003
New due date 06/20/2003
Time
Automatic
SAP AG 2003
The deferral does not change the original due date. Deferral can be performed manually in the document change transaction or automatically during returns processing.
© SAP AG
IUT240
12-7
Deferral/Installment Plan: Installment Plan
Deferral
Installment Plan
Customizing
SAP AG 2003
© SAP AG
IUT240
12-8
Installment Plan
Inst. plan - Create Inst. plan - Change
Interest Calculation Installment plan
Manual
Installment plan charges
Installment plan Amount due: 1000
Dunning activity Î Deactivation
Inst. plan parameters
250.00
(e.g. repayment Old due date plan)
Automatic
250.00
250.00
New due dates
250.00
Time
Letter Installment plan
SAP AG 2003
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.
© SAP AG
IUT240
12-9
Installment Plan Parameters 1
Inst. plan category 2
Inst. amount or number of installments 3
Rounding amount
Installment plan
Rem. Amount 4 Inst. interval 1 First inst. 2 Last inst. 5 Interval category 3 New inst.
01/10 Inst. 1 100 02/10 100 .............................100 12/10/ 100
6 Charges amount 7
Memos Status Open Deactivated Balanced Overdue interest
Account balances Open: 500 USD Due: 480 USD Credit: 0 USD
SAP AG 2003
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.
© SAP AG
IUT240
12-10
Create Installment Plan: Workflow Enter Selection parameters Posting parameters Installment plan parameters (default values)
Print letter
Interest Calculation Charges
Installment plan charges
Change installment amounts and due dates
Select open items
Add installments Delete installments Change installment plan parameters SAP AG 2003
© SAP AG
IUT240
12-11
Installment Plan: Document Structure Business partner items
1 Sample record
OPBEL OPUPK WHGRP 4711
1
Repetition items
BETRW Sample1 (repaym.)
10.00
e.g. 12 Installments
OPBEL OPUPW WHGRP
FAEDN
4711
1
1
1. Due date
01/01/
4711
2
1
2. Due date
02/01/
4711
12
1
12. Due date
12/01/
SAP AG 2003
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
© SAP AG
IUT240
12-12
Example Business partner items OPBEL OPUPK WHGRP 4710
1
4711
1
BETRW ABWTP ABWBL Source receivable
1
Sample1 (repaym.)
120.00
R
4711
10.00
Repetition items OPBEL OPUPW WHGRP
FAEDN
4711
1
1
1. Due date
01/01/
4711
2
1
2. Due date
02/01/
4711
12
1
12. Due date
12/01/
SAP AG 2003
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
© SAP AG
IUT240
12-13
Installment Plan: Interest Calculation
500 USD
Customer calls and requests payment in installments
Installment is created
Item is replaced by installment plan
Time Source items Post item
Due item
Due date of 1st installment Due date of 2nd installment ...
Installment plan
10 USD
1st Inst.
10 USD
2nd Inst.
10 USD
3rd Inst.
10 USD
4th Inst.
10 USD
5th Inst.
Interest on items in arrears Interest on interval of installment plan
Start date of installment plan
SAP AG 2003
© SAP AG
IUT240
12-14
Deferral/Installment Plan: Customizing
Deferral
Installment Plan
Customizing
SAP AG 2003
© SAP AG
IUT240
12-15
Installment Plan: Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Deferral and Installment Plan Define Default Values for Installment Plan Categories for Installment Plan Define Installment Plan Category Define Interest Key Define Default Values for Installment Plan Charges Define Default Values for Interest on the Installment Plan Deactivation Reasons for Installment Plan
SAP AG 2003
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).
© SAP AG
IUT240
12-16
Deferral/Installment Plan: Summary
z You can defer open items manually or automatically in returns processing. z The installment plan distributes open receivables over several installments in the future. z Interest can be calculated as part of the installment plan. z You can deactivate an installment plan. z You can deactivate an installment plan manually or automatically through a dunning activity.
SAP AG 2003
© SAP AG
IUT240
12-17
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.
© SAP AG
IUT240
12-18
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: Contract account: Currency: Posting date
PICA1110## (PI1101C0##) PICA1110## (PI1101C0##) EUR (USD) 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: ___________________________
© SAP AG
IUT240
12-19
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.
© SAP AG
IUT240
12-20
Other Business Transactions
Contents: z Account Maintenance z Reversal of Documents z Clearing Reset z Document Transfer z Mark as doubtful / Individual Value Adjustment z Write-Off z Customizing
SAP AG 2003
© SAP AG
IUT240
13-1
Other Business Transactions: Overview
This unit will provide you with an overview of the following for subledger accounting in FI-CA: z The options in account maintenance z The reversal of documents z Clearing reset z Transfer posting of documents z Marking documents as doubtful entries and individual value adjustment z Writing off documents
SAP AG 2003
© SAP AG
IUT240
13-2
Other Business Transactions: Unit Objectives
At the conclusion of this unit, you will be able to: z Describe how account maintenance is used z Describe the options for reversing documents within sub-ledger accounting z Be familiar with the functions for uncollectible receivables z Specify and configure the basic system settings
SAP AG 2003
© SAP AG
IUT240
13-3
Other Business Transactions: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
13-4
Other Business Transactions: Business Scenario (1)
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. z The credit is cleared against the receivable. z The payment that was allocated incorrectly is reversed and posted as a payment on account.
SAP AG 2003
© SAP AG
IUT240
13-5
Other Business Transactions: Business Scenario (2)
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. z The accounting clerk implements the steps for marking these items as doubtful.
SAP AG 2003
© SAP AG
IUT240
13-6
Other Business Transactions: Account Maintenance
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-7
Account Maintenance in FI-CA
Cash desk Manual
Acct Maintenance general
Invoicing Automatic
C l e a r i n g C o n t r o l
Incoming lot
Open items: Clearing 05/10/03 150.00 05/08/03
70.00
05/22/03 200.00 -
150.00 50.00 200.00 -
05/19/03 123.00 -
Difference: 0.00
SAP AG 2003
© SAP AG
IUT240
13-8
Account Maintenance: Process
Business partner: Contract account: Due: 05/28/05
1740
Open items
Open items: Clearing
Proposal
Clearing control
150.00
150.00
70.00
50.00
200.00 -
200.00 Difference: 0.00
SAP AG 2003
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.
© SAP AG
IUT240
13-9
Automatic Clearing: Parameters Date identifier Identification General Restrictions
Posting parameters
Technical settings
Logs
Business Partner
Clearing reason
Number of jobs
Problem class
Contract acct
Doc. type
Company code
Posting date
Net due date
Document date Reconciliation key
SAP AG 2003
© SAP AG
IUT240
13-10
Other Business Transactions: Reversal of Documents
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-11
Reversal of Documents: Restrictions
Reversal not possible
Invoicing documents Documents for which interest has been calculated Installment/budget billing documents SD documents External billing documents
SAP AG 2003
© SAP AG
IUT240
13-12
Reversal of Documents Document header Document no: 010000234591 Document no.: Posting date: 02/22/03 Posting date: Doc. type: F1 Currency: USD Reversal Doc. type: S1 Reconciliation key: 03022201/SK1 Reconciliation key: Reversed with: 102345678 Reversal doc. for:
102345678 03/05/03 Currency: USD 03022201/SK1 010000234591
Business partner items BPART CCODE 4711 U100 Clearing doc:
Due 02/22/03 102345678
Amount 230.00 AG: 05
G/L Account Items/Tax Items CCODE G/L Acc. U100 800000 U100 175000
BA Cost Cent.
Amnt 200.00 30.00 -
CCODE G/L Acc. U300 800000 U300 175000
BA Cost Cent.
Amnt 200.00 30.00
Cleared items BPART CCODE 4711 U100
Division 01
Amount 230.00 -
SAP AG 2003
Document to be reversed: y After reversal, the business partner items have the clearing document number of the reverse document. Indicator: reverse document: y Reference to the reversed document using the document number from the reversed document in the document header. y In the reversal document, an item is created for every G/L. These items have the opposite +/- sign to the G/L item.
© SAP AG
IUT240
13-13
Mass Reversal: Parameters Selection: Reconciliation key Document No. Reference document Posting date Document date Doc. type Agent
Mass reversal
Entry date
Activities
Count documents
Display documents
Reverse documents Posting parameters: Reconciliation key Reversal date Doc. type Clearing reason SAP AG 2003
© SAP AG
IUT240
13-14
Other Business Transactions: Clearing Reset
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-15
Clearing Reset
Bill: 100.00 USD
Bill outstanding: 100.00 USD
Payment: -100.00 USD
Payment on account: -100.00 USD
Allocation and clearing
Clearing reset
SAP AG 2003
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
© SAP AG
IUT240
13-16
Other Business Transactions: Transfer of Documents
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-17
Document Transfer Selection specifications
Target of transfer posting Business partner Contract account Contract
Business Partner Contract account Contract Document number Reference document no.
Open
Cleared
Open
Receivables account, due date, transaction description Dunning and interest information are copied
SAP AG 2003
You can only transfer open receivables or credits. You can transfer the following: y Individual items - receivables and credit y All items of a business partner y All items of a contract account y All items of a contract y 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. y 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.
© SAP AG
IUT240
13-18
Other Business Transactions: Mark as Doubtful / Individual Value Adjustment
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-19
Mark as doubtful / Individual Value Adjustment
Mark as doubtful: 38.-FI doc:: #0815 Mass run transfer posting of corrected receivables
Document: 4711 Amount 58 Open: 38
38.-16.38
38.-16.38
Individual value adjustment 50% net 16.38--
FI-CA doc.
FI-CA Documents Summary Records
FKKZW
FI document
SAP AG 2003
© SAP AG
IUT240
13-20
Mark as Doubtful/Individual Value Adjustment: Posting Example:
Contract acct [1] 58.-
20.- [3]
Receivables [1]
58.--
20.--
Revenue [3]
50.--
20.--
Doubtful receivable [4] 38.--
Tax account [1]
8.--
[1]
Cash clearing
Bank [2]
FI-CA
Receivable 58 Tax rate: 16% Partial payment: 20 USD 50% value adjustment
[3]
20.-- 20.--
DR correction
[2]
Adjustment account Individual value adjustment
38.-- [4]
16.38 [5]
IVA expense
[5] 16.38
FI SAP AG 2003
Posting records: y 1. Issuing a bill y 2. Posting incoming payment in general ledger accounting (bank statement) y 3. Payment posting in sub-ledger accounting and allocation of the payment y 4. Marking the receivable as doubtful y 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.
© SAP AG
IUT240
13-21
Mass Run for Automatic Doubtful Entries and Individual Value Adjustment: Parameters Date identifier Identification General Restrictions
Selection
Technical settings
Logs
Business partner
Select open/ adjusted items
Number of jobs
Problem class
Contract acct Company code
Simulation
Delimitation date Posting date Reason for MAD/IVA Value adjustment variant Value adjustment reversal
SAP AG 2003
© SAP AG
IUT240
13-22
Other Business Transactions: Write-Off
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-23
Manual Write-Off: Process Check level BP Account Contract Doc.
... ... ...
... ...
Special authorization: Check rules not used Expense account 50 Tax account
Check rules ?
8
- No credit available ... Event: 5010
optional
Release for collection
SAP AG 2003
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.
© SAP AG
IUT240
13-24
Automatic Write-Off: Parameters Date identifier Identification Posting parameters
Technical settings
Business partner Amount
Posting date
Number of jobs Problem class
Contract account dunning level
Company code
Extra log
Currency
Proration
General Selections
Company code Document no. Reference document no.
Additional Selections
Dunning procedure Dunning level category Net due date
Simulation run
Transaction
Logs
Clearing reason Write-off reason Doc. type Further details
Execution variant
SAP AG 2003
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
© SAP AG
IUT240
13-25
Write-Off: Posting 1 Example:
Contract acct [1] 58.--
20.-- [3] 38.-- [4]
Receivables [1] 58.--
Revenue 50.--
20.-- [3] 38.-- [4]
Bank [2] 20.--
Receivable 58 Tax rate: 16% Partial payment: 20 USD 50% value adjustment Write off receivable
Tax account [1]
20.--
[4] 5.24
8.--
[1]
Sales deduction
Cash clearing [3] 20.--
FI-CA
[2]
[4] 32.76
FI SAP AG 2003
Posting records: y 1. Issue a bill y 2. Post incoming payment in general ledger accounting y 3. Post payment in sub-ledger accounting and allocate the payment y 4. Write off the open item
© SAP AG
IUT240
13-26
Write-Off: Posting 2 Contract acct [1] 58.--
[2] 20,--
Revenue
20.-- [3] 38.-- [4]
Bank
FI-CA
Receivable: 58 Tax rate: 16% Partial payment: 20 USD 50% value adjustment Write off receivable
20.-- [3] 38.-- [6]
Receivables [1] 58.--
Example:
50.--
Tax account [1]
Cash clearing [3] 20.--
Doubtful receivable DR correction [7] 38.-[4] 38.-- 38.-- [7] 38.-- [4]
20.--
[6] 5.24
8.--
[1]
Sales deduction [2]
[6] 32.76
Individual value adjustment [8] 16.38 16.38 [5]
IVA expense [5] 16.38 16.38 [8]
FI SAP AG 2003
Posting records: y 1. Issue a bill y 2. Post incoming payment in general ledger accounting (bank statement) y 3. Post payment in sub-ledger accounting and allocate the payment y 4. Mark the receivable as doubtful y 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. y 6. Write off the open item y 7. Reset doubtful entry y 8. Reset IVA
© SAP AG
IUT240
13-27
Write-Off History
Selection options - No reversed items - No statistical items WrOffdoc. Doc.
...
Amnt
WrO
Date
STAKZ Srce Reversal
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
X
...
Display variant SAP AG 2003
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.
© SAP AG
IUT240
13-28
Other Business Transactions: Customizing
Account Maintenance
Mark as Doubtful / Individual Value Adjustment
Reversal of Documents
Write-Off
Clearing Reset
Customizing
Document Transfer
SAP AG 2003
© SAP AG
IUT240
13-29
Account Maintenance - Customizing
IMG Contract Accounts Receivable and Payable Basic Functions Open Item Management Define Default Values for Account Maintenance Define Default Values for Automatic Clearing Clearing Control Business Transactions Automatic Clearing Grouping Variants Define Grouping Characteristics Define Grouping Variants Define Specifications for Automatic Clearing
SAP AG 2003
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.
© SAP AG
IUT240
13-30
Reverse / Reset Clearing: Customizing
IMG Contract Accounts Receivable and Payable Basic Functions Open Item Management Define Default Values for Resetting Clearing Define Default for Resetting Clearing
Business Transactions Reversal Define Alternative Accounts for Reversal in Following Year Define Default Values for Reversal Define Specifications for Clearing Item
SAP AG 2003
© SAP AG
IUT240
13-31
Transfers - Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Transfers Define Transfer Reasons Define Specifications and Default Values for Transfer Define Transactions for Transferring items
SAP AG 2003
© SAP AG
IUT240
13-32
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 Doubtful Items and Individual Value Adjustment Maintain Correction Reasons Maintain Correction Reset Reasons Maintain Exceptions for Adjustments Maintain Account Determination for Doubtful Item Entries Maintain Account Determination for Ind. Value Adjustment Maintain Value Adjustment Variants for Automatic Adjustments Maintain Processing Methods for User Exits for Automatic Adjustments Maintain Default Values for Transfer Posting Run
SAP AG 2003
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: y Manual doubtful entry or value adjustment y Automatic doubtful entry or value adjustment y 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.
© SAP AG
IUT240
13-33
Write-Off: Customizing
IMG Contract Accounts Receivable and Payable Basic Functions Particular Aspects of Taxation Procedure Tax Adjustment for Write Off Define Tax Calc. Types Write-Offs and Ind. Val Adj. Define Change in Tax Code with Write-Offs Business Transactions Write-Off Define Write-Off Reasons Define Specifications and Default Values for Write-Off Define Specifications and Defaults for Mass Write-Offs Automatic G/L Account Determination for Write-Offs Define Execution Variants for Mass Write-Offs
SAP AG 2003
You should only enter an execution variant if the event 5015 has been defined.
© SAP AG
IUT240
13-34
Other Business Transactions: Summary
z Account maintenance enables you to clear credits against open receivables. z You can reverse incorrect documents. z You can use the "reset clearing" function to process payments that have been allocated incorrectly. z You can transfer receivables and credits to another business partner. z You can mark uncollectable receivables as doubtful, adjust the individual value and then finally write it off.
SAP AG 2003
© SAP AG
IUT240
13-35
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: Contract account: Company code: Currency: Posting date
PICA1210## (PI1201C0##) PICA1210## (PI1201C0##) U100 (U300) EUR (USD) Today’s date
Instruct the system to generate a clearing proposal. Check the proposal and post the clearing. Write down the document number: ______________________________
© SAP AG
IUT240
13-36
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: Contract account: Posting date: Currency: Clearing reason: Write-off reason:
PICA1210## (PI1201C0##) PICA1210## (PI1201C0##) Today’s date EUR (USD) 04 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.
© SAP AG
IUT240
13-37
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.
© SAP AG
IUT240
13-38
Security Deposits
Contents: z Cash and non-cash security deposits z Customizing
SAP AG 2003
© SAP AG
IUT240
14-1
Security Deposits: Overview
This unit will provide you with an overview of: z The request for cash and non-cash security deposits z Non-cash security deposits z The request, payment and settlement of cash security deposits
SAP AG 2003
© SAP AG
IUT240
14-2
Security Deposits: Unit Objectives
At the conclusion of this unit, you will be able to: z Enter non-cash security deposits in the system z Request cash security deposits in the system z Post incoming payment to requests for cash security deposits z Explain how a cash security deposit is settled against other receivables
SAP AG 2003
© SAP AG
IUT240
14-3
Security Deposits: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
14-4
Security Deposits: Business Scenario
You assess the credit rating of your business partner such, that you agree on cash security deposits for this business partner. z A request for cash security deposit is created for the business partner in the system. z After the incoming payment, the request for cash security deposit is cleared and accounted for as a down payment.
SAP AG 2003
© SAP AG
IUT240
14-5
Security Deposits: Cash and Non-Cash Security Deposits
Cash and non-cash security securitydeposits deposits Customizing
SAP AG 2003
© SAP AG
IUT240
14-6
Security Deposits 1
CityBank
Non-cash security deposit
Four hundred€
- 400,-
Security deposit request
To Der vorg edr uckt e Sch eckt ext d arf n icht g eän dn.
Account No. X 12131400 X 00000150900
X
X 67291500 11
Security deposit payment
Guarantee of payment
FI-CA FI
Received security deposits SAP AG 2003
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.
© SAP AG
IUT240
14-7
Security deposit Request
Security deposit payment
Interest Calculation
Cash Security Deposits
Release or IS-U invoicing
FI-CA FI Received Interest security deposits payables
Receivable from (final) bill
SAP AG 2003
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.
© SAP AG
IUT240
14-8
Security Deposits: Posting - 1 Contract account [1] 50.--
FI-CA
Sec. deposits received
Revenue account
Bank
Cash clearing
Receivables
Tax account
FI SAP AG 2003
[1] Posting the request for the cash security deposit in FI-CA: y The cash security deposit is posted statistically so that no transaction relevant to the general ledger is generated. y A notification containing the requested amount, the terms and methods of payment, etc. for a security deposit can be generated.
© SAP AG
IUT240
14-9
Security Deposits: Posting - 2 Contract account [1] 50.--
[2]
FI-CA
Sec. deposits received
Revenue account
Bank
Cash clearing
50.--
Receivables
50.--
[2]
Tax account
FI SAP AG 2003
[2] Posting incoming payment in FI. The business partner pays by bank transfer.
© SAP AG
IUT240
14-10
Security Deposits: Posting - 3 Contract account ([1]
50.-- 50.-0.--)
FI-CA
[3]
Sec. deposits received 50.-- [3]
Revenue account
Cash clearing
Bank [2]
50.--
Receivables
[3]
50.-- 50.--
[2]
Tax account
FI SAP AG 2003
[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.
© SAP AG
IUT240
14-11
Security Deposits: Posting - 4 Contract account ([1]
50.-- 50.-0.--) 50.-[4] 116.--
FI-CA
[3] [4]
Sec. deposits received [4] 50.-- 50.-- [3]
Revenue account
Bank
Cash clearing
[2]
50.--
[3]
50.-- 50.--
[2]
Tax account
Receivables [4] 116.-- 50.--
100.-- [4]
[4]
16.--
[4]
FI SAP AG 2003
[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.
© SAP AG
IUT240
14-12
Security Deposits: Customizing
Cash Cash and and non-cash non-cash security security deposits deposits Customizing
SAP AG 2003
© SAP AG
IUT240
14-13
Security Deposits: Customizing
IMG Contract Accounts Receivable and Payable Business Transactions Security deposits Define Number Ranges for Security Deposits Define General Parameters for Security Deposits Create Special Definitions for Security Deposits Define Request Reasons for Security Deposits Define Status of Non-Cash 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 Deposits Maintain 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 SAP AG 2003
© SAP AG
IUT240
14-14
Security Deposits: Summary
z In contract accounts receivable and payable, a distinction is made between cash and non-cash security deposits. z You can only enter a cash security deposit if a request for a security deposit has been created. z 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.
SAP AG 2003
© SAP AG
IUT240
14-15
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: Contract account: Type of security deposit: Reason for request: Requested amount: Start date:
PICA1210## (PI1301C0##) PICA1310## (PI1301C0##) Cash security deposit Payment history 500.00 EUR (USD) 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:___________________________
© SAP AG
IUT240
14-16
1-1-2 Now pay the cash security deposit request at the cash desk. Use the following information: Amount: Company code: Bank clearing account: Fixed value date: Posting date: Document date:
500.00 EUR (USD) U100 (U300) 113100 2nd April.2004 2nd April 2004 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?
© SAP AG
IUT240
14-17
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.
© SAP AG
IUT240
14-18
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.
© SAP AG
IUT240
14-19
Integration
Contents: z FI-CA Integration in SAP Applications z Customizing
SAP AG 2003
© SAP AG
IUT240
15-1
Integration: Unit Objectives
At the conclusion of this unit, you will be able to: z Describe the embedding of the contract accounts receivable and payable in the SAP Business Suite applications
SAP AG 2003
© SAP AG
IUT240
15-2
Integration: Overview Diagram Course Overview
Clearing Control
Introduction
Dunning and Collections
Documents
Interest Calculation
Account Balance Display
Deferral/Installment Plan
Transactions and Account Determination
Other Business Transactions
Payment
Security Deposits
Returns Processing
Integration
Incoming Payments / Clarification Processing SAP AG 2003
© SAP AG
IUT240
15-3
Integration: Business Scenario
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.
SAP AG 2003
© SAP AG
IUT240
15-4
Integration: Overview
CO-PA
Business Information Warehouse
CO
IS-U Invoicing
FI-GL FI-CA
SD Invoicing
Customer Relationship Management mySAP Financials
Ext. Billing Systems
Dispute Mgmnt. Biller Direct
TR-CM
Treasur y & Risk Mgmnt
COEC IM FI RE TM
Biller Consoledator Credit Mgmnt.
In-House Cash
FSCM
SAP AG 2003
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.
© SAP AG
IUT240
15-5
Integration with Treasury: Planning Group z Classifies planned revenues and expenditures for updates in the Cash Management (TR-CM) application component. z 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.
Planning group
FI-CA Doc.
Additional days for cash management and forecast
FI
SAP AG 2003
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: y Included in the debit memo procedure y 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: y 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. y Additional days provide a reference value for deviation from the due date.
© SAP AG
IUT240
15-6
Treasury: Determination of Planning Level Determining the planning level: Contract account Master record
Planning group
Planning level
FI-CA transaction
Alternative planning level for transaction
Payment lock
Alternative planning level for payment block
SAP AG 2003
© SAP AG
IUT240
15-7
Business Partner: SD Customer and BP in FI-CA z 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
z A standard customer is created based on a predefined reference customer z Different integration scenarios are possible:
You can post SD invoices in FI-CA
SD invoicing requests can be integrated in an IS-U invoice
SAP AG 2003
© SAP AG
IUT240
15-8
FI/CO Interface
FI-GL CO-PA FI-AR CO-... FI-SL ...
EC-PCA
FI-GL
FI/CO Interface
ch ro As yn
FI-CA
no us
Sy nc hr
SD Invoice
on ou s
FI / SD Integration: Standard Process
CO-... CO-PA EC-PCA ... CO-PA
SAP AG 2003
© SAP AG
IUT240
15-9
Integration: SD Invoicing Document FI-AR
Doc. type PosAr 1210
FI-CA Contract account
SD
In vo ice
SD Invoice
Ac co un t
typ e
gro up
FI customer
IS-U Invoicing request SD Invoicing Category "U"
IS-U Invoice Doc. type PosAr R400
IS-U Billing
SAP AG 2003
© SAP AG
IUT240
15-10
SAP FSCM: Biller Direct
WWW WWW
E -Mail E-Mail
Customer
Account
Account
Bill
SAP AG 2003
© SAP AG
IUT240
15-11
Business Information Warehouse (BW)
SAP AG 2003
© SAP AG
IUT240
15-12
BW: Data Extraction, Transformation, and Presentation InfoCube
Update rules InfoSource Transfer rules BW
Transfer structure DataSource
BEx
Mass run DataSource Customer enhancement Operative data OLTP
Data extract SAP AG 2003
© SAP AG
IUT240
15-13
BW: Business Content FI-CA
Cleared items
Installment plans
Open items
Submission to collection agencies SAP AG 2003
© SAP AG
IUT240
15-14
CRM Integration: Business Agreement z Master data at business partner level for controlling accounting processes in FI-CA z Resembles the contract account in FI-CA (less data) z The data is:
Terms of payment
Dunning control
Correspondence control
Tax
z You can determine the maximum number of business partner agreements for each business partner in Customizing z You can group different types of business agreements in business agreement classes
SAP AG 2003
© SAP AG
IUT240
15-15
CRM – CFM: What is Financial Customer Care? Customer Relationship Management Marketing & Sales
Customer Financials Management Collections Management
Service & Customer Care Contract Management
Receivables Management Credit Management
Dispute Management
Profitability Analysis …
…
Billing
Æ Seamless integration of all finance-relevant data in communication with customers Æ Based on standard Interaction Center functionality SAP AG 2003
© SAP AG
IUT240
15-16
Contents of Financial Customer Care z Business partner data (name, address,...) z Contract account data (such as, payment method, disconnections, correspondence settings) z
Account balances
z
Open items
z
Bills
z
Payments
z
Carry forward balance
z
Dunning notices
z
Installment plans
SAP AG 2003
© SAP AG
IUT240
15-17
Integration: Customizing
IMG Financial Accounting Contract Accounts Receivable and Payable Integration SD Customer Relationship Management Financial Supply Chain Management General Ledger Accounting Controlling Cash Management Business Information Warehouse
SAP AG 2003
© SAP AG
IUT240
15-18
Integration: Summary
z Contract accounts receivable and payable is integrated in all classic SAP components, as well as the Web-based SAP applications. z Further development of these components include the integration for FI-CA.
SAP AG 2003
© SAP AG
IUT240
15-19
Appendix
Contents: z Appendix 1: IS-M Special Features z Appendix 2: IS-T Special Features z Appendix 3: IS-U/CCS Special Features
SAP AG 2003
© SAP AG
IUT240
16-1
Appendix 1: IS-M Special Features
Contents: z IS-M/SD Connection to IS-M/CA z Renewal Subscriptions z Service Settlement
SAP AG 2003
© SAP AG
IUT240
17-1
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
SAP AG 2003
© SAP AG
IUT240
17-2
IS-M/SD Connection to IS-M/CA: Overview
Contract Accounts Receivable and Payable
Media Sales and Distribution Order Item
Contract Account
Invoice Item Account Assignment Data
Transfer Doc.Type Transaction Receivables Account
Doc. Source: Media Sales and Distribution
General Ledger FI-GL Transfer FI-GL
SAP AG 2003
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.
© SAP AG
IUT240
17-3
Contract Account Determination in Order I Order
Business Partner
GP1 Contract account 1 Contract account 2
Payer: GP1 determination tract account Contract account determination Input help Contract account 1
Contract account 3
Contract account 2 Contract account 3
SAP AG 2003
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.
© SAP AG
IUT240
17-4
Contract Account Determination in Order II Order
Business Partner
GP1 Contract account 1
Payer: GP1 Contract account determination
Contract account 2
Automatic allocation
Contract account 3
Controlled by user exit
SAP AG 2003
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.
© SAP AG
IUT240
17-5
Contract Account Determination in Order III Order
Business Partner
GP1 Contract account 1 Contract account 2
Payer: GP1 Contract account determination Create contract account
Contract account 3
SAP AG 2003
If no contract account exists for the payer, you can create a contract account in the dialog.
© SAP AG
IUT240
17-6
Payment Methods in Contract Account
Contract Accounts Receivable and Payable
Media Sales and Distribution Order Item
Invoice Item
Automatic Debit
Automatic Debit
Doc. Transfer
Contract Account Automatic Debit with Bank Details
Payment Run Automatic Debit with Bank Details
SAP AG 2003
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.
© SAP AG
IUT240
17-7
Different Payment Methods in Order
Contract Accounts Receivable and Payable
Media Sales and Distribution Order Item
Invoice Item
Automatic Debit
Automatic Debit
Doc. Transfer
Automatic Debit
Contract Account
Payment Run
Bill
Automatic Debit
SAP AG 2003
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: y You select a payment method different to the contract account. y 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: y 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. y The the terms of payment must be defined and valid for the whole month. y Installment payment conditions are not supported. y 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.
© SAP AG
IUT240
17-8
Payment Method: Cash Payer
Contract Accounts Receivable and Payable
Media Sales and Distribution Order Item
Contract Account Cash payer
Invoice Header
Transfer + Payment Form Payment Form Number Number
Bill Payment Form
Doc. Document No.
Payment Form Table • Document No. • Payment Form Number
SAP AG 2003
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.
© SAP AG
IUT240
17-9
Deriving Transactions from IS-M/SD Information
Sales Document Type
Transaction
Item Type
Main Transaction Debit / Credit Indicator
Subtransaction
Represents a business transaction
Account Key
SAP AG 2003
© SAP AG
IUT240
17-10
Deriving the Receivables Account
Contract Accounts Receivable and Payable
Media Sales and Distribution Business Partner Receivables Account
Transfer Deriving the Receivables Account + User Exit
Doc. (BP Item)
Receivables Account
SAP AG 2003
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.
© SAP AG
IUT240
17-11
IS-M/SD Connection to IS-M/CA: Revenue Deferral
Contract Accounts Receivable and Payable
Media Sales and Distribution
General Ledger
Doc. (Summarized) Deferred Revenues
Transfer Doc.Type
Pure G/L Account Document
FI-GL Transfer
FI-GL
Source: Media Revenue Deferral
SAP AG 2003
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.
© SAP AG
IUT240
17-12
IS-M: Contract Accounts Receivable and Payable IS-M/CA: Renewal Subscriptions
IS-M/SD Connection to IS-M/CA Renewal Subscriptions Service Settlement
SAP AG 2003
© SAP AG
IUT240
17-13
Renewal Subscription - Customer Driven Payments
First Expiry Date
New Expiry Date
Order
Contract Account
t
Levels
Monitoring Period Renewal offer Reminders
Tolerance periods
2
Suspension Termination Resumption
Liability acct Liability acct Payment Amort. Payment Amort.
Billing
Billing Period covered by payment amount
Open Item
3 Payment
Period covered by new payment amount
IS-M/SD
1 Check Cash Payment Bank Transfer
IS-M/CA
SAP AG 2003
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.
© SAP AG
IUT240
17-14
Cancellation of Customer Driven Payments
First Expiry Date
New Expiry Date
Order
Contract Account
t
Levels
Monitoring period Renewal offer Reminders
Tolerance periods
Liability acct Liability acct Payment Amort. Payment Amort.
4
3 Billing
1X
Cancellation Item
Cancellation
Billing Period covered by payment amount
Open Item
Suspension Termination Resumption
Check Cash Payment Bank Transfer
Payment
Period covered by new payment amount
Refunding
IS-M/SD
2
IS-M/CA
SAP AG 2003
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.
© SAP AG
IUT240
17-15
Renewal Subscription - Company-Driven Payment
First expiry date
New expiry date
Order
Contract Account
t
Levels
Monitoring period Renewal offer Reminders
Tolerance periods
1
Suspension Termination Resumption
Liability acct Liability acct Payment Amort. Payment Amort.
Billing
Billing Period covered by payment amount
Open item
3 Payment
Period covered by new paymentamount
IS-M/SD
2 Credit card Direct debit
IS-M/CA
SAP AG 2003
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.
© SAP AG
IUT240
17-16
Cancellation of Company-Driven Payment – Change to Check / Cash
First expiry date
New expiry date
Order
Contract account
t
Levels
Monitoring period Renewal offer Reminders
Tolerance periods
Open items
Suspension Termination Resumption
Liability acct Liability acct Payment Amort. Payment Amort.
Billing
1X
Cancellation item
Cancellation
Billing Period covered by payment amount
4
3
Payment
Periods covered by new payment amount
Return
IS-M/SD
Credit card Direct debit
2
IS-M/CA
SAP AG 2003
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 ISM/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.
© SAP AG
IUT240
17-17
Payment Amount Reduced by Credit Note
First expiry date
New expiry date
Order
Contract account
t
Levels
Monitoring period Renewal offer
1a
Tolerance periods Suspension Termination Resumption
Billing of credit note
Billing
Complaint Liability acct suspension Payment Amort. Billing
Offer 60.00 -5.00
1b 3
Open item
Credit item
60.00
-5.00
Clearing
4
2a
Payment -55.00
55.00
IS-M/SD
2b Check Cash Payment Bank Transfer
IS-M/CA
SAP AG 2003
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).
© SAP AG
IUT240
17-18
IS-M: Contract Accounts Receivable and Payable IS-M/CA: Service Settlement
IS-M/SD Connection to IS-M/CA Renewal Subscriptions Service Settlement
SAP AG 2003
© SAP AG
IUT240
17-19
IS-M/SD Connection to IS-M/CA: Service Settlement
Media Sales and Distribution Employment relationship or service company
Contract account
Service settlement
Account Assignment Data
Contract Accounts Receivable and Payable
General Ledger
Transfer FI-GL Document + Doc. type FI-GL Source: + Transaction Transfer Service + Receivables settlement account
SAP AG 2003
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
© SAP AG
IUT240
17-20
IS- M Special Features: Summary
z The IS-M Media Sales and Distribution component processes sales of periodic publications (newspapers and magazines). The emphasis here is on processing subscriptions. z In IS-M/SD, it is also possible to settle services from employees or service companies. z Subscription and service settlement can be transferred to contract accounts receivable and payable. You can use media-specific functions to process debit/credit activities.
SAP AG 2003
© SAP AG
IUT240
17-21
Appendix 2: IS-T Special Features
Contents: z Data storage in RM-CA z Transfer of invoices from external billing systems z Disconnection/Reconnection Files
SAP AG 2003
© SAP AG
IUT240
18-1
IS-T: RMCA: Data Storage in RM-CA
Data Storage in RM-CA Invoices from EBS Disconnection/ Reconnection Files
SAP AG 2003
© SAP AG
IUT240
18-2
Database Table IST_TDATA CRM (optional)
EBS
Service data
Telephone number management
Disconnection infos
Service data (incl. disconnection infos) are replicated
Æ Activation Æ Billing
Invoice items
R/3 (RM-CA) Table IST-TDATA
Table DFKKOP
OBJECT_ID
...
SERVICE
ADD_REFOBJ
VALID_FROM
ADD_REFOBJID
GROUP_ID
...
Disconnection/ reconnection files
SAP AG 2003
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.
© SAP AG
IUT240
18-3
IS-T: RMCA: Invoices from EBS
Data Storage in RM-CA Invoices from EBS Disconnection/ Reconnection Files
SAP AG 2003
© SAP AG
IUT240
18-4
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 SAP AG 2003
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.
© SAP AG
IUT240
18-5
IS-T/IS-U IDOC Interfaces EBS
CO-PA
FI-CA
Bill 4711 Bill 4711 Bill 4711 Invoice 4711 xx.xx xx.xx xx.xx xx.xx
1
Doc.No. … 0000815 0000816 0000817 0000818 0000819 …
Invoice No. … 4709 4710 4711 4712 4713 …
Amount … xx.xx xx.xx xx.xx xx.xx xx.xx …
Division FixedNet. Cell. Internet
FI
2 Optical archive
Quantity xxxx xxxx xxxx
Account 880000 175000
Amount xx.xx xx.xx xx.xx
Amount … xx.xx
FI-CA Invoice 4711 xx.xx
3
Doc.No. … 0000815 0000816 0000817 0000818 0000819 …
Invoice No. … 4709 4710 4711 4712 4713 …
Amount … xx.xx xx.xx Reversal xx.xx xx.xx …
1. Invoice document transfer + optional CO-PA update 2. Archive link to optical invoice archive 3. Mass reversal SAP AG 2003
© SAP AG
IUT240
18-6
Invoice Document Transfer (Business Scenario) Doc. header
Doc. number Currency Date 4711 USD 07/21/2003
Invoice
Business partner items
Martin Mustermann
Doc. no. Item Bus. partner Contr.Acct G/L Account Amount 4711 1 Smith MM01 140000 58.00 Open item 4711 2 Smith MM01 140000 58.00 4711 3 Smith MM01 140000 116.00
Invoice no. 4711
Quantity Rate 20 local calls 10 national 05 international
Price 50.00 50.00 100.00
Tax 8.00 8.00 16.00
Total
200.00
32.00
Total:
IS-T/IS-U FI-CA
transfer Value fields
232.00
Characteristics
General ledger items (tax and revenue posting) Doc. no. 4711 4711 4711 4711 4711 4711
Item 1 1 2 2 3 3
Characteristics Rate Local call National International
G/LAccount Amount 175000 8.00080000 50.00175000 8.00080000 50.00175000 16.00080000 100.00-
Quantity 20 10 5
CO-PA
Quantity 20 10 5
Revenue 50.00 50.00 100.00
SAP AG 2003
© SAP AG
IUT240
18-7
Mass Reversal Interface
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.
Open items
EBS
RM-CA
Document header data (table DFKKKO) ...
Mass reversal
OPBEL
...
AWSYS
AWKEY
AWTYP
10000001
LogSys
0004711
ISTBS
10000002
LogSys
0004712
ISTBS
10000003
LogSys
0004713
ISTBS
...
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
SAP AG 2003
© SAP AG
IUT240
18-8
Possible Processing Runs Data Data sent sent from from EBS EBS to to RM-CA RM-CA Processing Processing by by mass mass activity activity Status Status "64" "64" (IDoc (IDoc ready ready for for transfer transfer to to application) application)
Status Status "53" "53" (Application (Application document document posted) posted)
Status Status "51" "51" (Application (Application document document not not posted) posted)
Low Low error error rate rate (Manual (Manual correction) correction)
Status Status "69" "69" (IDoc (IDoc edited) edited)
Very Very high high error error rate rate (e.g. (e.g. due due to to incorrect incorrect Customizing Customizing settings) settings)
Error Error processing processing (for (for example, example, change change Customizing Customizing settings) settings) and and scheduling scheduling using using mass mass processing processing
Scheduling Scheduling using using mass mass processing processing (ONLY (ONLY STATUS STATUS "69") "69")
Status Status "53" "53" (application (application document document posted) posted) SAP AG 2003
© SAP AG
IUT240
18-9
IS-T: RMCA: Disconnection/Reconnection Files
Data Storage in RM-CA Invoices from EBS Disconnection/ Reconnection Files
SAP AG 2003
© SAP AG
IUT240
18-10
Disconnection File for Telephone Numbers External Billing System
Dunning activity run
Disconnection file
Mail / escalation processing
Dunning history
SAP AG 2003
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.
© SAP AG
IUT240
18-11
Reconnection File for Telephone Numbers Payment External billing system
Payment lot Cash Desk Account maintenance Credit
Posting XX
A
B
XX
Mass activity
File
Reconnection file
Account balance Mail / escalation processing SAP AG 2003
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
© SAP AG
IUT240
18-12
IS-T Special Features: Summary
z In IS-T, telecommunication data can be stored in documents. z 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. z 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.
SAP AG 2003
© SAP AG
IUT240
18-13
Appendix 3: IS-U/CCS Special Features
Contents: z Budget billing procedure - Postings z Payment in a deregulated environment - Postings
SAP AG 2003
© SAP AG
IUT240
19-1
Budget Billing Procedures: Overview Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-2
Implemented Budget Billing Procedures
z Statistical procedure z Debit entry procedure (partial bills) z AMB - Average monthly billing z BBP - Budget billing plan
SAP AG 2003
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.
© SAP AG
IUT240
19-3
BB plan BB amt. n BB amt 2 BB amt 1
BB plan BB BB payment n BB payment 2 payment 1
Invoicing
Invoicing
Budget Billing Requests: Statistical Procedure
BB amt. n BB amt 2 BB amt 1
IS-U FI Receivable from YAP
Received BB amounts
Receivable from YAP
SAP AG 2003
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 FICA 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.
© SAP AG
IUT240
19-4
BB amt. n BB amt 2 BB amt 1
BB plan BB BB payment n BB payment 2 payment 1
Invoicing
Invoicing
BB plan
Partial billing
Budget Billing Requests: Debit Entry Procedure
BB amt. n BB amt 2 BB amt 1
IS-U FI Receivable from YAP
Partial billing receivable
BB payment
Receivable from YAP
SAP AG 2003
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.
© SAP AG
IUT240
19-5
Budget Billing Procedure: Statistical Budget Billing Procedure Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-6
Statistical Procedure: Example
This example displays the statistical procedure. Example I:
- Electricity division - Tax rate: 16% - Budget billing amount: 58.00 - Consumption billing: 69.60
SAP AG 2003
To simplify the example, only one budget billing is requested and paid.
© SAP AG
IUT240
19-7
Budget Billing Payments: Postings 1 Contract account IS-U [1]
IS-U
58.--
Receivables - Electricity
Revenue account - Electricity
Bank
Bank clearing
Tax account
Tax clearing
Budget billing amounts received
FI SAP AG 2003
1. (Statistical) posting of the budget billing request in IS-U.
© SAP AG
IUT240
19-8
Budget Billing Payments: Postings 2 Contract account IS-U [1]
Receivables - Electricity
Bank [2]
IS-U
58.--
58.--
Tax account
Revenue account - Electricity
Bank clearing 58.-- [2]
Budget billing amounts received
Tax clearing
FI SAP AG 2003
2. Posting of incoming payment in general ledger accounting.
© SAP AG
IUT240
19-9
Budget Billing Payments: Postings 3 Contract account IS-U ([1]
58.-- 58.-0.--)
IS-U
[3]
Receivables - Electricity
Revenue account - Electricity
Bank clearing
Bank [2]
58.--
[3]
[2]
Tax clearing
Tax account 8.--
58.-- 58.--
Budget billing amounts received 58.-- [3]
[3]
[3]
8.--
FI SAP AG 2003
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.
© SAP AG
IUT240
19-10
Budget Billing Payments: Postings 4 Contract account IS-U ([1] [4]
58.-- 58.-0.--) 69.60
Receivables - Electricity [4]
IS-U
[3]
Revenue account - Electricity 60.--
69.60
Bank clearing
Bank [2]
[4]
58,--
[3]
58.-- 58.--
[2]
Budget billing amounts received 58.-- [3]
Tax clearing
Tax account 8.--
[3]
9.60
[4]
[3]
8.--
FI
SAP AG 2003
4. Posting consumption billing in IS-U using IS-U invoicing. The debit entry of the receivable is made available for general ledger accounting.
© SAP AG
IUT240
19-11
Budget Billing Payments: Postings 5 Contract account IS-U ([1]
58.-- 58.-0.--) [4.5] 11.60
Receivables - Electricity [4]
69.60 58.--
IS-U
[3]
Revenue account - Electricity
[5]
60.--
Bank clearing
Bank [2]
[3]
58.--
8.--
58.-- 58.--
[2]
Budget billing amounts received [5] 58.-- 58.-- [3]
Tax clearing
Tax account [5]
[4]
8.--
[3]
9.60
[4]
[3]
8.--
8.--
[5]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-12
Budget Billing Payments: Overpayment - 1
This example displays the statistical procedure. Example 2:
Electricity Water
- Tax rate: 16% - Budget billing amount 60.00 - Billing 46.40 - Tax rate: 7% - Budget billing amount 50.00 - Billing 53.50
SAP AG 2003
To simplify the example, only one budget billing is requested and paid.
© SAP AG
IUT240
19-13
Budget Billing Payments: Overpayment - 2 Electricity [1]
Water
60.--
50.--
IS-U Contr. Acct
Electricity
Water
IS-U
110.--
Receivables Electricity
Receivables - Water
Bank
Bank clearing
Tax account
-
Revenue account Electricity
BB received - Elec.
Revenue account Water
BB received - Water
Tax clearing
FI SAP AG 2003
1. (Statistical) posting of the budget billing request in IS-U.
© SAP AG
IUT240
19-14
Budget Billing Payments: Overpayment - 3 Electricity [1]
[2]
Water 60.--
50.--
-
IS-U Contr. Acct
Receivables - Water
Bank
Bank clearing
Tax account
Electricity
Water
IS-U
110.--
Receivables Electricity
110.--
-
Revenue account Electricity
BB received - Elec.
Revenue account Water
BB received - Water
110.-- [2]
Tax clearing
FI SAP AG 2003
2. Posting of the incoming payment to the general ledger.
© SAP AG
IUT240
19-15
Budget Billing Payments: Overpayment - 4 Electricity [1]
Water 60.--
50.--
-
IS-U Contr. Acct 110.--
110.--
-
Electricity
Water
60.--
50.--
IS-U [3]
Receivables Electricity
Receivables - Water
Revenue account Electricity
Revenue account Water
Bank
Bank clearing
BB received - Elec.
BB received - Water
60.-- [3]
50.-- [3]
[3] 110.-- 110.-- [2]
[2] 110.--
Tax account 11.55 [3]
Tax clearing [3] 11.55
FI SAP AG 2003
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.
© SAP AG
IUT240
19-16
Budget Billing Payments: Overpayment - 5 Electricity
-
Water
IS-U Contr. Acct
-
Electricity
IS-U
Water
[1]
60.--
50.--
110.--
110.--
60.--
50.--
[3]
[4]
46.40
53.50
99,90
110.--
60.--
50.--
[5]
[F]
Receivables Electricity [4] 46.40 60.-- [5]
Bank [2] 110.--
Tax account [5] 11.55 11.55 [3]
10.10
3.50
[G] 13.60
Receivables - Water [4] 53.50 50.-- [5]
Revenue account Electricity 40.-- [4]
Revenue account Water 50.-- [4]
Bank clearing
BB received - Elec.
BB received - Water
[3] 110.-- 110.-- [2]
[5] 60.-- 60.-- [3]
[5] 50.-- 50.-- [3]
Tax clearing [3] 11.55 11.55
9.90 [4]
[5]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-17
Budget Billing Payments: Overpayment/Underpayment Electricity
Water
-
IS-U Contr. Acct
-
Electricity
IS-U
Water
[1]
60.--
50.--
110.--
110.--
60.--
50.--
[3]
[4]
46.40
53.50
99.90
110.--
60.--
50.--
[5]
[F]
3.50
10.10
[G] 13.60
z 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
SAP AG 2003
The way in which remaining credit from consumption billing is cleared against other receivables or future due budget billings is specified in clearing control.
© SAP AG
IUT240
19-18
Budget Billing Procedure: Partial Bill Procedure Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-19
Partial Billing Procedure: Example
This example presents the partial bill procedure. Example:
Electricity - Tax rate: 16% - Budget billing amount 58.00 - Billing 232.00
SAP AG 2003
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
© SAP AG
IUT240
19-20
Partial Billing Procedure: Postings 1 Contract account IS-U [1]
Receivables - Electricity
Bank [2]
58.--
Partial bill receivables [1]
IS-U
58.-- 58.-- [3]
58.-- 58.-- [3]
Revenue account - Electricity
Partial bill revenues
Bank clearing [3] 58.-- 58.-- [2]
50.-- [1]
Tax account 8.--
[1]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-21
Partial Billing Procedure: Postings 2 Contract account IS-U
IS-U
[1] 58.-- 58.-- [3] [1a] 58.--
Receivables - Electricity
Bank [2]
58.--
Partial bill receivables [1] 58,-- 58,-- [3] [1a] 58.--
Revenue account - Electricity
Bank clearing [3] 58.--
58.-- [2]
Partial bill revenues 50.-- [1] 50.-- [1a]
Tax account 8.-- [1] 8.-- [1a]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-22
Partial Billing Procedure: Postings 3 Contract account IS-U [1] 58.-[1a] 58.-[4,5] 116.--
Receivables - Electricity [4]
IS-U
58.-- [3]
Revenue account - Electricity
232.-- 58.-- [5] 58.-- [5]
200.-- [4]
Partial bill revenues Bank [2]
58.--
Partial bill receivables [1] [1a]
58.-- 58.-- [3] 58.--
Bank clearing [3] 58.--
58.-- [2]
[5] 50.-- 50.-- [1] [5] 50.-- 50.-- [1a]
Tax account [5] 16.--
16.-32.--
[1+1a] [4]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-23
Budget Billing Procedures: Payment Plan Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-24
Payment Plan: Example
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
SAP AG 2003
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
© SAP AG
IUT240
19-25
Budget Billing Procedures: Payment Plan Actual billing amount
Payment Plan 11/01/ 12/03/ 01/02/ 02/03/ 03/04/ 04/05/ 05/05/ 06/01/ 07/02/ 08/03/ 09/03/ 10/01/ 11/01/ 12/03/ .... 02/03
50.-50.-50.-50.-50.-50.-50.-50.-50.-50.-50.-50.-52.-52.-.... 52.--
Nov. Dec. Jan. Feb. Mar. Apr. May June July Aug. Sep. Oct. Nov. Dec. .... Oct.
55.11 65.12 51.45 50.34 50.98 49.99 48.87 49.01 45.98 45.56 50.09 52.98
50.-50.-50.-50.-50.-50.-50.-50.-50.-50.-50.-50.--
55.11 - 50 65.12 - 50+ 5.11 Balance Forward
Payment plan amount
Bill New payment plan
+
5.11 20.23 21.68 22.02 23.00 22.99 21.86 20.87 16.85 12.41 12.50 15.48 10/15 50.00 15.48 65.48
SAP AG 2003
© SAP AG
IUT240
19-26
Payment Plan: Postings Contract account IS-U 50.-- [3] [1] 50.-5.11 [4a] [1a] 5.11 [4] 50.-[4a] 20.23
IS-U
G/L account Electricity [1] [4]
55.11 65.12
50.--
Revenue account Electricity 47.51 [1+1a] 56.14 [4+4a]
[3]
Tax account 7.60 8.93
Bank [2]
50.--
[1+1a] [4+4a]
Bank clearing [3]
50.-- 50.--
[2]
FI SAP AG 2003
© SAP AG
IUT240
19-27
Budget Billing Procedure: Budget Billing Advance Payment Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-28
Budget Billing Advance Payment Budget billing plan from invoicing (*): 04/01/
100.--
Jan.- Mar.
07/01/
100.--
Apr. - June
10/01/
100.--
July - Sep.
01/01/
100.--
Oct. - Dec.
Budget billing plan after activation of advance payment: Activation date of advance payment: On 05/01/03 New
New
(*) Billing period 1/2 – 1/1 4 BB amounts/year
04/01/
100.--
Jan. - Mar.
07/01/
100.--
Apr. - Jun.
X
07/01/
100.--
July - Sep.
X
10/01/
100.--
Oct. - Dec.
L
01/01/
100.--
Jan.- Mar.
Consumption/advance payment period
Agenda: X = Advance payment flag L = 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 SAP AG 2003
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.
© SAP AG
IUT240
19-29
Budget Billing Procedure: Yearly Advance Payment Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-30
Yearly Advance Payment: Acceptance Cash payer
Account
Direct debit payer
Account
YAP participant 1 01/15/ 02/15/ 03/15/ 04/15/ . . .
99.99.99.99.-
YAP Base 1,089.00 Bonus 9.07 Amount 1,079.93
12/15/ 99.-
Active
01/15/ 02/15/ 03/15/ 04/15/ . . .
99.99.99.99.-
YAP Base 1,089.00 Bonus 9.07 Amount 1,079.93
12/15/ 99.-
Active
Acceptance by paying BB or YAP amount by payment block date
Active Explicit acceptance by customer or manual switch
YAP participant 2 01/15/ 02/15/ 03/15/ 04/15/ . . .
99.99.99.99.-
YAP Base 1,089.00 Bonus 9.07 Amount 1,079.93
12/15/ 99.-
Active
Manual switch possible
SAP AG 2003
© SAP AG
IUT240
19-31
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)
SAP AG 2003
© SAP AG
IUT240
19-32
Budget Billing Procedures: Customizing Overview of Budget Billing Procedures Statistical Budget Billing Procedure Partial Billing Procedure Payment Plan Budget Billing Advance Payment Yearly Advance Payment Customizing SAP AG 2003
© SAP AG
IUT240
19-33
Budget Billing: Customizing
IMG Contract Accounts Receivable and Payable Financial Accounting Contract Accounts Receivable and Payable Basic Functions Postings and Documents Documents Define Account Assignments for Automatic Postings Automatic G/L Account Determination Define Accounts for Down Payment Tax Clearing ISU: Define Acct Assmt Data Relevant to Main Transactions Define Accounts for Budget Billing Down Payments SAP Utilities Invoicing Budget Billing Plan Define Budget Billing Procedures Yearly Advance Payment Define Control Parameters for Yearly Advance Payment Allocate Interest Calculation Rule for Yearly Advance Payment SAP AG 2003
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.
© SAP AG
IUT240
19-34
Budget Billing Procedure: Summary
z There are different options for charging budget billing amounts in IS-U. z There is a distinction between actual debit entry and the statistical budget billing request. z 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.
SAP AG 2003
© SAP AG
IUT240
19-35
Payment in a Deregulated Environment: Overview
Overview Budget Billing Request and Payment Periodic Billing and Invoicing Individual Reversal
SAP AG 2003
© SAP AG
IUT240
19-36
Business Scenario: Grid Usage Processing 1 Distributor
Supplier
Create Create bills/budget bills/budget billing billing receivables receivables for for externally externally supplied supplied points points of of delivery delivery
Data Data exchange exchange
Data Data exchange exchange Send Send bills bills to to supplier supplier
INVOIC
Save Save incoming incoming bills bills in in the the system system
Identification Identification and and check check
Paper Paper printout printout
Post Post aggregated aggregated receivables receivables for for supplier supplier to to contract contract account account
Create Create aggregated aggregated bill bill
Paper Paper printout printout
Settings in service provider agreement SAP AG 2003
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
© SAP AG
IUT240
19-37
Business Scenario: Grid Usage Processing 2 Distributor
Supplier Data Data exchange exchange
REMADV
Save Save payment payment advice advice note/ note/ complaint complaint data data in in system system
Data Data exchange exchange Paper Paper printout printout
Aggreg., Aggreg., post post and and pay pay receivables receivables for for supplier supplier
Check Check complaints, complaints, ifif necessary necessary bill bill again again
Post Post incoming incoming payment payment to to supplier's supplier's contract contract account account Use Use payment payment advice advice data data to to distribute distribute incoming incoming payment payment among among individual individual accounts accounts SAP AG 2003
The following examples are a step-by-step explanation of postings in the distributor processes of bill processing and incoming payments
© SAP AG
IUT240
19-38
Payment in a Deregulated Environment: Budget Billing Request and Payment
Overview Budget Billing Request and Payment Periodic Billing and Invoicing Individual Reversal
SAP AG 2003
© SAP AG
IUT240
19-39
Payment in a Deregulated Environment: Example
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
SAP AG 2003
© SAP AG
IUT240
19-40
Payment in a Deregulated Environment Postings 1 Contract account customer 1 [1] 30.-[1a] 30.--
Contract account customer 2 [1] 80.00 [1a] 80.00
Contract account Supplier
Receivables
Revenue
Supplier clearing
Tax account
Tax clearing
Clearing
Bank
Bank clearing
Budget billing amounts received
IS-U
FI SAP AG 2003
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.
© SAP AG
IUT240
19-41
Payment in a Deregulated Environment Postings 2 Contract account customer 1 [1] 30.-[1a] 30.--
Contract account customer 2 [1] 80.-[1a] 80.--
Receivables
Revenue
Tax account
Tax clearing
Contract account Supplier [2] 110.-[2a] 110.--
IS-U
Supplier clearing [2] 110.-[2a] 110.-Clearing 110.-- [2] 110.-- [2a]
Bank
Bank clearing
Budget billing amounts received
FI SAP AG 2003
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.
© SAP AG
IUT240
19-42
Payment in a Deregulated Environment Postings 3 Contract account customer 1 [1] 30.-[1a] 30.--
Contract account customer 2 [1] 80.-[1a] 80.--
Receivables
Revenue
Tax account
Tax clearing
Bank
Bank clearing
[3] 110.--
Contract account Supplier [2] 110.-[2a] 110.--
IS-U
Supplier clearing [2] 110.-[2a] 110.-Clearing 110.-- [2] 110.-- [2a] Budget billing amounts received
110.-- [3]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-43
Payment in a Deregulated Environment Postings 4 Contract account customer 1 [1] 30.-[1a] 30.--
Contract account customer 2 [1] 80.-[1a] 80.--
Receivables
Revenue
Tax account
Tax clearing
Bank
Bank clearing
[3] 110.--
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.--
Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-Clearing 110.-- [2] 110.-- [2a] Budget billing amounts received
[4] 110.-- 110.-- [3]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-44
Payment in a Deregulated Environment Postings 5 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.--
Receivables
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.--
Revenue
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.--
Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.--
Tax account 15.17 [5]
Bank [3] 110.--
Tax clearing [5] 15.17
Bank clearing [4] 110.-- 110.-- [3]
Clearing [5] 110.-- 110.-- [2] 110.-- [2a] Budget billing amounts received 110.-- [5]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-45
Payment in a Deregulated Environment: Periodic Billing and Invoicing
Overview Budget Billing Request and Payment Periodic Billing and Invoicing Individual Reversal
SAP AG 2003
© SAP AG
IUT240
19-46
Payment in a Deregulated Environment: Example
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
SAP AG 2003
© SAP AG
IUT240
19-47
Payment in a Deregulated Environment Postings 6 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.--
Receivables [6] 240.--
15.17 15.17 [5] 33.10 [6]
Bank [3] 110.--
Revenue
110.-- [6]
Tax account [6]
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.--
206.90 [6]
Tax clearing [5] 15.17
15.17 [6]
Bank clearing [4] 110.-- 110.-- [3]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.--
Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-Clearing [5] 110.-- 110.-- [2] 110.-- [2a] Budget billing amounts received [6] 110.-- 110.-- [5]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-48
Payment in a Deregulated Environment Postings 7 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.--
Receivables [6] 240.--
15.17 15.17 [5] 33.10 [6]
Bank [3] 110.--
Revenue
110.-- [6]
Tax account [6]
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.--
206.90 [6]
Tax clearing [5] 15.17
15.17 [6]
Bank clearing [4] 110.-- 110.-- [3]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-Clearing [5] 110.-- 110.-- [2] [7] 110,-- 110.-- [2a] 130.-- [7] Budget billing amounts received [6] 110.-- 110.-- [5]
FI SAP AG 2003
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.
© SAP AG
IUT240
19-49
Payment in a Deregulated Environment Postings 8 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.-- 40.-- [8]
Receivables [6] 240.--
15.17 15.17 [5] 33.10 [6]
Bank [3] 110.-[8] 130.--
Revenue
110.-- [6] 130.-- [8]
Tax account [6]
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.-- 90.-- [8]
206.90 [6]
Tax clearing [5] 15.17
15.17 [6]
Bank clearing [4] 110.-- 110.-- [3] [8] 130.-- 130.-- [8]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8]
Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8] Clearing [5] 110.-- 110.-- [2] [7] 110.-- 110.-- [2a] [8] 130.-- 130.-- [7] Budget billing amounts received [6] 110.-- 110.-- [5]
FI
SAP AG 2003
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).
© SAP AG
IUT240
19-50
Payment in a Deregulated Environment: Individual Reversal
Overview Budget Billing Request and Payment Periodic Billing and Invoicing Individual Reversal
SAP AG 2003
© SAP AG
IUT240
19-51
Payment in a Deregulated Environment Postings 9 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.-- 40.-- [8] 40.-- [9] Receivables [6] 240.-[9] 30.--
110,-- [6] 130.-- [8] 70.-- [9]
Tax account [6] [9]
15.17 15.17 [5] 9.66 33.10 [6] 4.14 [9] Bank
[3] [8]
110.-130.--
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.-- 90.-- [8]
Revenue [9] 60.34 206.90 [6]
Tax clearing [5] 15.17 15.17 [6] [9] 4.14
Bank clearing [4] 110.-- 110.-- [3] [8] 130.-- 130.-- [8]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8]
Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- 8] Clearing [5] 110.-[7] 110.-[8] 130.--
110.-- [2] 110.-- [2a] 130.-- [7]
Budget billing amounts received [6] 110.--
110.-- [5] 30.-- [9]
FI
SAP AG 2003
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).
© SAP AG
IUT240
19-52
Payment in a Deregulated Environment Postings 10 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.-- 40.-- [8] 40.-- [9] Receivables [6] [9]
240.-- 110.-- [6] 30.-- 130.-- [8] 70.-- [9] Tax account
[6] [9]
15.17 15.17 [5] 9.66 33.10 [6] 4.14 [9] Bank
[3] [8]
110.-130.--
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.-- 90.-- [8]
Revenue [9] 60.34 206.90 [6]
Tax clearing [5] 15.17 15.17 [6] [9] 4.14
Bank clearing [4] 110.-- 110.-- [3] [8] 130.-- 130.-- [8]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8] 40.-- [10] Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8] 40.-- [10] Clearing [5] 110.-- 110.-- [2] [7] 110.-- 110.-- [2a] [8] 130.-- 130.-- [7] [10] 40.-Budget billing amounts received [6] 110.--
110.-- [5] 30.-- [9]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-53
Payment in a Deregulated Environment Postings 11 Contract account customer 1 [1] 30.-- 30.-- [5] [1a] 30.-- 30.-- [6] [6] 40.-- 40.-- [8] [11a] 40.-- 40.-- [9] Receivables [6] 240.-[9] 30.-[11a] 40.--
110.-- [6] 130.-- [8] 70.-- [9]
Tax account [6] [9]
15.17 15.17 [5] 9.66 33.10 [6] 4.14 [9] Bank
[3] 110.-[8] 130.--
40.-- [11b]
Contract account customer 2 [1] 80.-- 80.-- [5] [1a] 80.-- 80.-- [6] [6] 90.-- 90.-- [8]
Revenue [9] 60.34 206.90 [6]
Tax clearing [5] 15.17 15.17 [6] [9] 4.14
Bank clearing [4] 110.-- 110.-- [3] [8] 130.-- 130.-- [8] [11b] 40.-- 40.-- [11]
Contract account IS-U Supplier [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8] [11] 40.-- 40.-- [10] Supplier clearing [2] 110.-- 110.-- [4] [2a] 110.-- 110.-- [7] [7] 130.-- 130.-- [8] [11] 40.-- 40.-- [10] Clearing [5] 110.-- 110.-- [2] [7] 110.-- 110.-- [2a] [8] 130.-- 130.-- [7] 40.-- [11a] [10] 40.-Budget billing amounts received [6] 110.--
110.-- [5] 30.-- [9]
FI
SAP AG 2003
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.
© SAP AG
IUT240
19-54
Payment with VV2: Summary
z Deregulation has made it necessary to adjust bill processing and payment processes to meet the requirements of the new deregulated processes. z Distributors bill with suppliers on the basis of individual account billing. z Clearing accounts are posted for the aggregated posting and complete processing of an incoming payment.
SAP AG 2003
© SAP AG
IUT240
19-55
