IUT240 FI-CA SAP for Industries - SAP for Utilities
Date Training Center Instructors Education Website
Instructor Handbook Course Version: 2006/Q2 Course Duration: 5 Days Material Number: 50080588 Owner: Susanne Kruse (D031858)
An SAP Compass course - use it to learn, reference it for work
Copyright Copyright © 2006 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. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks •
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
•
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.
•
ORACLE® is a registered trademark of ORACLE Corporation.
•
INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.
•
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.
•
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
g2006102902950
About This Handbook This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used. Type Style
Description
Example text
Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).
2006/Q2
Example text
Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT
Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text
Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text
Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.
Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
© 2006 SAP AG. All rights reserved.
iii
About This Handbook
IUT240
Icons in Body Text The following icons are used in this handbook. Icon
Meaning For more information, tips, or background Note or further explanation of previous point Exception or caution Procedures
Indicates that the item is displayed in the instructor’s presentation.
iv
© 2006 SAP AG. All rights reserved.
2006/Q2
Contents Course Overview .......................................................... ix Course Goals ........................................................... ix Course Objectives .....................................................xii
Unit 1: Basics ............................................................... 1 Concept and Special Functions in FI-CA ...........................2 Event Technology .......................................................8 Parallel Mass Processes in FI-CA .................................. 13 Master Data Objects in FI-CA ....................................... 19
Unit 2: Documents ....................................................... 41 Lifecycle of Documents .............................................. 43 Document Structures ................................................ 51 Posting Documents ................................................... 61 Integration with General Ledger Accounting ...................... 80 Account Balance Display ............................................ 97
Unit 3: Transactions and Account Determination ............... 109 Structure of Transactions .......................................... 111 Transactions in IS-U ................................................. 118 General Ledger Account Determination ..........................122 Tax Determination....................................................130 Tax Determination in IS-U...........................................141 USA - Tax Jurisdiction Code (Only relevant for US training) ...146
Unit 4: Incoming Payments........................................... 153 Processing Incoming and Outgoing Payments..................154 Payment Lots and Check Lots .....................................158 Clarification Processing .............................................176 Cash Desk / Cash Journal ..........................................193
Unit 5: Payment Run ................................................... 211 Prerequisites of the Payment Settlement .........................212 Payment Program....................................................220 Payment Cards.......................................................236 Check Management .................................................248 FSCM Biller Direct ...................................................253 Revenue Distribution ................................................258
2006/Q2
© 2006 SAP AG. All rights reserved.
v
Contents
IUT240
Unit 6: Returns Processing........................................... 267 Configuration of Returns ............................................268 Processing of Returns...............................................281
Unit 7: Clearing Control ............................................... 295 Terminology and Definitions ........................................296 Configuration of the Clearing Strategy ............................303 Special Cases: .......................................................319
Unit 8: Dunning and Collections .................................... 333 Dunning - Terminology ..............................................334 Configuration and Execution of the Dunning Run ...............339 Submission to External Collection .................................364
Unit 9: Interest Calculation ........................................... 379 Calculation of Interest on Items ...................................380 Interest Keys and Calculation Rules ..............................384 Processing of Interest Calculation .................................396
Unit 10: Deferral/Installment Plan ................................... 413 Deferral: Definition and Processing ...............................414 Installment Plan: Definition and Processing .....................420
Unit 11: Other Business Transactions ............................. 435 Account Maintenance ...............................................437 Reversing Documents and Resetting Clearing ..................446 Document Transfer ..................................................456 Mark as Doubtful / Individual Value Adjustment .................460 Write Off ...............................................................465
Unit 12: Security Deposits ............................................ 475 Cash and Non-Cash Security Deposits ...........................476 Request, Payment and Settlement of Cash Security Deposits 481
Unit 13: Correspondence ............................................. 499 Definition and Types .................................................500 Handling and Customizing ..........................................508 The Print Workbench ................................................518
Unit 14: Further Integration of FI-CA in SAP Modules ......... 527 Integration of Contract Accounts Receivable and Payable: Overview ..........................................................529 Funds Management .................................................533
vi
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Contents
Cash Management...................................................544 Contract Accounts Receivable and Payable and SD Integration .........................................................549 Integration of New G/L (Segment Reporting) ....................558 Credit Management..................................................563 Financial Customer Care ...........................................571 Business Intelligence ................................................578 Outbound Interface ..................................................583
Unit 15: Appendix: Industry-Specific Functions ................ 591 Appendix Utilities.....................................................592 Appendix Telecommunications .....................................612 Appendix Media ......................................................622
2006/Q2
© 2006 SAP AG. All rights reserved.
vii
Contents
viii
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Course Overview Contents: • • • • •
Course goals Course Objectives Contents Course Overview Diagram Main Business Scenario
Target Audience This course is intended for the following audiences: • • • •
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
Course Prerequisites Required Knowledge • •
IUT210: Master Data and Basic Functions Basic knowledge of the Windows operating system environment
Course Duration Details Unit 1: Basics Concept and Special Functions in FI-CA Event Technology Parallel Mass Processes in FI-CA Master Data Objects in FI-CA Unit 2: Documents Lifecycle of Documents Document Structures Posting Documents Exercise 1: Entering Documents in Contract Accounts Receivable and Payable Integration with General Ledger Accounting Exercise 2: Transferring Summary Records to General Ledger Accounting
2006/Q2
© 2006 SAP AG. All rights reserved.
20 Minutes 15 Minutes 20 Minutes 50 Minutes 10 Minutes 50 Minutes 40 Minutes 20 Minutes 40 Minutes 20 Minutes
ix
Course Overview
IUT240
Account Balance Display Exercise 3: Analysis of Contract Accounts Unit 3: Transactions and Account Determination Structure of Transactions Transactions in IS-U General Ledger Account Determination Tax Determination Exercise 4: Configuring Transactions Tax Determination in IS-U USA - Tax Jurisdiction Code (Only relevant for US training)
30 Minutes 15 Minutes 20 Minutes 20 Minutes 30 Minutes 10 Minutes 15 Minutes
Unit 4: Incoming Payments Processing Incoming and Outgoing Payments Payment Lots and Check Lots Exercise 5: Entering Payments in Payment Lots Clarification Processing Exercise 6: Clarification Processing Cash Desk / Cash Journal Exercise 7: Cash Desk / Cash Journal
10 Minutes 45 Minutes 20 Minutes 40 Minutes 20 Minutes 30 Minutes 20 Minutes
Unit 5: Payment Run Prerequisites of the Payment Settlement Payment Program Exercise 8: Payment Run Processing Payment Cards Exercise 9: Payment by Credit Card Check Management FSCM Biller Direct Revenue Distribution
15 Minutes 40 Minutes 20 Minutes 30 Minutes 20 Minutes 15 Minutes 10 Minutes 15 Minutes
Unit 6: Returns Processing Configuration of Returns Processing of Returns Exercise 10: Configuration and Processing of Returns
x
30 Minutes 20 Minutes
45 Minutes 20 Minutes 30 Minutes
Unit 7: Clearing Control Terminology and Definitions Configuration of the Clearing Strategy Special Cases: Exercise 11: Configuration of Clearing Variants
15 Minutes 50 Minutes 30 Minutes 40 Minutes
Unit 8: Dunning and Collections Dunning - Terminology Configuration and Execution of the Dunning Run Exercise 12: Dunning Submission to External Collection
10 Minutes 45 Minutes 30 Minutes 30 Minutes
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Course Overview
Exercise 13: Submitting Receivables to External Collection Agencies Unit 9: Interest Calculation Calculation of Interest on Items Interest Keys and Calculation Rules Processing of Interest Calculation Exercise 14: Calculation of Interest on Items
15 Minutes 40 Minutes 30 Minutes 20 Minutes
Unit 10: Deferral/Installment Plan Deferral: Definition and Processing Exercise 15: Manual Deferral of Open Items Installment Plan: Definition and Processing Exercise 16: Creating an Installment Plan
10 Minutes 10 Minutes 30 Minutes 15 Minutes
Unit 11: Other Business Transactions Account Maintenance Exercise 17: Manual Account Maintenance Reversing Documents and Resetting Clearing Document Transfer Mark as Doubtful / Individual Value Adjustment Write Off Exercise 18: Manual Write Off
15 Minutes 15 Minutes 20 Minutes 15 Minutes 20 Minutes 15 Minutes 15 Minutes
Unit 12: Security Deposits Cash and Non-Cash Security Deposits Request, Payment and Settlement of Cash Security Deposits Exercise 19: Processing Cash Security Deposits Unit 13: Correspondence Definition and Types Handling and Customizing The Print Workbench Unit 14: Further Integration of FI-CA in SAP Modules Integration of Contract Accounts Receivable and Payable: Overview Funds Management Cash Management Contract Accounts Receivable and Payable and SD Integration Integration of New G/L (Segment Reporting) Credit Management Financial Customer Care Business Intelligence Outbound Interface Unit 15: Appendix: Industry-Specific Functions Appendix Utilities
2006/Q2
20 Minutes
© 2006 SAP AG. All rights reserved.
10 Minutes 40 Minutes 15 Minutes 15 Minutes 25 Minutes 20 Minutes
10 Minutes 10 Minutes 10 Minutes 10 Minutes 10 Minutes 10 Minutes 10 Minutes 10 Minutes 10 Minutes 1 Minutes
xi
Course Overview
IUT240
Appendix Telecommunications Appendix Media
1 Minutes 1 Minutes
Course Goals This course will prepare you to: • • • •
Get to know the conceptual characteristics of the component FI-CA Contract Accounts Receivable Execute the basic business processes Make the necessary settings for configuring FI-CA Understand the integration of FI-CA with other R/3 components and web-based SAP applications
Course Objectives After completing this course, you will be able to: • • •
Modify FI-CA business processes to meet your individual needs Execute and check these business processes Describe the integration with other components and applications
SAP Software Component Information The information in this course pertains to the following SAP Software Components and releases:
xii
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Course Overview
•
Hints on Preparing This Course
•
– Completing Exercises – Checking Demo Data Training System The course is held in the TNU system (Release ERP 2005). All data in TNU is copied from a master system on a weekly basis. Before starting the course, ensure that the responsible curriculum product consultant has used [email protected] to allocate a training client.
•
User ID and Password for Trainer User ID: IUT240-00 Password: init
•
User ID and Password for Course Participants User: IUT240-xx (xx = Group number) Password: init
Course participant users are available for participants IUT240-01 to IUT240-30 in the system. The users have general authorizations for all necessary transactions and for the Customizing to be executed in the exercises. ERP 2005 master data examples in TNU: The TNU clients contain existing exercise data for both scenarios: US scenario with tax jurisdiction code, and general scenario with single-level tax calculation:
2006/Q2
Business partner/contract account number
Company code
Currency
US scenario
PI####C0##
U300 / U400
USD
General scenario
PICA###0##
U100 / U110
EUR
Topic
Data (trainer)
1
Basics
PI0904C030 (PICA071030)
2
Documents
PI0202C030 (PICA021030)
PI0202C001 - 30 (PICA021001 - 29)
3
Transactions and Account Determination
PI0202C030 (PICA021030)
PI0202C001 - 30 (PICA021001 - 29)
© 2006 SAP AG. All rights reserved.
Data (participant)
xiii
Course Overview
IUT240
Topic
Data (trainer)
Data (participant)
4
Incoming Payments
PI0701C030 (PICA071030)
PI0701C001 – 30 (PICA071001 - 29)
5
Payment Run
PI0501C030 (PICA051030
PI0501C001 – 30 (PICA051001 - 29)
6
Returns Processing
PI0501C030 (PICA051030)
PI0501C001 – 30 (PICA051001 - 29)
7
Clearing Control
PI0903C030 (PICA093030)
PI0903C001 – 30 (PICA093001 - 29)
8
Dunning and Collections
PI10901C030 (PICA101030)
PI0901C001 – 30 (PICA091001 - 29)
9
Interest Calculation
PI1001C030 (PICA101030)
PI1001C001 – 30 (PICA101001 - 29)
10
Deferral/Installment Plan
PI1101C030 (PICA101030)
PI1101C001 – 30 (PICA111001 - 29)
11
Other Business Transactions
PI1201C030 (PICA120130)
PI1201C001 – 30 (PICA121001 - 29)
12
Security Deposits
PI1301C030 (PICA131030)
PI1301C001 – 30 (PICA131001 - 29)
13
Correspondence
14
Further Integration of FI-CA in SAP Modules
Preparation in the System Enable Customizing in clients (should be undertaken by curriculum product consultant) • • • • •
•
xiv
Enter TA code SM30 Make entry in Table/View field of T000 table, and select the Maintain pushbutton Select current training clients (such as 015 or 016) when selecting all clients from system Activate first selection field ’Changes without automatic recording’. Make entry in ’Changes field and transport client-dependent objects’ Select ’Changes to Repository and cross-client Customizing allowed’ in the ’Cross-Client Object Changes’ field, using F4 help (ignore the system messages). Save the transaction
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Course Overview
For those exercises, in which the participants must change Customizing, it must be possible for multiple users to access IMG tables: • • • •
2006/Q2
Enter the TA code SA38 in the current TNU client Enter ZSENQOFF in the program field Execute the program and confirm the message Once the exercise is complete, start the ZSENQON program to block IMG tables for multiple access.
© 2006 SAP AG. All rights reserved.
xv
Course Overview
xvi
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 1 Basics
1
Unit Overview
Unit Objectives After completing this unit, you will be able to: • • • •
Explain the general concept and special functions in FI-CA. Use event management to integrate customer-specific requirements into the SAP System without modifying SAP programs. Dramatically reduce the runtime for mass runs (such as payment runs or dunning processing) by using parallel processes. Explain the most important master data objects in FI-CA, and their controlling elements.
Unit Contents Lesson: Lesson: Lesson: Lesson:
2006/Q2
Concept and Special Functions in FI-CA ............................2 Event Technology........................................................8 Parallel Mass Processes in FI-CA................................... 13 Master Data Objects in FI-CA........................................ 19
© 2006 SAP AG. All rights reserved.
1
Unit 1: Basics
Lesson: 2
IUT240
Concept and Special Functions in FI-CA Lesson Duration: 20 Minutes
Lesson Overview At the end of this lesson you will be able to explain the general concept and special functions in FI-CA.
Lesson Objectives After completing this lesson, you will be able to: •
Explain the general concept and special functions in FI-CA.
Business Example
Figure 1: Advantages of Contract Accounts Receivable and Payable
2
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Concept and Special Functions in FI-CA
Figure 2: Applications for Contract Accounts Receivable and Payable
Various industry sectors use FI-CA as a subledger, due to its seamless integration in the general ledger or invoicing, as well as in Web-based self services and call center solutions. The exchange of messages in the integration is based largely on the XML interfaces of the SAP Netweaver Exchange infrastructure.
Figure 3: SAP ERP Central Components (ECC) mySAP ERP 2005
The majority of industry solutions within the ERP release are delivered with mySAP ERP 2005. •
The SAP Switch Framework is available for activating industry solutions that are delivered as business function sets. In addition, the industry extensions are divided into business function sets, to which one or more business functions are allocated. You can activate these business functions.
2006/Q2
© 2006 SAP AG. All rights reserved.
3
Unit 1: Basics
IUT240
You can only activate one business function for each instance. Within the business function sets you can individually activate the business functions from the industry extension. At the start of the implementation, select the business function set that corresponds to your industry solution, or which contains the business functions that you require, and activate this business function set. When you activate a business function set you install the SAP system. You can then no longer deactivate the business function set or activate a different business function set. Industry business function sets (BFS) consist of a number of functions (BF), which can be activated separately. –
BFS Utilities: BF ISU_UTIL_WASTE - Utilities, Waste, Recycling BF ISU_FM – Utilities: Funds Management
–
BFS Telco: BF RM_CA – Telco: Revenue Management BF CONVEREGENT_INVOICING – Telco: Invoicing in FI-CA
–
BFS Media: BF ADVERTISING MANAGEMENT - Media: Advertising Management BF SINGLE COPY NEWSP. & MAG (PUB) - Media: SC Newsp & Mag (Pub) BF SINGLE COPY NEWSP. & MAG (WHS) - Single copy Newsp. & Mag (WHS) BF SINGLE COPY PREMIUM CONTENT - Media: SC Premium Content BF SUBS LOOSE-LEAF, JOURNALS - Media: Subs Loose Leaf, Journals BF SUBS NEWSPAPER & MAGAZINES - Media: Subs Newspaper Magazines BF TITLE LIFECYCLE MANAGEMENT - Media: Title Lifecycle Management
•
4
The enterprise extensions contain the generic business functions from mySAP ERP. You can use the SAP Switch Framework to activate all enterprise extensions. The enterprise extensions are available in addition to the industry extensions.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Concept and Special Functions in FI-CA
You can simultaneously activate more than one business function from the enterprise extension for each instance.
Figure 4: mySAP ERP 2005: Industry enhancements are activated by the Switch Framework
2006/Q2
© 2006 SAP AG. All rights reserved.
5
Unit 1: Basics
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
6
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Concept and Special Functions in FI-CA
Lesson Summary You should now be able to: • Explain the general concept and special functions in FI-CA.
2006/Q2
© 2006 SAP AG. All rights reserved.
7
Unit 1: Basics
Lesson: 7
IUT240
Event Technology Lesson Duration: 15 Minutes
Lesson Overview At the end of this lesson you will recognize the definition and concept of the events in contract accounts receivable and payable, and know how you can use installation-specific enhancements in your system.
Lesson Objectives After completing this lesson, you will be able to: •
Use event management to integrate customer-specific requirements into the SAP System without modifying SAP programs.
Business Example
Figure 5: Technology: Event Concept (1)
8
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Event Technology
The event concept allows you, at defined points in a program, to include specific source text passages in the events. These passages are capsulated in function modules, and are therefore exchangeable. You use defined interfaces to include these source text passages in the events. You maintain events and their function modules in the implementation guide for Contract Accounts Receivable and Payable, under Program Enhancements → Define Customer-Specific Function Modules. The FKK_FUNC_MODULE_DETERMINE function module runs for each event. It determines the event modules stored for processing in Customizing from the following tables: •
TFKFBM (sample function module from Contract Accounts Receivable and Payable) TFKFBS (applications from standard function module) TFKFBC (installation-specific function modules)
• •
The technical name of the function module is formed from the technical code FKK_SAMPLE_ and the name of the event. In the case of a sample function module defined at event 0010, the name would be FKK_SAMPLE_0010. As well as the events that are available to all industry components, additional industry-specific events also exist. You can recognize these from the encryption of the application area in the technical name. Overview of event nomenclature
2006/Q2
From event
To event
Application
0
9999
Application-independent
R0
R999
Utilities Industry
V0
V999
Insurance
T0
T999
Telecommunications
P0
P999
Public Sector
X0
X999
Partner Developments
Z0
Z999
Customer Developments
S0
S999
SAP Contract Accounts Receivable and Payable
© 2006 SAP AG. All rights reserved.
9
Unit 1: Basics
IUT240
Figure 6: Technology: Event Concept (2)
Events can be managed using transaction FQEVENTS. To use the event concept you must have knowledge of the program and the data structure. If you require a different function to those intended by SAP, we recommend you proceed as follows: • • • • •
10
Analyze the standard function modules from the application (TFKBS). These function modules define the required interfaces. Copy the function group that groups customer-specific function modules according to business transactions. Program and activate the individual enhancements/changes in the installation-specific function module. Enter the installation-specific function module in the TFKFBC table (Customizing: Program enhancements). Start the program that calls the enhanced event.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Event Technology
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
11
Unit 1: Basics
IUT240
Lesson Summary You should now be able to: • Use event management to integrate customer-specific requirements into the SAP System without modifying SAP programs.
12
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 11
Lesson: Parallel Mass Processes in FI-CA
Parallel Mass Processes in FI-CA Lesson Duration: 20 Minutes
Lesson Overview At the end of this lesson you will know what options you have for optimizing your mass processes in FI-CA.
Lesson Objectives After completing this lesson, you will be able to: •
Dramatically reduce the runtime for mass runs (such as payment runs or dunning processing) by using parallel processes.
Business Example
Figure 7: Technology: Mass Processes in FI-CA
2006/Q2
© 2006 SAP AG. All rights reserved.
13
Unit 1: Basics
IUT240
Business processes such as payment or dunning runs, in which large volumes of data are processed, are realized in FI-CA by using mass activities. Mass activities automatically divide the dataset, such as a quantity of business partners or contract accounts, into multiple technical jobs, and processes these at the same time.
Figure 8: Technology: Splitting-Up Processes
You can use the FI-CA mass activities to divide data to be processed into several jobs. The system then processes these jobs parallel. For more information, see the SAP note 607797 (Job control for mass runs: FAQ).
14
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Parallel Mass Processes in FI-CA
Figure 9: Technology: Parallel Processing - Interval Creation
When processing data, the system automatically splits the dataset to be processed into multiple parallel jobs. The specifications for distributing the key for the parallel objects are saved in variants, which you must update periodically. For example, you can create a variant for the business partners that splits the business partner set to be processed into 1,000 equal intervals. During parallel processing, the system makes sure that the processes do not block each other because of changing accesses to the same database resources, which could be the case, for example, in the assignment of document numbers or the update of transaction figures. A payment run for all business partners starts several processes (for example, 10) that process the intervals created automatically one after the other. When the processing is completed for an interval, the system processes the next free interval. If all intervals have been processed, and therefore all technical jobs completed, the business task also receives the status Completed.
2006/Q2
© 2006 SAP AG. All rights reserved.
15
Unit 1: Basics
IUT240
Figure 10: Technology: Parallel Processing - Portioning
Figure 11: Technology: Parallel Processing - Realization
You can find documentation on planning batch processes in FI-CA and working with the FI-CA job container in OSS under the keyword FO-JOB.
16
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Parallel Mass Processes in FI-CA
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
17
Unit 1: Basics
IUT240
Lesson Summary You should now be able to: • Dramatically reduce the runtime for mass runs (such as payment runs or dunning processing) by using parallel processes.
18
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 16
Lesson: Master Data Objects in FI-CA
Master Data Objects in FI-CA Lesson Duration: 50 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the most important master data objects in FI-CA, and their controlling elements.
Business Example
Figure 12: Central Objects
2006/Q2
© 2006 SAP AG. All rights reserved.
19
Unit 1: Basics
IUT240
Figure 13: Business Partner and Roles: Examples
Application-neutral data, such as name, address, bank details and payment cards, is contained on the business partner master record. Special requirements involved in setting up business partners that are organizations, groups, and individuals are also fulfilled. The SAP Business Partner also provides an open infrastructure for linking the application-specific attributes of the business partner. From a business point of view, this link is made by way of the role concept. On the technical side, SAP Business Partner offers predefined interfaces via which business partner attributes from different applications can be linked. This means that existing business partner mapping (from resident to tax payer) within SAP can gradually be integrated into SAP Business Partner.
20
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Figure 14: Business Partner: Role Definition
A business partner role corresponds to a business context in which a business partner can appear. A business partner can have several business partner roles. Possible roles are, for example, a contract partner (FICA), contact person, prospect (potential customer) or business partner (general). The above example shows that a business partner can assume several roles (contact person, prospect, contract partner) depending on the business process in which he/she is involved. BP roles consist of blocks (attributes) known as data sets. These are shown as little black boxes in the graphic above. SAP’s Business Partner offers an open infrastructure. This means that other components (ERP core, industry components, components of development partners, and a customer’s-own components) can easily include their own application-specific business partner data. As of release ERP2005, business partners must exist in the business role MKK for role category MKK. If you use business partner roles on a time-dependent basis, take the following into account: The time frame for business role MKK for role category MKK cannot be delimited. It must always have a validity period from today’s date to 12.31.9999. You may not, and cannot, restrict the validity of this role.
2006/Q2
© 2006 SAP AG. All rights reserved.
21
Unit 1: Basics
IUT240
Figure 15: Business Partner: Business Partner Category
A business partner in FI-CA usually represents the person or legal entity that you need to process incoming and outgoing payments against. It is primarily the constituent or taxpayer from the collections point of view and the beneficiary from the disbursements point of view. Business partner category is the term used to classify a business partner as a natural person (e.g. private individual), group or organization (legal entity or part of a legal entity, such as department). The business partner category determines which fields are available for data entry. For example, when you want to create a business partner as an organization, one of the fields requires you to enter the legal form. With a person, you have to enter first name, name components and gender, etc. When a business partner is created, the business partner category must be selected (required entry). Assignment of the business partner category is static and cannot be changed once the business partner has been created. It is not possible to create any other business partner categories.
22
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Figure 16: Business Partner: Business Partner Group
A business partner group is a classification of business partners according to criteria that the user can freely define. The procedure in customizing is as follows: • •
Definition of number ranges for the business partners Definition of groupings for the business partner and assignment of number ranges
Number range intervals and a type of number assignment are defined for each number range: • •
Type of number assignment: External or internal number assignment Number range intervals determine which numbers are permitted.
Business partner number ranges apply to all clients. The standard R/3 system contains number ranges for the groups provided, and these can be changed if necessary.
2006/Q2
© 2006 SAP AG. All rights reserved.
23
Unit 1: Basics
IUT240
Figure 17: Business Partner: Business Partner Type
The business partner type controls the field status definition (which fields on the business partner master record are mandatory, hidden, displayed, optional) when creating a business partner in FI-CA. You can use business partner types to group business partners according to your own criteria. You can find the business partner type in the control data of the business partner.
Figure 18: Business Partner: Address Management
24
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Central address management allows different addresses to be assigned to a business partner for different functions (see customizing of business partner address types). These addresses can be classified according to address types (e.g. delivery address, correspondence address, etc.). You can maintain any number of addresses for each business partner. One address per business partner is flagged as being the standard address. Postal data and information on different communication types is assigned to the address. You can maintain different communication types for each address (telephone, fax, internet mail address, pager services, printers, remote mail, Secure Store & Forward, telex, teletex, URI/URL/FTP, X.400). The address can be used independently of the business partner. The address is an object in itself and offers interfaces. The business partner is based on these, and offers corresponding business partner interfaces. The standard address is always maintained on the “Address” screen. As of release ERP2005, the standard address of a business partner is no longer portrayed using the indicator XDFADR in table BUT020. This indicator is obsolete and you can no longer specify it on manual entry. With effect from Release 6.40, the standard address is portrayed with the address use XXDEFAULT. If you want to use addresses on a time basis, you can create different standard addresses for different periods. For each time, you can specify one address as standard address for the business partner.
Figure 19: Address Management: Additional Functions
To date, SAP uses software provided by the company UNISERV to carry out the above checks. Interfaces provided by the company Paricon make the link to Central Address Management. Integration with other software providers is also planned.
2006/Q2
© 2006 SAP AG. All rights reserved.
25
Unit 1: Basics
IUT240
Integration is guaranteed by BADIs (Business Add Ins). BADIs are open interfaces that can be created at every level of a multi-level system landscape (R/3, country versions, IS solutions, partner, customer and so on). Examples of checks: •
• •
Postal check: Postal codes, cities and streets, and combinations of the same, are checked for consistency. To activate the central address management please review the SAP notes 098050 and 132948. During the check, missing elements are added. For example, if only the city has been entered, the postal code will then be added. When you create and change a business partner, you are offered a number of phonetically similar, existing partners for comparison purposes. In this way you avoid creating the same partner more than once.
Error tolerant search means, that you can search for duplicate business partner entries using the PF4 ‘search’ function.
Figure 20: Contract Account: Structure and Function
For posting a document, a contract account must be assigned to a business partner. A contract account can represent a grant type. It is necessary for the open item accounting within FI-CA. A contract account is also a unit that groups business partner postings (for example, tax type).
26
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
The contract account category determines the following attributes: • • • • • •
Whether you are allowed to assign only one business partner or more than one to a contract account. Whether you are allowed to assign only one contract or more than one. Whether you are allowed to maintain a contract account online. The number range that is allowed for external or internal number assignment. Whether it is a one-time account. The editing screens or data fields that you can use to edit the contract account.
You can use the method “BAPI_CTRACCOUNT_EASYCREATE” to create a contract account with sample values.
Figure 21: Contract Account: Company Code Group
The company code group includes all company codes that are permitted for posting to a contract account. One company code group is assigned to each contract account. Company code groups can overlap. This means, for example, you can have a group G1 that consists of company codes 0001, 0002, and 0003, and group G2 that consists of 0001 and 0003. Using the new event 1010, you can check whether a company code group is permitted in a contract account. This enables you to prevent, for example, that cross-country groups (in certain contract accounts) are used.
2006/Q2
© 2006 SAP AG. All rights reserved.
27
Unit 1: Basics
IUT240
Figure 22: Company Codes in Contract Accounts Receivable and Payable
•
Exactly one paying company code is always assigned to each company code group in Customizing. A paying company code is responsible for payment transactions. You have to define house banks and payment methods for paying company codes. Several company code groups can have the same paying company code. The paying company code does not have to be in the company code group itself. You can also specify the paying company code in a business partner item. In this case, this specification overrides the paying company code determined via the company code group of the contract account. If a paying company code specified in the line item is in a different country to the paying company code determined via the contract account, you also have to specify a payment method in the line item. In this case you cannot use the payment methods from the contract accounts since they refer to a different country.
•
28
A standard company code is allocated to each contract account You use the standard company code for all postings for which no company code can be determined by other means (for example, for payments on account).
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Figure 23: Transfer of Responsible Company Code
The first check, in which the validity of a company code group is checked or required, automatically transfers the responsible company codes to the company code groups and paying company codes. The system creates a company code group with the same key for each responsible company code. The company codes that were previously allocated to the responsible company code are allocated to this company code group. The responsible company code is allocated as the paying company code for the group. This guarantees the continuity for the existing organization model. The description of the responsible company code is copied as the description of the company code group. As the new description is language-dependent, it is automatically created in all languages used in the installation. The languages are determined by analyzing the document type texts. Change to contract accounts A company code group and standard company code are necessary specifications for new contract accounts. The RFKKSTDBK conversion program is available for existing contract accounts. You can use it to enhance the missing specifications from the standard company code. The standard company code is then given the value of the previous responsible company code. The conversion of contract accounts can take place in sections subsequently. Accounts that have not yet been converted are handled by the system as though the conversion had already taken place.
2006/Q2
© 2006 SAP AG. All rights reserved.
29
Unit 1: Basics
IUT240
Figure 24: Elements of the Customer Profile
The business partner’s payment patterns are reflected in his/her creditworthiness. The dunning procedure is stored at contract account level. The payment term determines the due date. This includes the due date for the cash discount. The clearing category controls payment allocation and the clearing of credit notes and receivables. The interest key is used to determine individual conditions for interest calculation. The account determination ID is used for determining general ledger accounts. The account class is not used by SAP programs and can, therefore, be used freely. The tolerance group defines limits for payment differences in the incoming payment. 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.
30
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Figure 25: Creditworthiness 1
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
31
Unit 1: Basics
IUT240
Figure 26: Creditworthiness 2
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 04.01.2003: 5 creditworthiness points (February) * 3 + 15 creditworthiness points (March) * 4 = 75 creditworthiness number If SAP Credit Management from Financial Supply Chain Management is activated, the creditworthiness recorded in FI-CA is passed to the SAP Credit Management and can be used for the rating of the here stored internal creditworthiness. Internal processes such a dunning and returns processing shall be influenced by the internal score of SAP Credit Management and thus it has to be transferred back to FI-CA. It is visible here in the creditworthiness display in FI-CA with the date of the last replication.
32
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Figure 27: Payment Terms
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.
Figure 28: Lock Concept
2006/Q2
© 2006 SAP AG. All rights reserved.
33
Unit 1: Basics
IUT240
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 locks. 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. You can create processing locks with transaction FKLOCK2 (Menu : Periodic Processing → For Contract Accounts). From the selection criteria Business Partner, Contract Account, Contract, Company Code, you can set mass locks for a combination of Lock Category, Process and Lock Reason. To delete mass locks, you can use transaction FPLKDEL.
Figure 29: Locks
Locks for contract account: Dunning, posting, invoicing, correspondence dunning, interest calculation, incoming payments and outgoing payments.
34
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
You can set the lock for a limited period, or multiple locks for the individual business transactions. Hint: If you only define one reason for the lock, then it is valid for an unlimited amount of time. If you only enter one lock reason, then you can change or delete it. If you have set several time-dependent locks, use the arrow key to make changes. You can then enter the changes in a dialog box. If you have set multiple time-dependent locks, then only a ~ is displayed. In this case you can use the arrow key to display the other locks. You can use the FPLKA transaction, under ’Periodic Processing → For Contract Accounts → Evaluation of Processing Locks’ to evaluate locks that have been set. Bank Data and Payment Card Maintenance •
You can use transaction FPP4 to: –
Create new bank details (determine a new bank ID for event 1053)
– –
Change/delete existing bank details Create new payment cards (determine a new payment ID for event 1054)
– – – –
Change/delete existing payment card details and create customer contacts Print confirmation letters Control follow-up actions (such as dunning reversal and reversal of locks) Make further changes to a contract account (event 1083)
Transaction FPP4 makes it considerably easier to change business partner-related bank data. This allows you, for example, to change the bank details for a customer changing from cash payer to direct debit payer in the business partner master record and in dependent objects at the same time in the Maintain Payment Data transaction. You can use a flexible set of rules to control follow-up actions such as the reversal of dunnings. If you set the ’Create Bank ID’ indicator in the client-specific settings in Customizing, you can determine a new bank details ID for the relevant business partner at event 1053.
2006/Q2
© 2006 SAP AG. All rights reserved.
35
Unit 1: Basics
IUT240
If you set the ’Create Credit Card ID’ indicator in the client-specific settings in Customizing, you can determine a new payment card ID for the relevant business partner at event 1054. With a function module processed in event 1083 you can make further changes to the contract account when you save the data. In this event, you can, for example, change the field Planning Group in the contract account if a customer changes from being a cash payer to a direct debit payer.
Figure 30: Maintenance of Bank Data and Payment Card
Transaction FPP4 Maintain Bank Data makes it much easier to change a business partner‘s bank details. This allows you, for example, to change the bank details for a customer changing from cash payer to direct debit payer in the business partner master record and in dependent objects at the same time in the Maintain Payment Data transaction. The following is possible: • • • • • • • •
36
Create new bank details Change/delete existing bank details Create new payment cards Change/delete existing payment card data Create customer contacts Print confirmation letters Control follow-up activities (such as dunning reversal and reversal of locks) Make further changes to a contract account (event 1083)
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
If you set the ’Create Bank ID’ indicator in the client-specific settings in Customizing, you can determine a new bank details ID for the relevant business partner at event 1053. If you set the ’Create Credit Card ID’ indicator in the client-specific settings in Customizing, you can determine a new payment card ID for the relevant business partner at event 1054. With a function module processed in event 1083 you can make further changes to the contract account when you save the data. In this event, you can, for example, change the field Planning Group in the contract account if a customer changes from being a cash payer to a direct debit payer.
Figure 31: Basic Customizing
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” area.
2006/Q2
© 2006 SAP AG. All rights reserved.
37
Unit 1: Basics
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
38
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Master Data Objects in FI-CA
Lesson Summary You should now be able to: • Explain the most important master data objects in FI-CA, and their controlling elements.
2006/Q2
© 2006 SAP AG. All rights reserved.
39
Unit Summary
IUT240
Unit Summary You should now be able to: • Explain the general concept and special functions in FI-CA. • Use event management to integrate customer-specific requirements into the SAP System without modifying SAP programs. • Dramatically reduce the runtime for mass runs (such as payment runs or dunning processing) by using parallel processes. • Explain the most important master data objects in FI-CA, and their controlling elements.
40
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 2 Documents
37
Unit Overview This unit will provide you with an overview of: • • • • •
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 The account balance display
in contract accounts receivable and payable.
Unit Objectives After completing this unit, you will be able to: • • • • •
2006/Q2
Explain the concept of documents and the processes in contract accounts receivable and payable. Explain the specific structure of FI-CA documents and the configuration of document types. Post documents in FI-CA and know the special functions for document entry in contract accounts receivable and payable. Explain the concept of the integration into the general ledger, and know how to process and reconcile the transfer. Navigate to the account balance display and configure it for your needs.
© 2006 SAP AG. All rights reserved.
41
Unit 2: Documents
IUT240
Unit Contents Lesson: Lifecycle of Documents ............................................... 43 Lesson: Document Structures ................................................. 51 Lesson: Posting Documents.................................................... 61 Exercise 1: Entering Documents in Contract Accounts Receivable and Payable ....................................................................... 73 Lesson: Integration with General Ledger Accounting ....................... 80 Exercise 2: Transferring Summary Records to General Ledger Accounting.................................................................... 91 Lesson: Account Balance Display ............................................. 97 Exercise 3: Analysis of Contract Accounts..............................103
42
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 39
Lesson: Lifecycle of Documents
Lifecycle of Documents Lesson Duration: 10 Minutes
Lesson Overview Contract accounts receivable and payable is a sub-ledger accounting component that manages mass data. It is used for processing open items.
Lesson Objectives After completing this lesson, you will be able to: •
Explain the concept of documents and the processes in contract accounts receivable and payable.
Business Example
Figure 32: The Life Cycle of an Open Item (1)
2006/Q2
© 2006 SAP AG. All rights reserved.
43
Unit 2: Documents
IUT240
The life cycle of a receivable item in Contracts Account Receivable and Payable reveals which processes from Contracts Account Receivable and Payable are handled in FI-CA: •
• • •
Open items can be posted in invoicing, dunning, or returns processing. Alternatively, open items can be posted manually in subledger accounting The usual form of document posting is posting from an invoice. Items relevant for the general ledger are regularly compressed and transferred to the general ledger. Cleared documents that have expired can be archived. Opened and cleared items can be displayed in the account display function.
Figure 33: The Life Cycle of an Open Item (2)
Payments are initiated either by the business partner (cash payer) or via payment runs (direct debit). Payments usually clear open items.
44
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Lifecycle of Documents
Figure 34: The Life Cycle of an Open Item (3)
In returns processing, cleared payments are reset, the source receivables are posted as debit items, and return charges are posted. Return charges can be bank charges that are passed on to the business partner or company charges.
Figure 35: The Life Cycle of an Open Item (4)
Overdue items for cash payers or blocked items from direct debit payers can be dunned. Dunning charges or interest on arrears can be posted.
2006/Q2
© 2006 SAP AG. All rights reserved.
45
Unit 2: Documents
IUT240
Figure 36: The Life Cycle of an Open Item (5)
Interest calculation can be carried out automatically in invoicing and 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.
Figure 37: The Life Cycle of an Open Item (6)
Open documents can be deferred manually. A deferral can take place automatically in returns processing.
46
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Lifecycle of Documents
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.
Figure 38: The Life Cycle of an Open Item (7)
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.
Figure 39: The Life Cycle of an Open Item (8)
2006/Q2
© 2006 SAP AG. All rights reserved.
47
Unit 2: Documents
IUT240
Overdue items can be entered as doubtful, adjusted individually or written off.
Figure 40: The Life Cycle of an Open Item (9)
Items can be submitted to external collection agencies. Payments such as interest and external collection agency charges can be posted automatically or manually.
48
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Lifecycle of Documents
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
49
Unit 2: Documents
IUT240
Lesson Summary You should now be able to: • Explain the concept of documents and the processes in contract accounts receivable and payable.
50
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 46
Lesson: Document Structures
Document Structures Lesson Duration: 50 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the specific structure of FI-CA documents and the configuration of document types.
Business Example
Figure 41: Document Types for Single Processing
2006/Q2
© 2006 SAP AG. All rights reserved.
51
Unit 2: Documents
IUT240
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.
Figure 42: Number Ranges for Mass Processing
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.
52
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Structures
Figure 43: Structure of a FI-CA Document (1)
The document header contains general data for the accounts receivable/payable document such as: the document number, document category, document date, posting date, currency, and reconciliation key. Data on the person making entries and on the origin are stored in the administrative data of the document header. Data relevant to posting is stored in the business partner items: Data on the partner/contract, general ledger data (receivables account), data on the receivables amount, specifications on the due date, dunning and clearing data, cash management and forecast data, and other data. Information on offsetting posting is stored in the offsetting item. This normally means the line items for revenue posting(s) and the tax posting line items. Offsetting items and tax lines are created automatically, so only the business partner items must be created.
2006/Q2
© 2006 SAP AG. All rights reserved.
53
Unit 2: Documents
IUT240
Figure 44: Structure of a FI-CA Document (2)
Repetition documents are put into repetition groups. IS-U budget billing plans and installment plans are represented as documents with repetition groups.
Figure 45: Structure of a Payment Document
The clearing document that can be posted, for example, during incoming payment, only consists of a document header and the offsetting item(s).
54
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Structures
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.
Figure 46: Document Structure for Partial Payments
If the incoming payment only results in a partial clearing, the item of the source receivable document is split into a cleared partial item and a partial item that is still open. The clearing data, that is the amount of the partial payment and the document number of the payment, are stored in the cleared partial item.
2006/Q2
© 2006 SAP AG. All rights reserved.
55
Unit 2: Documents
IUT240
Figure 47: Clearing Open Items (Partial Clearing)
In some cases documents do not retain their status. Document changes and the clearing of open items sometimes require that the document is then saved in a different form. This split is required if a partial amount of the open item is cleared. An entry in the subledger is split into two entries; the open portion and the cleared portion. For the new sub-items, you also want to be able to recognize later that they arose from one original item. In order to achieve this, an additional key field is introduced into the Business Partner table: the sub-item number.
56
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Structures
Figure 48: Statistical Postings
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. Dunning charges are also a typical 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. Another example of this are budget billing receivables. 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.
Figure 49: Structure of a Statistical Document
2006/Q2
© 2006 SAP AG. All rights reserved.
57
Unit 2: Documents
IUT240
Statistical documents only consist of a document header and business partner items. These documents are not forwarded to the general ledger.
Figure 50: Payment for Statistical Items
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.
58
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Structures
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
59
Unit 2: Documents
IUT240
Lesson Summary You should now be able to: • Explain the specific structure of FI-CA documents and the configuration of document types.
60
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 55
Lesson: Posting Documents
Posting Documents Lesson Duration: 40 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Post documents in FI-CA and know the special functions for document entry in contract accounts receivable and payable.
Business Example
Figure 51: Goals of Document Entry
2006/Q2
© 2006 SAP AG. All rights reserved.
61
Unit 2: Documents
IUT240
Figure 52: Post Document: Entry Point
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 here. 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.
62
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Figure 53: List Entry: Business Partner Items
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. 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
63
Unit 2: Documents
IUT240
Figure 54: Posting: Foreign Currency
The exchange rate can either be determined from the rates stored in the system, or by an entered exchange rate when entering a document in a foreign currency. If you want to calculate the exchange rate of a specific date, you must enter this exchange rate date. If you do not, the system uses the current rate. If an exchange rate is entered, it is compared to the rates stored in the system. If the rates differ, a message is displayed. An exchange rate can only be entered by users for whom a local currency is stored in their user-specific settings for FI-CA.
64
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Figure 55: Cross-Company Code Posting
The business partner is not allocated to a company code. The information on the paying company code is stored in the contract account via the company code group. Incoming and outgoing payments are handled via the paying company code. Posting examples: • • • • • •
(1) Debit entry (without revenue and tax) (2) Cash receipt in company code 0001 (without bank account display) (3a) Payment allocation in company code 0001 (3b) Payment allocation in company code 0002 (4) Company code 0001 owes a payment to company code 0002. (4) Company code 0002 receives a payment from company code 0001.
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
65
Unit 2: Documents
IUT240
Figure 56: Post Document: Additional Functions
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).
66
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Figure 57: Manual Posting with Clearing
Open items to be cleared may belong to a: • • • • • •
Business partner Contract account (usually 2nd criteria) Contract or contract object Company code Applied period (this is in tax and revenue management usually the 1st criteria) Due date
From the transaction Post document you can access the selection screen for entering selection criteria by clicking on the button Process open items or Select open items.
2006/Q2
© 2006 SAP AG. All rights reserved.
67
Unit 2: Documents
IUT240
Figure 58: Manual Posting with Clearing: Display
In addition to standard display options, you can use create line layouts in customizing to customize the display of fields during display.
Figure 59: Example: Manual Posting with Clearing: Display Options
By double-clicking on the fields in the “Gross” (or another amount column) column, you can select (=activate) the open items that are to be cleared with (assigned to) the amount entered. The gross amount is proposed as the clearing amount. The items are deactivated if you double-click again.
68
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
The amount entered may be insufficient to clear all the activated open items completely. By double-clicking on the open items in the “gross clearing” column, partial clearing of the open item is proposed for the amount that is not yet assigned. You can overwrite this default value. Alternatively, you can enter individual amounts in the fields in the “Gross clearing” column. By putting a checkmark in the box at the beginning of the line, you can select multiple open items for activation or deactivation as a group (also possible from the menu, function keys or line commands).
Figure 60: Clearing: Generation of Line Items
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 charge. 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
69
Unit 2: Documents
IUT240
Figure 61: Clearing: Different Currency
It is possible to clear open items in a different currency. For example, receivables can be cleared in EUR with an incoming payment in USD. All selected open items are recalculated in the clearing currency if they have different document currencies. The calculation is carried out in two steps using the posting date of the clearing document: • •
Document currency -> Local Currency / Local Currency -> Clearing Currency. In this way, maintaining the rates for all currency pairs is not necessary.
The system uses the current average rate for the conversion according the rate table. If you have agreed upon different rates or amounts with the customer, differences will then appear during the conversion. In Account Maintenance (menu: Account -> Maintenance) in the screen Account Maintenance: Process Open Items, you can change the converted amounts and prevent these differences. The clearing currency and the clearing amount are stored in a cleared item.
70
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Figure 62: Interfaces for Transferring IDocs
The IDoc interface is a standard communication procedure of the SAP System and is used to exchange business information with an external system or another SAP System. In order to be able to receive and process data from an external billing system efficiently and carry out a mass transfer of data effectively, the IDoc interfaces of FI-CA use the infrastructure of the IDoc technology. You can use the FI-CA IDoc interfaces to: • • • •
Transfer bill documents and (if desired) update data in CO-PA Set an archive link to optically archived bills or archive external documents Transfer reversals of bills Transfer open items to the legacy system to be printed on bills
An optimized processing of the usually large data volume created, for example, in a bill or reversal run, is achieved by scaled parallelization of processing in mass runs where you can process intervals of IDocs on several application servers in parallel.
2006/Q2
© 2006 SAP AG. All rights reserved.
71
Unit 2: Documents
72
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
67
Lesson: Posting Documents
Exercise 1: Entering Documents in Contract Accounts Receivable and Payable Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Explain how to enter a document manually in Contract Accounts Receivable and Payable.
Business Example Documents are usually created automatically in the subledger accounting of FI-CA. Documents can also be created manually in special cases.
2006/Q2
© 2006 SAP AG. All rights reserved.
73
Unit 2: Documents
IUT240
Task 1: Hint: First save your user parameters. To do this, choose the following menu path: System → User Parameters → Own Data in Parameters Tab Page Enter the following parameters: BUK:
U100 (company code)
FWS:
EUR (currency key)
8P3:
(post without jurisdiction code)
If you are on a course without US scenarios. BUK:
U300 (company code)
FWS:
USD (currency key)
8P3:
X (post with jurisdiction code)
If you are on 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.
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.
Which document type does the system propose?
2.
Where can you define the proposed document type in the system?
3.
Use the following data to enter the documents: Document date:
07.05.2006
Posting date:
07.05.2006
Reconciliation key:
Is proposed by the system
Continued on next page
74
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Currency:
EUR (USD)
Company code:
U100 (U300)
Tax:
Calculate automatically → x
Enter the additional data with the “New Business Partner Item” function: Business partner:
PICA0210## (PI0202C0##)
Contract account:
PICA0210## (PI0202C0##)
Transaction:
6000 / 0020
Amount:
200,00
Repeat the transaction for this business partner and the amount of USD 300.00. Write down the document numbers: ______________________________________
Task 2: 1.
Which payment date (due date) was determined for the receivable? ___________
Task 3: 1.
How can you control the determination of the payment date? ____________
Task 4: Display your documents in the account display. 1.
2006/Q2
Use the following information: Business partner:
PICA0210## (PI0202C0##)
Company code:
U100 (U300)
List Type:
“All items ”
Line layout:
Standard Line Layout – Account Display
© 2006 SAP AG. All rights reserved.
75
Unit 2: Documents
IUT240
Solution 1: Entering Documents in Contract Accounts Receivable and Payable Task 1: Hint: First save your user parameters. To do this, choose the following menu path: System → User Parameters → Own Data in Parameters Tab Page Enter the following parameters: BUK:
U100 (company code)
FWS:
EUR (currency key)
8P3:
(post without jurisdiction code)
If you are on a course without US scenarios. BUK:
U300 (company code)
FWS:
USD (currency key)
8P3:
X (post with jurisdiction code)
If you are on 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.
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.
Which document type does the system propose? a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post Continued on next page
76
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
The system proposes document type AB. 2.
Where can you define the proposed document type in the system? a)
The document type is defined in Customizing in the IMG. Choose: Tools → Customizing → IMG → Execute 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.
3.
Use the following data to enter the documents: Document date:
07.05.2006
Posting date:
07.05.2006
Reconciliation key:
Is proposed by the system
Currency:
EUR (USD)
Company code:
U100 (U300)
Tax:
Calculate automatically → x
Enter the additional data with the “New Business Partner Item” function: Business partner:
PICA0210## (PI0202C0##)
Contract account:
PICA0210## (PI0202C0##)
Transaction:
6000 / 0020
Amount:
200,00
Repeat the transaction for this business partner and the amount of USD 300.00. Write down the document numbers: ______________________________________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post and and make the entries as specified.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
77
Unit 2: Documents
IUT240
Task 2: 1.
Which payment date (due date) was determined for the receivable? ___________ a)
The receivables are due immediately based on the posting date.
Task 3: 1.
How can you control the determination of the payment date? ____________ a)
The payment date is determined using the payment conditions in the contract account.
Task 4: Display your documents in the account display. 1.
Use the following information: Business partner:
PICA0210## (PI0202C0##)
Company code:
U100 (U300)
List Type:
“All items ”
Line layout:
Standard Line Layout – Account Display
a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance
78
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Posting Documents
Lesson Summary You should now be able to: • Post documents in FI-CA and know the special functions for document entry in contract accounts receivable and payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
79
Unit 2: Documents
Lesson: 74
IUT240
Integration with General Ledger Accounting Lesson Duration: 40 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the concept of the integration into the general ledger, and know how to process and reconcile the transfer.
Business Example
Figure 63: Contract Accounts Receivable and Payable as a Subledger
FI-CA serves as a subledger as well as an integrator of accounting data that originates (for the most part) from various prestored applications and systems. These applications pass their posting data to FI-CA for further processing. Instead of individually posting each document created in the subledger to the general ledger and controlling, summary records are transferred (batch processing). Each
80
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
summary record is posted to the general ledger. This summarization technique greatly reduces the volume of postings in the general ledger and results in a tremendous performance advantage. The transfer of bills from convergent invoicing is dealt with later in its own unit.
Figure 64: Integration with FI General Ledger: Definitions
Summary records are saved in the DFKKSUM* tables. 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. Additional account assignments of Funds Management, such as funds center or commitment item.
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. Furthermore, the document type for the general ledger transfer can be individually predefined for each document in FI-CA. A function module, which is defined at event 0061, is used to make the specifications. Separate summary records are listed for FI-CA documents with different document types for the general ledger transfer. The documents for the general ledger transfer are
2006/Q2
© 2006 SAP AG. All rights reserved.
81
Unit 2: Documents
IUT240
generated separately according to these document types. If no document type is issued for the general ledger transfer, then the posting is executed using the document type defined in Customizing for posting area 0100. As of release ERP 2005, a function is available for reversing the general ledger transfer. The documents are reversed as a real reversal in the general ledger or, if a real reversal is not possible, as an offsetting entry. The reversal is executed on the posting date of the document to be reversed. It is not possible to post with a different posting date. It is only possible to completely reverse all documents for a reconciliation key and company code.
Figure 65: Reconciliation Key Structure: Automatic Determination
Various business processes create a reconciliation key in the system. The reconciliation key is identified by the current day in the business year - which is derived from the creation date - and the source or name. Reconciliation keys that have been created automatically are closed automatically at the end of the business process. The system can also propose reconciliation keys for manual business transactions (post document, payment at cash desk ...). In order to do this, reconciliation groups for default values must be maintained in Customizing. These reconciliation keys can be accepted or overwritten. You must close them manually before transfer to the general ledger.
82
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
Figure 66: Tools: Reconciliation Keys
The reconciliation key can be can be structured user (group) specifically for online postings. User-dependent and user-independent reconciliation keys can also be proposed for origin keys stored in Customizing. However, for this to happen, the SAP function modules FKK_SAMPLE_1113_USER or FKK_SAMPLE_1113 must be used in event 1113. During mass closing (transaction FPG4), the system closes all keys that are not reserved for a specific group of postings, for example postings for a payment run or a payment or returns lot. In addition to this, keys that are reserved for posting invoicing documents from Sales and Distribution (SD) are also closed If necessary, you can also delete reconciliation keys that have been created but are not used. To do this, select the Delete Unused Open Keys or the Delete Unused Closed Keys parameter. Document itemization for reconciliation key (RFKKABS30): The report selects all FI-CA documents posted under a reconciliation key The FI-CA totals records are selected according to the selection criteria. The corresponding FI-CA document line items are selected and sorted.
2006/Q2
© 2006 SAP AG. All rights reserved.
83
Unit 2: Documents
IUT240
Figure 67: FI-CA Document - Summary Record - FI Document
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: • • •
84
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)
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
Figure 68: Reference Documents: FI-CA => Summary => FI
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
85
Unit 2: Documents
IUT240
Figure 69: Reconciliation: General Ledger Documents
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.
86
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
Figure 70: Reconciliation: FI-CA with the General Ledger
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
87
Unit 2: Documents
IUT240
Figure 71: Reconciliation: Open Items
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 in the contract accounts receivable and payable general ledger. 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.
88
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
Figure 72: Documents: Customizing (1)
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
89
Unit 2: Documents
IUT240
Figure 73: Documents: Customizing (2)
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: •
•
90
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).
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
85
Lesson: Integration with General Ledger Accounting
Exercise 2: Transferring Summary Records to General Ledger Accounting Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Transfer cumulated posting data to general ledger accounting.
Business Example The summary records listed in Contract Accounts Receivable and Payable are transferred to G/L accounting during day-end closing.
Task 1: Transfer to general ledger accounting 1.
Display the documents. Where can you find the corresponding reconciliation key in the document? Write down the reconciliation key: _________________________________________________________
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? _________________________________________________________
3.
Once you have closed the reconciliation key, transfer this reconciliation key to G/L accounting. Use the following information: Reconciliation key:
Predefined (see exercise 1)
Test run:
SPACE
List of documents created:
X
Task 2: Status of reconciliation key 1.
Which status is assigned to the reconciliation key after the transfer to general ledger accounting? _________________________________________________________ Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
91
Unit 2: Documents
IUT240
Task 3: G/L accounting document 1.
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? _________________________________________________________
92
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
Solution 2: Transferring Summary Records to General Ledger Accounting Task 1: Transfer to general ledger accounting 1.
Display the documents. Where can you find the corresponding reconciliation key in the document? Write down the reconciliation key: _________________________________________________________ a)
The reconciliation key is saved in the Document Header, in the Reconciliation Key field. To do this, choose Goto → Document Header in the document display.
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? _________________________________________________________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Reconciliation Key → Close
b)
Choose the Goto → Totals Records function.
c)
Choose the Reconciliation Key → Close function.
d)
The status changes from “Reserved for Individual Postings → Postings Can Be Made” to: “Reserved for Individual Postings → Postings Are No Longer Allowed”
3.
Once you have closed the reconciliation key, transfer this reconciliation key to G/L accounting. Use the following information:
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
93
Unit 2: Documents
IUT240
Reconciliation key:
Predefined (see exercise 1)
Test run:
SPACE
List of documents created:
X
a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Periodic Processing → Forward Postings → Execution → Transfer to General Ledger
Task 2: Status of reconciliation key 1.
Which status is assigned to the reconciliation key after the transfer to general ledger accounting? _________________________________________________________ a)
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
Task 3: G/L accounting document 1.
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?
Continued on next page
94
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration with General Ledger Accounting
_________________________________________________________ a)
Choose: Accounting → Financial Accounting → General Ledger → Document Display → List
2006/Q2
b)
Enter FKKSU as the reference procedure. Enter the reconciliation key with “*” as the last character for the reference key.
c)
Choose Program → Execute.
d)
In the document header of the G/L accounting document, the FKKSU reference procedure is saved, and the reconciliation key is saved as the reference key.
© 2006 SAP AG. All rights reserved.
95
Unit 2: Documents
IUT240
Lesson Summary You should now be able to: • Explain the concept of the integration into the general ledger, and know how to process and reconcile the transfer.
96
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 91
Lesson: Account Balance Display
Account Balance Display Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Navigate to the account balance display and configure it for your needs.
Business Example
Figure 74: Account Balance Display
FI-CA through its account balance display functionality enables quick and comprehensive account information to be obtained regarding open, cleared, or statistical items.
2006/Q2
© 2006 SAP AG. All rights reserved.
97
Unit 2: Documents
IUT240
The display functionality is flexible in that search criteria can be defined and maintained by and for the individual user. Through the use of additional ‘selection criteria’ the user can further refine the search parameters. For example, a user might wish to search for items within a specific dollar amount range. This could be done by maintaining the amount “search range” accordingly. List types determine which type(s) of of line items are displayed with the account balance, such as open items, cleared items, additional business partner items, and so on. They also determine which types (if any) of statistical items should appear, and which document category to search by. If a sorting variant is not specified, the system will use the first 6 fields defined in the line layout variant for sorting (ascending order). User parameter 814 selects the last setting of ‘normal’ versus “reduced” initial screen (i.e. selection screen where parameters are entered prior to actually viewing an account balance). User Parameter 815 saves the last recorded initial “list display” screen, but will be overwritten if parameter 810 is active.
Figure 75: Line Layout Variants
Each line layout variant must either be defined as a “totals” variant or a “line-item” variant.
98
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Balance Display
Figure 76: Account Balance Display: Structure of Totals Variant
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.
Figure 77: Account Balance Display: Further Functions
Restriction of Item Selection: If you select the button Period for Item Selection (F7) on the initial screen of the account balance display, you can restrict the period that the system uses for selecting the items in the account balance.
2006/Q2
© 2006 SAP AG. All rights reserved.
99
Unit 2: Documents
IUT240
Context Menu in the Account Balance: You can call up a context menu by clicking on the right mouse button when the cursor is on an item in the account balance. In events 1247 and 1248, you can adjust the functions of the context menu to meet your requirements or add to them.
Figure 78: Account Balance Display: Events
Figure 79: Creating Snapshots
100
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Balance Display
For business partners whose contract accounts have a larger number of items, you can create the account balance display from a previously selected set of items (a snapshot). Reading the items in the account balance for a business partner with a large number of items usually takes up a lot of time. To avoid long response times, you can use this report to preselect items for particularly large partners and display them in the account balance instead of the current list. In the Implementation Guide for Contract Accounts Receivable and Payable, under Basic Functions → Account Balance Display → Business Partner → Define Business Partner for Creation of Snapshots, you must enter the business partners with large numbers of items. This setting is one of the current system settings and, therefore, you can access it in the menu under Current Settings (Business Partner for Snapshots). In order to ensure that the account balance is up-to-date, you should update this balance at regular intervals.
Figure 80: Displaying Snapshots
When you call up the account balance display, the system checks whether a unique business partner can be determined from the selection conditions. If the system has determined a business partner and a snapshot exists for this business partner: • • •
2006/Q2
The system imports this snapshot The system checks the current selection conditions The system displays the result in the list with corresponding information that the data is not up-to-date and with the date of the snapshot.
© 2006 SAP AG. All rights reserved.
101
Unit 2: Documents
IUT240
If you are in a snapshot display, you can deactivate the snapshot from the menu via Account Balance → Current Status. The system then reads the current data.
Figure 81: Documents: Customizing
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.
102
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
97
Lesson: Account Balance Display
Exercise 3: Analysis of Contract Accounts Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Analyze Contract Accounts.
Business Example 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.
Task: Account display 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? _______________________________________________________________
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? _______________________________________________________________
3.
Branch from the display of an installment plan receivable to the display of the source receivable(s). Describe your actions. _______________________________________________________________ _______________________________________________________________
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 payment run? _______________________________________________________________
2006/Q2
© 2006 SAP AG. All rights reserved.
103
Unit 2: Documents
IUT240
Solution 3: Analysis of Contract Accounts Task: Account display 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? _______________________________________________________________ a)
2.
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance. List Type:
Standard - All Open Items
Line Layout:
Standard Line Layout – Account Display
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? _______________________________________________________________ a)
Choose the list type: Open Items (Statistical and Non-Statistical) All additional installment plan receivables and dunning charges receivables are displayed.
3.
Branch from the display of an installment plan receivable to the display of the source receivable(s). Describe your actions. _______________________________________________________________ _______________________________________________________________ a)
Double-click on an installment plan receivable. Choose Environment → Source Items → For Installment Plan in the source receivables display. Alternatively, you can choose the Installment Plans button (cntrl + 9) and display the source receivables via Environment → Source Receivables (Account Display).
Continued on next page
104
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Balance Display
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 payment run? _______________________________________________________________ a)
Choose the Payment List tab in the item display. Determine the payment run and choose the button at the start of this line to display the detail view. The payment has cleared other receivables and installment plan items.
2006/Q2
© 2006 SAP AG. All rights reserved.
105
Unit 2: Documents
IUT240
Lesson Summary You should now be able to: • Navigate to the account balance display and configure it for your needs.
106
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Explain the concept of documents and the processes in contract accounts receivable and payable. • Explain the specific structure of FI-CA documents and the configuration of document types. • Post documents in FI-CA and know the special functions for document entry in contract accounts receivable and payable. • Explain the concept of the integration into the general ledger, and know how to process and reconcile the transfer. • Navigate to the account balance display and configure it for your needs.
2006/Q2
© 2006 SAP AG. All rights reserved.
107
Unit Summary
108
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 3 Transactions and Account Determination
103
Unit Overview This unit will enable you to understand: • • • •
The structure of the transactions The determination of general ledger accounts The tax determination process The Customizing of transactions that map your business transactions.
Unit Objectives After completing this unit, you will be able to: • • • • • •
Know the definition and structure of transactions. Understand the special functions of transactions in IS-U. Configure the automatic general ledger account determination in FI-CA. Explain the special tax determination functions in contract accounts receivable and payable. Explain the special tax determination features for billing in IS-U. Know the special features in the US tax determination.
Unit Contents Lesson: Lesson: Lesson: Lesson:
2006/Q2
Structure of Transactions ........................................... 111 Transactions in IS-U.................................................. 118 General Ledger Account Determination ...........................122 Tax Determination ....................................................130
© 2006 SAP AG. All rights reserved.
109
Unit 3: Transactions and Account Determination
IUT240
Exercise 4: Configuring Transactions....................................133 Lesson: Tax Determination in IS-U ...........................................141 Lesson: USA - Tax Jurisdiction Code (Only relevant for US training)....146
110
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 104
Lesson: Structure of Transactions
Structure of Transactions Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Know the definition and structure of transactions.
Business Example
Figure 82: Transactions
A transaction is a combination of main and sub-transactions. The texts allocated to the main and sub-transactions explain the corresponding business transaction and are available in the correspondence. The main transaction controls the determination of receivables and payables accounts.
2006/Q2
© 2006 SAP AG. All rights reserved.
111
Unit 3: Transactions and Account Determination
IUT240
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 industry-specific versions use internal main and sub-transactions that are assigned by various business processes and that control these processes. These internal transactions are 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 maintain any number of transactions that do not correspond to internal transactions. Transactions in FI-CA 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.
Figure 83: Assigning Main Transactions and Subtransactions
Internal transactions are those transactions which take place within FI-CA and its industry-specific versions. The main examples of these transactions are charges, interest, payments on account, clarification postings, and so on. These main and subtransactions thus serve to provide parameters needed for the posting of these ‘internal’ transactions. NOTE: Each entry delivered in this table must be assigned to an ‘ID’ by the customer, regardless if the customer chooses not to rename the transactions (i.e if the customer wishes not to rename the entry for main transaction 0010 subtransaction 0100, then he must place identical entries in the space for external assignment). These internal transactions are hard-coded. Do NOT delete them.
112
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Structure of Transactions
Main transactions and subtransactions are used to identify items based on their type (such as interest and charge) as well as the business process from which they originated (payments, account statements, and so on). This function links each item with a main transaction to which several subtransactions are assigned. For example, there is a main transaction “charge” and associated subtransactions “dunning charge”, “return charge”, “return charge 1”, “return charge 2”, “correspondence charge”, “installment plan charge”, and so on.
Figure 84: Maintain Main Transactions and Subtransactions
A user is free to define new entries in this table for use for transactions not defined as ‘internal’ to FI-CA. These additional main and sub entries can be used in general ledger account determination. You can also define whether the amount entered can be negative or positive. All postings in FI-CA contain information on the business transaction in the main and sub transactions. You can assign additional attributes to the transactions in Customizing. These attributes are copied in the business partner item when the posting is made and can influence the following business transactions.
2006/Q2
© 2006 SAP AG. All rights reserved.
113
Unit 3: Transactions and Account Determination
IUT240
Figure 85: Freely Defined Transactions
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.
114
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Structure of Transactions
Figure 86: Allocating an Internal Transaction - Defined Transaction
Examples: • •
•
2006/Q2
Customer-specific transactions: Other receivables for manual postings (6000 / 0020 in the training system) do not correspond to internal transactions. Depending on the charge schema selected in the dunning steps of a dunning procedure, dunning charges must be posted either statistically or as relevant for the general ledger. The transaction is ’allocated’ to the business process (specifies, which defined transaction is used in the business process) with the option of creating 1:n relationships. The rate structure in IS-U Billing and Invoicing enables you to create different rate steps, which generate posting-relevant bill lines to different revenue accounts and CO account assignments. The freely defined subtransactions are included in these rate steps. Allocations cannot be made in the transaction configurations due to the customer-defined rates and subtransactions.
© 2006 SAP AG. All rights reserved.
115
Unit 3: Transactions and Account Determination
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
116
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Structure of Transactions
Lesson Summary You should now be able to: • Know the definition and structure of transactions.
2006/Q2
© 2006 SAP AG. All rights reserved.
117
Unit 3: Transactions and Account Determination
Lesson: 110
IUT240
Transactions in IS-U Lesson Duration: 15 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Understand the special functions of transactions in IS-U.
Business Example
Figure 87: Subtransactions in IS-U Billing / Invoicing
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.
118
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Transactions in IS-U
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).
Figure 88: Subtransactions in the Statistical Budget Billing Procedure in IS-U
The payment and transfer procedures should be allocated to the internal procedures. Account determination is not 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”). Account determination must be defined for these transactions.
2006/Q2
© 2006 SAP AG. All rights reserved.
119
Unit 3: Transactions and Account Determination
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
120
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Transactions in IS-U
Lesson Summary You should now be able to: • Understand the special functions of transactions in IS-U.
2006/Q2
© 2006 SAP AG. All rights reserved.
121
Unit 3: Transactions and Account Determination
Lesson: 113
IUT240
General Ledger Account Determination Lesson Duration: 20 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Configure the automatic general ledger account determination in FI-CA.
Business Example
Figure 89: Posting Areas
The posing areas are broken down into the following areas: • •
•
122
Posting areas for all application areas (for example, posting area used to identify a tax account based on the tax code) Posting areas for more than one application area (for example, posting area used to determine the default values for incoming payments). You can make a number of different specifications for each application area. Application-Specific posting areas -> prefixed by the letter from the application area
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: General Ledger Account Determination
The active application area is defined in the user parameters and/or by selecting the application area. You can maintain the posting areas either in transaction FQC0 or in the implementation guide. 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.
Figure 90: Posting Areas
You can always enter several derivation rules. If the system does not display the necessary key fields at first, call them by choosing the menu path GOTO → SELECT KEYS.
2006/Q2
© 2006 SAP AG. All rights reserved.
123
Unit 3: Transactions and Account Determination
IUT240
Access Sequence: As standard, the system first attempts to impart an entry with recourse to all used key fields. If this does not work, the last key field is excluded at the next attempt. At the last attempt, only the first key field value is used. You can change this standard procedure with user-defined access sequences. To do this, you define: • •
Which of the possible key fields are relevant for the determination of the G/L account In which order the system uses your key field definitions for the determination of the G/L accounts
Test your customizing by clicking on „simulation“. There is also an error analysis if the derivation was not possible.
Figure 91: General Ledger Account Determination 1
General ledger accounts are determined by means of standard account determination functionality. This function takes a subset of posting parameters and checks a special allocation table that is set up in FI-CA customizing. G/L account determination is done via main transactions and subtransactions from the line items of postings and account determination ID. The account determination ID is derived from the contract account, the account determination ID of the contract object (PS-CD), or the contract (IS-U). The event for determining the reconciliation account is 1101. The event for determining the revenue account is 1100.
124
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: General Ledger Account Determination
Figure 92: General Ledger Account Determination 2
The account determination ID is automatically derived from the contract account category, when an item is posted. Each individual posting in the subledger is allocated to exactly one receivables / payables account in the general ledger. A negative transfer amount is a credit, and positive amount a debit. Hint: General ledger accounts used in line items for business partners (receivables, payables, down payments, etc.) must be designated as being reconciliation account category “V”. This prevents unintentional direct postings to these accounts, and thus avoids potential complication of the reconciliation process. Revenue Account: The account determination logic is the same for income statement account determination as for balance sheet account determination. A subset of fields is used from the documents to determine automatically the general ledger account in which to post.
2006/Q2
© 2006 SAP AG. All rights reserved.
125
Unit 3: Transactions and Account Determination
IUT240
Figure 93: Account Determination - Reconciliation Account
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/contract object for contract-related business transactions. The account determination ID controls determination of the receivables account in FI-CA (together with the main transaction resulting from the business transaction). The company code and, potentially, the division are further criteria. The same receivables account is determined for identical business transactions for contract accounts with the same account determination IDs, for example residential customers or companies connected inland. You can use different account determination IDs to access different receivables accounts in general ledger accounting.
126
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: General Ledger Account Determination
Figure 94: Account Determination: Sales Revenue Account
The subtransaction is also required for the revenue account determination This enables you to allocate different revenue accounts to one business transaction (main transaction) by defining special subtransactions. It is also possible to allocate different revenue accounts for each company code and division. The business area and sales/purchase tax code are defined in revenue account determination. Further account assignment characteristics (such as cost and profit centers) can be saved there using the CO account assignment key. In IS-U, you can override the auxiliary account assignments from cost accounting using a contract-dependent CO account assignment key that is defined in the IS-U contract.
2006/Q2
© 2006 SAP AG. All rights reserved.
127
Unit 3: Transactions and Account Determination
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
128
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: General Ledger Account Determination
Lesson Summary You should now be able to: • Configure the automatic general ledger account determination in FI-CA.
2006/Q2
© 2006 SAP AG. All rights reserved.
129
Unit 3: Transactions and Account Determination
Lesson: 120
IUT240
Tax Determination Lesson Duration: 20 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the special tax determination functions in contract accounts receivable and payable.
Business Example
Figure 95: Tax: Tax Code Determination
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.
130
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Tax Determination
The tax accounts to be posted are defined in the posting area 0010 depending on company code, sales tax code and tax transaction.
Figure 96: Tax: Tax Change
Example: Tax increase from 15% to 16%: • • • •
2006/Q2
The sales/purchase tax determination code E1 is valid from 01/01/1995 to 03/31/1998. The tax determination ID A1 is valid in general ledger accounting for this period. The tax code (A3) resulting from the change of tax must be newly defined in general ledger accounting. In FI-CA, a new validity period is specified, in which the new tax code is allocated.
© 2006 SAP AG. All rights reserved.
131
Unit 3: Transactions and Account Determination
IUT240
Figure 97: Transactions and Account Determination: Customizing
In the activity, “Maintain ...... Transactions for Industry Components”, 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. 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.
132
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
123
Lesson: Tax Determination
Exercise 4: Configuring Transactions Exercise Duration: 30 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Expand the transaction definition in FI-CA. • Explain the concept of account determination in FI-CA. • Explain how sales/purchase tax determination works.
Business Example FI-CA requires defined transactions in order to post documents. Account assignments are also defined using the posting function in subledger accounting.
2006/Q2
© 2006 SAP AG. All rights reserved.
133
Unit 3: Transactions and Account Determination
IUT240
Task 1: Concept
1.
What does a transaction consist of and what does it represent in FI-CA?
2.
What controlling tasks form the basis of the transaction concept?
3.
What is a posting area?
Task 2: Definitions 1. Hint: Check with your instructor that Customizing has been opened for concurrent access to the necessary transaction configuration tables and posting areas. 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”. 2.
Define the account determination in the chart of accounts INT:
Continued on next page
134
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
2006/Q2
Lesson: Tax Determination
Receivables account:
140520
Revenue account:
800525
Value-added tax determination code:
E1
CO account assignment:
1
3.
Post a document to contract account PICA0210## (PI0202C0##) using your new transaction SB## / FO##.
4.
Why does your transaction not have to be allocated to an internal transaction?
© 2006 SAP AG. All rights reserved.
135
Unit 3: Transactions and Account Determination
IUT240
Solution 4: Configuring Transactions Task 1: Concept 1.
What does a transaction consist of and what does it represent in FI-CA? Answer: A transaction consists of a main transaction and a subtransaction. It represents the business transaction that is currently being processed in FI-CA.
2.
What controlling tasks form the basis of the transaction concept? Answer: 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).
3.
What is a posting area? Answer: A posting area is a subprocess that supports automatic determination of certain data required to create documents.
Task 2: Definitions 1. Hint: Check with your instructor that Customizing has been opened for concurrent access to the necessary transaction configuration tables and posting areas.
Continued on next page
136
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Tax Determination
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”. a)
Choose: Tools → Customizing → IMG → Execute 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 → 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 Define Sub-Transactions maintenance level. Select “New Entries” and define your 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: Company code:
U100 (U300)
Division: Short text:
soFo## (othRec.##)
Long text:
Other receivables ## (other Receivables ##)
Main transaction:
SB##
Subtransaction:
FO##
Debit/credit indicator:
Debit
Manual posting allowed:
X
Save your entries and use F3 to exit the maintenance dialog. 2.
Define the account determination in the chart of accounts INT: Receivables account:
140520
Revenue account:
800525
Value-added tax determination code:
E1
CO account assignment:
1 Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
137
Unit 3: Transactions and Account Determination
a)
IUT240
Choose the following path in the SAP Reference IMG: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Define Account Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U: Define Acct Assmt Data Relevant to Main Transactions. Enter INT as the chart of accounts. Select Create (shift + F4). This takes you to a maintenance step where you can enter the receivables account for your main transaction. Enter the following data: Company code:
U100 (U300)
Division: Act determ. ID:
01
Main transaction:
SB##
Enter G/L account 140520 (receivables account), save your entry and use F3 to exit this activity. Then choose Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents → Document → Define Account Assignments for Automatic Postings → Automatic G/L Account Determination → IS-U: Define Acct Assmt Data Relevant to Transactions. Enter INT as the chart of accounts. Select Create (shift + F4). This takes you to a maintenance step where you can enter the receivables account for your main transaction. Enter the following data: Company code:
U100 (U300)
Division: Act determ. ID:
01
Main transaction:
SB##
Subtransaction:
FO##
Enter G/L account 800520 (sales revenue account), the tax determination code E1, and CO account assignment. Save your entry and use F3 to exit this activity. Continued on next page
138
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Tax Determination
3.
Post a document to contract account PICA0210## (PI0202C0##) using your new transaction SB## / FO##. a)
4.
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, lesson 2. This time, however, select your new transaction SB## / FO##.
Why does your transaction not have to be allocated to an internal transaction? Answer: This transaction is used for other manual postings and does not correspond to an internal transaction defined by a SAP program.
2006/Q2
© 2006 SAP AG. All rights reserved.
139
Unit 3: Transactions and Account Determination
IUT240
Lesson Summary You should now be able to: • Explain the special tax determination functions in contract accounts receivable and payable.
140
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 131
Lesson: Tax Determination in IS-U
Tax Determination in IS-U Lesson Duration: 10 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the special tax determination features for billing in IS-U.
Business Example
Figure 98: Tax: Procedure for Changing Tax IS-U (1)
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
141
Unit 3: Transactions and Account Determination
IUT240
Figure 99: Tax: Procedure for Changing Tax IS-U (2)
Tax determination codes contained in the billing period are determined during creation of the billing document. The resulting tax code provides information on the tax percentage rate and tax account. If the tax changes within the billing period, proration occurs in the billing line items.
Figure 100: Transactions and Account Determination: Customizing
142
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Tax Determination in IS-U
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) must be defined in the contract master record, however, they can be included in the posting area R001 before the contract account CO account assignments. 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
143
Unit 3: Transactions and Account Determination
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
144
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Tax Determination in IS-U
Lesson Summary You should now be able to: • Explain the special tax determination features for billing in IS-U.
2006/Q2
© 2006 SAP AG. All rights reserved.
145
Unit 3: Transactions and Account Determination
Lesson: 135
IUT240
USA - Tax Jurisdiction Code (Only relevant for US training) Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Know the special features in the US tax determination.
Business Example Tax Calculation Based on Jurisdiction Code • • • •
146
Standard SAP interface for internal or external tax calculation with jurisdiction code Determination of tax code is the same as without jurisdiction code Jurisdiction code assigned at contract level and contract account level Tax rate changes maintained in table TE012 if tax calculation is executed in an external system
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: USA - Tax Jurisdiction Code (Only relevant for US training)
Figure 101: Jurisdiction Code Assigned in Contract
The tax jurisdiction code is used for determining the tax rates in the USA. The jurisdiction code defines the tax authority you have to pay your taxes to. It is always the city to which the goods / services are supplied. You may enter the tax jurisdiction codes in the data relevant to billing on the contract. The jurisdiction code on the contract is assigned during move-in.
2006/Q2
© 2006 SAP AG. All rights reserved.
147
Unit 3: Transactions and Account Determination
IUT240
Figure 102: Jurisdiction Code Assigned in Contract Account
The system uses the jurisdiction code on the contract for calculating contract-related taxes. For transactions that do not involve a contract, the jurisdiction code on the contract account is used.
Figure 103: External System - Tax Rate Change
You have to manually maintain this table for tax changes since there is an interface is not yet available.
148
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: USA - Tax Jurisdiction Code (Only relevant for US training)
If no data is maintained in Customizing, the actual billing data is used for tax determination.
Figure 104: Tax Determination with Jurisdiction Code
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
149
Unit 3: Transactions and Account Determination
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
150
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: USA - Tax Jurisdiction Code (Only relevant for US training)
Lesson Summary You should now be able to: • Know the special features in the US tax determination.
2006/Q2
© 2006 SAP AG. All rights reserved.
151
Unit Summary
IUT240
Unit Summary You should now be able to: • Know the definition and structure of transactions. • Understand the special functions of transactions in IS-U. • Configure the automatic general ledger account determination in FI-CA. • Explain the special tax determination functions in contract accounts receivable and payable. • Explain the special tax determination features for billing in IS-U. • Know the special features in the US tax determination.
152
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 4 Incoming Payments
141
Unit Overview
Unit Objectives After completing this unit, you will be able to: • •
• •
Name the different payment types in contract accounts receivable and payable. Explain the object of the lot in contract accounts receivable and payable, and explain the procedure for the manual and automatic generation and processing of lots. Explain the processing options offered by clarification processing. Process payments at the cash desk and know the principles of the cash journal.
Unit Contents Lesson: Processing Incoming and Outgoing Payments ...................154 Lesson: Payment Lots and Check Lots ......................................158 Exercise 5: Entering Payments in Payment Lots.......................171 Lesson: Clarification Processing..............................................176 Exercise 6: Clarification Processing .....................................189 Lesson: Cash Desk / Cash Journal...........................................193 Exercise 7: Cash Desk / Cash Journal ..................................205
2006/Q2
© 2006 SAP AG. All rights reserved.
153
Unit 4: Incoming Payments
Lesson: 142
IUT240
Processing Incoming and Outgoing Payments Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Name the different payment types in contract accounts receivable and payable.
Business Example
Figure 105: Initiation of Payment Transactions
154
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing Incoming and Outgoing Payments
The payment program considers the open items due from all business partners or contract accounts that have been selected. It can be used to process both incoming and outgoing payments. In case of payments initiated by the customer, the customer decides when to pay. Payments initiated from outside can be processed by a payment lot/check lot and automatic clearing. Alternatively, payments can be handled through the cash desk (cash journal). When payment is initiated by our organization the organization determines when it will collect or disburse payments from/to the business partner. All payments initiated by our organization are processed by the payment program.
Figure 106: Incoming Payment Processing: Externally Initiated
The open item that corresponds to an incoming payment is found and - as far as possible - cleared (by partial or overpayment if necessary). Most open items are cleared automatically (clearing procedure). If unable to automatically determine the open item to be paid, you can assign payments manually to one or more open items. Customer-initiated incoming payment methods are generally posted through the use of payment lots. Payment card payment postings may be posted manually online and therefore can be considered a customer-generated payment method as well as an internally generated method. Payments not assigned to an open item can be posted on account or put into the clarification controller for clarification activities.
2006/Q2
© 2006 SAP AG. All rights reserved.
155
Unit 4: Incoming Payments
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
156
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing Incoming and Outgoing Payments
Lesson Summary You should now be able to: • Name the different payment types in contract accounts receivable and payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
157
Unit 4: Incoming Payments
Lesson: 145
IUT240
Payment Lots and Check Lots Lesson Duration: 45 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the object of the lot in contract accounts receivable and payable, and explain the procedure for the manual and automatic generation and processing of lots.
Business Example
Figure 107: Payment Lots and Check Lots
Payment/check lots are used in connection with payments initiated by business partners. The payment/check lot is an object, which is used for storing data from externally-initiated payments. Data from payments that have a common origin or that should be processed together are stored in one lot.
158
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
You enter payment/check lots manually if the payment information exists in written (paper) form. This is normally the case for check payments, although incoming bank transfers can also be entered manually. Payment/check lots are created automatically by the system if payments are transferred in the form of an electronic bank statement. If you are not using ERP’s Cash Management system, then you must create a program which converts the bank statements into a file that can be read by FI-CA. This file is then converted to a payment/check lot.
Figure 108: Parallel Data Processing: Lots
The general steps in payment/check lot posting are as follows: Create and save the payment/check lot; can be created manually (check lots) or by a program (incoming bank transfers from an account statement) Display or change the payment/check lot (if necessary); items can be inserted or deleted Close the payment/check lot; insertion or deletion of items is no longer possible; however, corrections to items in the payment/check lot are permitted. It is no longer possible to add payments to the lot, or delete payments in the lot. Post the payment/check lot; posting can only take place if the lot has been “closed”. Upon posting, payments are transferred to the contract accounts and posting is made to the appropriate clearing account. Payment differences can be automatically posted to special profit and loss accounts. Further or post-processing is required if postings to a clarification account have been created or if postings were not possible (for example, incorrect/missing Customizing). The following possibilities exist: The triggering of a repayment (refund); posting to an interim account (if contract account cannot be determined); or posting as a payment to a contract account (where the account can be determined, but the open-item to be cleared cannot).
2006/Q2
© 2006 SAP AG. All rights reserved.
159
Unit 4: Incoming Payments
IUT240
Authorization object “F_KK_SOND” with activity “011” is needed in order to be able to reopen closed payment/check lots.
Figure 109: Interpretation Rules: Note to Payee
Define interpretation rules for note to payee: In this activity, you define the rules for the automatic analysis of note to payee texts for the automatic transfer of payment data to payment lots in Contract Accounts Receivable and Payable. Using the values determined, the system then determines the selection criteria for the assignment of payments to receivables. If you want to subject the values found in this way to an additional check, you can specify a check procedure for each structure sample. This check procedure has already been defined for the interpretation of the note to payee based on sample function module FKK_SAMPLE_SEL_TYPE_CHECK in the check procedure Customizing activity. In order to simplify the settings of the interpretation rules for the note to payee, the note to payee analysis can be tested in a Customizing activity. When payment data is transferred using the reports RFKKZE00 or RFKKKA00, you can still use the function module called up at event 0950 to make application-specific or customer-specific enhancements for payment or additional selections. For further information see the report documentation or the event description (FQEVENTS).
160
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Figure 110: Note to Payee: Configuration
SAP has enhanced the options for the evaluation and further processing of the note to payee specified for the transfer of FI bank statement data to the payment lot. The system accesses the interpretation rules that were defined in Customizing for contract accounts receivable and payable. In addition, it is possible to transfer incoming payments that have a particular pattern in the note to payee to a clarification account or to a short account. The program enters the short account or the status “to be clarified” directly into the payment lot. This ensures that these payments are not processed by the clearing control. For FI-CA customers this is interesting for holding transactions or for payments that do not have requests. In addition, you can reassign the selection values found. This means assigning a new value to a selection value or also assigning a new selection category.
2006/Q2
© 2006 SAP AG. All rights reserved.
161
Unit 4: Incoming Payments
IUT240
Figure 111: Interpretation of Note to Payee - Example
To simplify the Customizing settings for the interpretation rules for the note to payee, you can use transaction FP_NOTE_TEST to test the note to payee analyses.
Figure 112: Incoming Payment: Postings 1
Postings: 1. Debit entry from invoicing (shown without tax posting)
162
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Figure 113: Incoming Payment: Postings 2
Postings: 2. Incoming payment at the bank (the account statement is posted in the general ledger)
Figure 114: Incoming Payment: Postings 3
Postings: 3. Payment allocation by processing the payment lot
2006/Q2
© 2006 SAP AG. All rights reserved.
163
Unit 4: Incoming Payments
IUT240
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 recorded in the associated items in the payment lot. Payment usage can include the following: • • • • •
Clearing/partial clearing of open items Postings on account Expense/revenue (payment difference) Creation of new debit entries that are immediately cleared via payment allocation. (Charges or interest, for example) Down payments
Figure 115: Payment/Check Lot: Header Data
A manual payment/check lot consists of a header entry, one item per payment and, optionally, several sub-items per payment. In the header for the payment order, data is saved which is valid for the whole lot, along with data which is used as the default values for the items. The document type, search term, posting date, bank clearing account, company code for the bank posting and the reconciliation key for G/L accounting are valid for the entire lot. The currency and value date also have to be defined in the header. The most important default values for the items are the clearing reasons (such as incoming payments) and the selection categories (such as partner number, contract account number).
164
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Selection information is used to identify the open items which have to be cleared with the payment and/or to prepare the data for payment on account. Information is always given in the form of the selection category / selection value. Example: “C” stands for contract account; “B” stands for business partner, “P” for period key. Selection categories are defined in Customizing.
Figure 116: Payment/Check Lot: Processing Selection Categories
The selection categories allow you to decide which fields are to be used for selecting open items within a screen variant. Fields for selection categories can be defined in Customizing and may be taken from structure FKKOP (Business partner items in contract account document); fields from a customer defined structure may be used, but a function module must be coded for event 210. You can use the following fields to select open items in the transaction for manually posting a document: Business partner, contract account, contract, contract object, payment form reference number (reference number assigned to a payment form from an external system), document number, reference document number, payment form number, and net due date. Of all possible fields, the system displays only those that were specified as a selection category for your application in this activity.
2006/Q2
© 2006 SAP AG. All rights reserved.
165
Unit 4: Incoming Payments
IUT240
Figure 117: Payment/Check Lot: List Entry for Payment Screen
The selection details that can be created from the note to payee are defined in the item. If multiple allocations (such as multiple account numbers or contract numbers) are specified in the note to payee, you can enter further selections. They are then saved as sub items. In addition to the selection details, partial amounts can also be allocated (for example, with a total payment of 500 you can allocate 200 to account 4711, and 300 to account 4712). If you choose the Further Details pushbutton, or double click on a selected line, then the system displays the details screen for the selected item (not shown in the graphic). You can then enter additional data for the payment.
166
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Figure 118: Payment/Check Lot: Detailed Specifications
On the detail screen you can enter further specifications which are required for the allocation of payments or a subsequent clarification. Selections within a line are linked by AND logic, while the different lines of the selections are linked by OR logic. It is possible to transfer post payments to clearing accounts using short account assignment for which a company code and general ledger account are defined in Customizing. This type of posting is necessary if a payment was received by the wrong department. Standing order is used when a business partner has told his bank to send a certain amount form his account every month to a public sector organization. By selecting this indicator, the bank ID and note to payee information is passed with the item and the system can “learn” if an item is sent with the same incorrect data each time (used in Germany). The field refund method is used when a payment is received by mistake, from someone who is an unknown business partner. An entry screen is available, in which you can only enter selections. Moreover, a search function in the payment lot helps the user to search according to the content of a column in the item list. In the display for a payment lot item, you can now also reset the payment allocation or go to clarification processing. The clarification is only possible if the case has not yet been reserved for other users.
2006/Q2
© 2006 SAP AG. All rights reserved.
167
Unit 4: Incoming Payments
IUT240
Figure 119: Payment Advice Note
You can use payment advice notes to enter details on authorized 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: • • • •
168
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.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Figure 120: Electronic Bank Account Statement - Payment Lot
The bank transfers from an account statement are stored in a payment lot. Payments are assigned when the payment lot is processed. Interfaces: • •
•
Data Transfer from Electronic Account Statement to Payment/Returns Lot RFKKKA00 (transaction FPB7): The report selects payments, returns and payment orders that are imported into the bank data memory during the processing of electronic bank statements for the component Cash Management (TR-CM). If necessary,the FI-CA data can be transferred directly to a payment lot, payment order lot or returns lot. Alternatively, you can output selected data from the bank data memory in a file. You can then import the files created to payment lots, payment order lots or return lots in a later step. You can do this using the FI-CA transfer programs RFKKZE00 (payments, payment orders) and RFKKRL00 (returns). The system uses the business transaction and the amount +/- sign to decide the lot type a payment position is transferred to. Data transfer from MultiCash files to payment, payment order and returns lots RFKKKA00 (transaction FPB17): If you convert country-specific bank formats into MultiCash format, you can use this report to transfer data from the MultiCash statement file and line item file to payment and returns lots in FI-CA. However, in order to be able to process MultiCash files, you must make the system settings described in the ’Prerequisites’ section of the report documentation.
The files can also be generated using neutral interfaces. However, these must have the SAP format - which means they must not contain any country-specific formats from the electronic bank statements.
2006/Q2
© 2006 SAP AG. All rights reserved.
169
Unit 4: Incoming Payments
IUT240
Figure 121: Incoming Payments: Customizing
170
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
159
Lesson: Payment Lots and Check Lots
Exercise 5: Entering Payments in Payment Lots Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Use the payment lot to enter payments.
Business Example You have to enter the payments of your business partners on a daily basis. Your business partners use bank transfer to pay their open bills.
Task: Enter a payment lot. 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 ! 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? Write down the assigned document number: Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
171
Unit 4: Incoming Payments
IUT240
________________________________ Go to the account display and check the payment allocation. Which list category do you have to select to spot clearing entries? ________________________________
172
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Solution 5: Entering Payments in Payment Lots Task: Enter a payment lot. 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 ! 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? Write down the assigned document number: ________________________________ Go to the account display and check the payment allocation. Which list category do you have to select to spot clearing entries?
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
173
Unit 4: Incoming Payments
IUT240
________________________________ a)
Choose Utilities Industry → Contract Account Receivables and Payables → Payments → Payment Lot → Create. Reconciliation key:
ZS-## (## = Group number)
Selection categories:
G- Business partner K - Contract account B - Document
174
Status:
“Postings made”
List Type:
All items
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Lots and Check Lots
Lesson Summary You should now be able to: • Explain the object of the lot in contract accounts receivable and payable, and explain the procedure for the manual and automatic generation and processing of lots.
2006/Q2
© 2006 SAP AG. All rights reserved.
175
Unit 4: Incoming Payments
Lesson: 164
IUT240
Clarification Processing Lesson Duration: 40 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the processing options offered by clarification processing.
Business Example
Figure 122: Credit Clarification
Items requiring clarification arise where you post a payment/check lot but either some or all payments could not be posted (due to missing or incorrect Customizing, for example) to a contract account. When you post a payment/check lot, these items are posted to an interim account defined in customizing and included in a clarification worklist.
176
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
If you then process the clarification worklist, you can transfer these items from the interim account to a contract account. You can process the posting for a payment, a payment lot, or for all clarification cases (for more than one payment/check lot). You can clarify items from the payment or payment lot as follows: • •
•
Correct the payment items (the data used to select the items) and restart the posting of the selected items (clearing open items or payment on account). Perform the posting and clearing manually (with clearing of open items or payment on account). It is possible to clear some items during clarification. Partial clearings can be posted more than once. It is also possible to transfer posting items by using short account assignment defined in Customizing. In connection with this posting you can start a workflow (for example, you can send an E-mail to the department receiving the posting). Create a repayment request if you were unable to allocate the incoming payment amount to an individual item. The system then reposts the amount from the interim account to a repayment clearing account.
As of release ERP 2005, the new function “Correspondence for Clarification” is available for clarification processing. This allows you, for example, to make queries at the house bank or other addressees. When you use the function, the system proposes a business partner and an application form. The correspondence type is 0035.
Figure 123: Incoming payment: Processing
The clearing control is responsible for the automatic allocation of payments to open items.
2006/Q2
© 2006 SAP AG. All rights reserved.
177
Unit 4: Incoming Payments
IUT240
The clearing control logic can be used in various processes and transactions. The clearing control is used for manual or automatic account maintenance, as well as for processing payment lots.
Figure 124: Agent Allocation
The clarification worklist can be included in a worklist. SAP supplies the following two sample workflows for this. They can be used to create individual workflows: •
Standard workflow - WS21000078 A clarification case must be allocated to a processor before it can be sent to an agent in the workflow inbox. Agent assignment and agent restriction ensure that clarification cases are only assigned to an agent once. This means that if an agent cannot process and complete a clarification case, the case is sent automatically to another agent.
•
Ad hoc workflow - WS21000077 No agent allocations or restrictions have to be made for this workflow. If an agent cannot clarify a case, he or she determines the next agent and forwards the case to them. For this workflow, make the setting for a workflow with direct advance in the general workflow settings so that the next processor query appears immediately after processing.
178
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
Figure 125: Clarification List: Roles
When processing clarification worklists, you can carry out a check on the agent that processes individual clarification items using a role definition (like the SAP Workflow). This accounting agent then receives only those clarification items within their worklist for which they are responsible within the SAP organizational structure linked to the role. For clarification processing in the payment lot, roles for restrictions in the clarification worklist have been available for several releases. Standard role 02100008 (abbreviation FMCA_PLOT_SR) defines by which organizational units, positions, persons or users certain cases of the clarification worklists are processed. The standard role 02100009 (abbreviation FMCA_PLOT_UC) defines when clarification cases of the clarification worklist should count as urgent and which organizational units, positions, persons or users are responsible for their clarification. These roles were defined in the Customizing for clarification processing until now and had to be activated when needed. As of release ERP 2005, with clarification processing general roles are defined for payment clarification instead of these roles. However, the roles are still available. If you want to use these roles, replace the roles delivered with the roles 02100008 or 02100009 and then activate them.
2006/Q2
© 2006 SAP AG. All rights reserved.
179
Unit 4: Incoming Payments
IUT240
Figure 126: Selecting Clarification Cases from Payment Lot
The selection options of the payment clarification list enable you to limit the open clarification cases according to clarification accounts and account holders. You can also define mapping rules by using the new roles 2100008 (Limited Selection Clarification Worklist) and 2100009 (Limited to Acute Clarification Cases) and thereby assign each clarification case to at least one processor or a group of processors. You can transfer payments from payment or check lots that are in clarification, and that you cannot assign, after a predefined period using a program and thus remove them from the clarification worklist. You carry out the transfer posting by specifying a short account assignment to which a minimum retention period is assigned. The transfer posting program is RFKKUMBKL.
180
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
Figure 127: Clarification Proposal
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
181
Unit 4: Incoming Payments
IUT240
Figure 128: Repayment Request
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 “With refunds” indicator must be set in the payment run parameters.
182
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
Figure 129: Posting Process: Repayment
1. 2. 3. 4. 5.
2006/Q2
Incoming payment: Bank to bank clearing Allocation not possible: Clarification worklist - bank clearing to clarification account Clarification not possible: Repayment request generated - clarification account to repayment clearing account Repayment in payment run: Repayment clearing account to bank clearing account Electronic bank statement (outgoing payment): Bank clearing account to bank
© 2006 SAP AG. All rights reserved.
183
Unit 4: Incoming Payments
IUT240
Figure 130: Posting Process: Repayment
1. 2. 3. 4. 5.
184
Incoming payment: Bank to bank clearing Allocation not possible: Clarification worklist - bank clearing to clarification account Clarification not possible: Repayment request generated - clarification account to repayment clearing account Repayment in payment run: Repayment clearing account to bank clearing account Electronic bank statement (outgoing payment): Bank clearing account to bank
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
Figure 131: Credit Processing
You can use the following functions if the credit use has to be clarified for your business partner’s contract accounts: • •
Credit clarification Credit processing
The following types of credit can be processed with the credit clarification function: • •
Credit that was previously selected by the mass activity Generate Credit List and sent to clarification processing. Credit that was directly included in the clarification worklist as a result of Customizing settings.
The Process Credit function should only be used for manually processing individual credit that has not been entered by the credit list The activities Remain and Send Letter can be used for processing in credit clarification.
2006/Q2
© 2006 SAP AG. All rights reserved.
185
Unit 4: Incoming Payments
IUT240
Figure 132: Incoming Payments: Customizing
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.
Figure 133: Incoming Payments: Customizing
Selection criteria for clarifying credit. Field Immediately:
186
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
Ensures that a line item that fulfills the Customizing criteria is inserted directly in the credit list for clarifying credits. If you do not set this indicator, the line items are inserted in the clarification worklist when you call the credit list.
2006/Q2
© 2006 SAP AG. All rights reserved.
187
Unit 4: Incoming Payments
188
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
177
Lesson: Clarification Processing
Exercise 6: Clarification Processing Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Use the central clarification tools to allocate unclarified payments.
Business Example Not all incoming payments can be allocated to receivables at contract account level. Unclarified incoming payments are further processed within clarification processing.
Task: Central clarification processing. Unclarified incoming payments are processed in central clarification processing. The unclarified payments that you have to process have the following name: CA240-0## (ZIUT240-00##), where ## = group number.
2006/Q2
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?
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.
© 2006 SAP AG. All rights reserved.
189
Unit 4: Incoming Payments
IUT240
Solution 6: Clarification Processing Task: Central clarification processing. Unclarified incoming payments are processed in central clarification processing. The unclarified payments that you have to process have the following name: CA240-0## (ZIUT240-00##), where ## = group number. 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? Answer: Choose Utilities Industry → Contract Account Receivables and Payables → Payments → Clarification Activities → Payment Allocation. Enter CA240-0## (ZIUT240-00##) as the payment lot. Start the search with Program → Execute as Administrator or use the corresponding Administrator Mode icon. Select the required item and choose the Clarification button. The selection proposals contain one item that was formed from the payment data and another item that was formed 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.
Continued on next page
190
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Clarification Processing
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. Answer: Use the information from exercise 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 → Contract Accounts Receivable and Payable → Payments → Clarification Activities → Overview of Repayment Requests. Select company code U100 (U300) and start the evaluation with the status “Not yet paid”.
2006/Q2
© 2006 SAP AG. All rights reserved.
191
Unit 4: Incoming Payments
IUT240
Lesson Summary You should now be able to: • Explain the processing options offered by clarification processing.
192
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 181
Lesson: Cash Desk / Cash Journal
Cash Desk / Cash Journal Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Process payments at the cash desk and know the principles of the cash journal.
Business Example
Figure 134: Cash Journal Functionality
The 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
193
Unit 4: Incoming Payments
IUT240
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.
Figure 135: CD Structure
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.
194
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
Figure 136: Role Concept
Role concept (optional - can be activated/deactivated in Customizing) • • •
Branch office manager: Standard role 22000001 Cashier with special tasks: Standard role 22000003 Cashier: Standard role 22000005 can be allocated different activities. Users are allocated to roles using the transaction PFAC_INS or in the Customizing settings for responsibilities. Activities can also be individually allocated to the roles in Customizing, or configured according to the standard system. The overview displayed above represents a standard allocation.
Activity per role •
Branch office manager All activities for all cash desks in the branch office. For example, entering incoming and outgoing payments, posting deposits, transferring responsibilities, posting differences, posting withdrawals, the historical evaluation of all cash desks in his or her area of responsibility and opening/closing cash desks.
•
Cashier with special tasks All branch office manager activities except for closing cash desks in the branch office.
•
Cashier Entry of incoming and outgoing payments in his or her cash desk and posting deposits.
2006/Q2
© 2006 SAP AG. All rights reserved.
195
Unit 4: Incoming Payments
IUT240
Figure 137: Individual Enhancement of Cash Journal
Bar code reader For example, the customer data and the amount to be paid for each bar code are stored on the bill. A customer pays their bill and takes it to the cash desk. The cashier scans the bar code. The data for the business partner, contract account, amount and so on is already entered in the corresponding fields in the cash desk. There are 5 additional customer functions that can be activated and used for event 6120.
196
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
Figure 138: Cash desk
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 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 operation. Within the cash desk function, payments can be directly allocated to open items for a 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). If an overpayment is made in cash, the remaining amount is used to decide whether a posting on account is to be made or whether this amount is to be paid to the customer.
2006/Q2
© 2006 SAP AG. All rights reserved.
197
Unit 4: Incoming Payments
IUT240
Figure 139: Manual Cash Desk Payments with Business Partner
The cash desk allows a user to enter payments manually or automatically. Automatic assignment takes place the same way it does for payment/check lots (specifications for posting and selection criteria are also based on payment lots). Cash, card, and check payments are all permitted within the cash desk. If posting a payment/check lot – regardless of type – with the cash desk transaction, you can only create, post, and close the payment/check lots (within this transaction); a payment/check lot created here can only be displayed in the payment/check lot transaction. Default settings for the transaction illustrated above are set in Customizing in the payment processing section of the IMG. Expense and revenue accounts for posting of differences are also defined in Customizing (in the automatic G/L account determination section). As of release ERP 2005 you can process payments with several payment categories in the cash desk. This means that a customer can make a payment with a combination of cash, check payment(s), payment card(s), and postal orders.
198
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
Figure 140: Manual Cash Desk Payments Without Business Partner
As of release ERP 2005, the initial screen is divided into three parts: •
Header data The header area contains the static data of a payment, such as the payment date and the company code. You can display or hide this screen area using a pushbutton.
•
Simple selection /general ledger account posting The middle area contains two tab pages one for entering selection criteria for the payment and one for entering the data for general ledger account postings. In both cases the cash desk supports multiple entries.
•
Details of payment category In the area for payment categories, there is a separate tab page for each payment category supported: Cash, Check, Payment Card, Postal Order. With the exception of cash payments, multiple entries are possible. The system displays the payment categories and amounts entered in a totals table. You can create individual documents in the general ledger (FI-GL) and payments on account by setting the corresponding indicator. Payment lots are still supported.
2006/Q2
© 2006 SAP AG. All rights reserved.
199
Unit 4: Incoming Payments
IUT240
Figure 141: Cash Journal - Post Deposit
As of release ERP 2005, the dialog for posting deposits has been revised. The screen is divided into two areas. You can hide the header data. The fields required for posting a deposit cannot be hidden. The cash desk clearing account is hidden in the cash journal dialog. If the system can automatically determine a unique cash desk clearing account, no cash desk clearing account is displayed. If the system cannot determine a unique cash desk clearing account, you can specify one. You can reverse a deposit with the “reversal of special posting documents” function, provided this has not already been fully or partially withdrawn.
Figure 142: Cash Journal - Post Withdrawals
As of release ERP 2005, the dialog for posting withdrawals has been revised. As when posting deposits, the interface has been divided into two areas. You can hide the header data. The area that is permanently visible shows the balance for each payment category. You can select and activate the balances for withdrawals.
200
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
You can also post a partial withdrawal. Regardless of the settings for the cash journal, the balances are now displayed for each payment card and are provided for withdrawal. If you select and activate a cash balance and enter a partial withdrawal amount, you can only post the remaining amount as a new deposit. This does not change the cash desk balance. However, the performance is greatly improved when determining the current cash desk balance. It is advisable to post the remaining amount of a cash withdrawal as a new deposit at regular intervals or, for example, before or after closing at the end of the day. The system posts a withdrawal document and, if necessary, a deposit for each item activated. The cash desk clearing account is hidden in the cash journal dialog. If the system can automatically determine a unique cash desk clearing account, no cash desk clearing account is displayed. If the system cannot determine a unique cash desk clearing account, you can specify one. You can reverse a withdrawal with the “reversal of special posting documents” function.
Figure 143: Cash Journal - Post Differences
As of release ERP 2005, the dialog for posting differences has been revised. As when posting deposits, the interface has been divided into two areas. You can also hide the header data. The area that is permanently visible shows the balance for each payment category, provided you can post difference for all payment categories. If a difference occurs in one or more balances, you can select and activate these and enter the respective actual balance. For each activated item, the system posts one document for differences. The cash desk clearing account is hidden in the cash journal dialog. If the system can automatically determine a unique cash desk clearing account, no cash desk clearing account is displayed. If the system cannot determine a unique cash desk clearing account, you can specify one. You can reverse a difference with the “reversal of special posting documents” function, provided this has not already been fully or partially withdrawn.
2006/Q2
© 2006 SAP AG. All rights reserved.
201
Unit 4: Incoming Payments
IUT240
Figure 144: Payment on Installment Plan
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.
Figure 145: Cash Journal: Day End Closing
202
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
You can execute day-end closing. 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, you can print the day-end closing. Irrespective of whether you carry out day-end closing for a cash desk, you can still open and close it. 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 have to reopen it. You can use the overview (menu: Payments → Cash Desk) to display the closing carried out in the cash journal across all cash desks and all branches. In the cash journal you can only display cash desk closing for the current cash desk and branch. The transaction enables you to display the cash desk closing dependent on the following selection criteria: • • • • •
Cash desk Branch Date of cash desk closing Closing carried out by Status of closing
Figure 146: Cash Desk / Cash Journal: Customizing
2006/Q2
© 2006 SAP AG. All rights reserved.
203
Unit 4: Incoming Payments
IUT240
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 Desk / Cash Journal: •
•
Prevent the cash desk from being called up directly by flagging the Cash Journ. Act. indicator in the activity: Maintain Specifications for Cash Journal. Make the basic settings and master data in the activities: Maintain Specifications for Cash Journal and Define Master Data for Cash Journal.
When defining Default Values for Posting Cash Desk Deposits and Withdrawals, make sure that you maintain different bank clearing accounts for deposits and withdrawals. However, you can enter the same G/L account for deposits and withdrawals. You can use user roles to control the authorizations for postings and evaluations in the cash desk. In order to do this, you must activate the role concept by setting the Use Roles indicator in the Maintain Specifications for Cash Journal activity and by allocating roles to the individual users (cashiers).
204
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
193
Lesson: Cash Desk / Cash Journal
Exercise 7: Cash Desk / Cash Journal Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Use the cash desk to enter payments.
Business Example You have to enter the payments of your business partners on a daily basis. Your business partner pays their open bills at the cash desk.
Task: Cash Desk 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: Selection category:
Business partner
Field value / selection cat.: ## = Group number
PICA0710## (PI0701C0##)
Amount:
180.00 (in both the Cash Payment screen and the summary)
Select the Incoming cash payment radio button. 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
205
Unit 4: Incoming Payments
IUT240
Solution 7: Cash Desk / Cash Journal Task: Cash Desk 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: Selection category:
Business partner
Field value / selection cat.: ## = Group number
PICA0710## (PI0701C0##)
Amount:
180.00 (in both the Cash Payment screen and the summary)
Select the Incoming cash payment radio button. Choose the “Post item in dialog” variant and display the payment proposal from the system. Post the payment and write down the document number.
Continued on next page
206
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Desk / Cash Journal
Generate a receipt. Switch to the print preview to display the receipt. a)
Choose Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal. Allocate yourself to the cash desk with the branch office WDF (BOS) and cash desk ##, then 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.: ## = Group number
PICA0710## (PI0701C0##)
Amount:
180,00
Choose “Post Item Online”, check the clearing proposal and post the payment. Confirm the receipt printout using the Print Immediately on Defined Printer (CTRL + P) button. You can display your receipt using System → Own Spool Requests.
2006/Q2
© 2006 SAP AG. All rights reserved.
207
Unit 4: Incoming Payments
IUT240
Lesson Summary You should now be able to: • Process payments at the cash desk and know the principles of the cash journal.
208
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Name the different payment types in contract accounts receivable and payable. • Explain the object of the lot in contract accounts receivable and payable, and explain the procedure for the manual and automatic generation and processing of lots. • Explain the processing options offered by clarification processing. • Process payments at the cash desk and know the principles of the cash journal.
2006/Q2
© 2006 SAP AG. All rights reserved.
209
Unit Summary
210
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 5 Payment Run
199
Unit Overview
Unit Objectives After completing this unit, you will be able to: • • • • • •
Explain the prerequisites for the payment program and the posting logic. Carry out postings and repayments using the payment run. Make payments with credit cards. Identify the options for creating and processing outgoing checks. Explain the Internet self-services for displays, and the options for paying bills in the Biller Direct component. Define the concept of revenue distribution to final recipients in Contract Accounts Receivable and Payable.
Unit Contents Lesson: Prerequisites of the Payment Settlement .........................212 Lesson: Payment Program ....................................................220 Exercise 8: Payment Run Processing ...................................231 Lesson: Payment Cards .......................................................236 Exercise 9: Payment by Credit Card.....................................241 Lesson: Check Management..................................................248 Lesson: FSCM Biller Direct....................................................253 Lesson: Revenue Distribution .................................................258
2006/Q2
© 2006 SAP AG. All rights reserved.
211
Unit 5: Payment Run
Lesson: 200
IUT240
Prerequisites of the Payment Settlement Lesson Duration: 15 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the prerequisites for the payment program and the posting logic.
Business Example
Figure 147: Initiation of Payment Transactions
There are several types of payment methods in FI-CA that are initiated internally. These payment methods are mainly used in connection with the payment program (see the next lesson for further details).
212
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Prerequisites of the Payment Settlement
The difference between a direct debit mandate and a debit memo (automatic debit) is that in a direct debit mandate the customer issues the approval to debit his/her account, and then has six weeks in which he/she can reject the posting. In the case of a debit memo, the customer informs the bank that it can debit the account. The bank must then confirm that the customer has given consent and is no longer able to reverse or reject the transaction once it has been started (this is relevant for German law). Hint: If an incoming payment method is valid (not locked), then it is the company’s responsibility to collect the money. For this reason dunnings do not include open items of this kind.
Figure 148: Payment Lot: Usage
2006/Q2
© 2006 SAP AG. All rights reserved.
213
Unit 5: Payment Run
IUT240
Figure 149: Payment Method Configuration
Through the use of the payment method it is possible to ensure that items with a payment method and items without a payment method are processed. The payment method of the document is not compared with the payment method of the contract account. By entering a payment method in an item it is possible to ensure that any minimum/maximum amount limits valid for this item are ignored (so that, for example, after the cancellation of a contract, minimal amounts that would not usually lead to a transfer or a collection can nevertheless still be paid automatically). Payment method classification specifies whether a check is to be created, if the payment is from a post office bank account, or if the payment method is to be used for incoming payments.
214
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Prerequisites of the Payment Settlement
Figure 150: Payment Program Control Data - Master Data
The responsible company code has the same function as the paying company code in Financial Accounting (posting the bank line responsible for house banks, sender of payment orders, etc.). Other entries relating to payment are determined separately for outgoing and incoming payments within a contract account master record. In both cases (incoming and outgoing): • •
A business partner bank (or that of an alternative business partner) can be specified for one or both cases Payment methods specified can be overridden by entries in the document.
A contract account can be blocked for outgoing or incoming payments. Furthermore, bank collection can be prevented after failed debit memos until a processing block date is reached. If a contract account is specified for offsetting, the contract account items are all paid to a business partner together. Payment methods, banks and blocks are determined via this offsetting contract account.
2006/Q2
© 2006 SAP AG. All rights reserved.
215
Unit 5: Payment Run
IUT240
Figure 151: Payment Control Data: Line Item
A due date is determined by three date entries: the cash discount date, the specified due date for net payment, and the deferral date. Grouping ensures that items with the same grouping term will be paid together (the grouping criteria must correspond). For example, it is used if you have sent your customer a bill with several items, but these items are to be collected with one amount. Using the indicator “can only be cleared” when posting an item ensures that items cannot be disbursed (or collected). Rather, the amount to be collected or disbursed can only be cleared with other debit entries. In event 0652, you can override the automatic selection of partner banks created by the payment program. In the standard system, the partner bank is selected as a result of the bank details defined either in the contract account or the contract (differentiated by incoming payment and outgoing payment). You can override this by explicitly specifying bank details in the line item. However, it is not possible, for example, to select a partner bank dependent on the currency of the items paid if these bank details are not entered in the items to be paid. Using event 0652, you can set a different bank details ID dependent on the items to be paid, or prevent payment.
216
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Prerequisites of the Payment Settlement
Figure 152: Payment: Posting 1
[1] Debit position of a receivable [2] Payment in FI-CA by the payment run.
Figure 153: Payment: Posting 2
[3] Incoming payments in General Ledger Accounting (posting the account statement).
2006/Q2
© 2006 SAP AG. All rights reserved.
217
Unit 5: Payment Run
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
218
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Prerequisites of the Payment Settlement
Lesson Summary You should now be able to: • Explain the prerequisites for the payment program and the posting logic.
2006/Q2
© 2006 SAP AG. All rights reserved.
219
Unit 5: Payment Run
Lesson: 206
IUT240
Payment Program Lesson Duration: 40 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Carry out postings and repayments using the payment run.
Business Example
Figure 154: Payment Program Processing
The process flow of the payment program is as follows: open items are selected; open items are grouped for payment; items requiring special processing are determined; payment methods and bank details are determined; the value date and account determination takes place; payments are posted and payment media created.
220
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
If desired, you can execute a test run of the payment program prior to the actual payment run. The test run creates a payment list but it does not create payment documents. The results of the test/payment run are stored in payment tables (DPAYH, DPAYP). These tables include payments as well as payment exceptions. Payment data and payment exceptions can be viewed in the payment list, but they cannot be changed. From the payment data payment media are created. Payment media can be created in electronic form or in hard copy. The payment run program uses the technique of parallel processing. You can define per item indicator for exceptions (in payment program) whether an item should be placed in the clarification list. Data that controls the payment run exists in: Master data, document, Customizing, current payment run parameters.
Figure 155: Payment Program: Program Flow
Parallel processing distributes the load across several systems in order to achieve improved performance. By choosing suitable sizes of the selected blocks, more rapid access is possible and less memory is required to process the data. Parallel processing is achieved by apportioning the dataset to be processed. The business partner or the combination of business partner and contract account are suitable interval objects for parallel processing.
2006/Q2
© 2006 SAP AG. All rights reserved.
221
Unit 5: Payment Run
IUT240
The dispatcher for the payment program calls up the payment program every time entries are made to the technical settings. Every process obtains a free interval which is not yet in operation. The work list defined by this interval is processed in blocks. When the interval has been processed, the process receives the next interval and continues until all intervals have been confirmed as completed. After an interval has been reserved for processing, the information in the worklist is transferred to the mass selection module so that the items for a business partner (or a contract account) can be read efficiently.
Figure 156: Events in the Payment Program
Through the use of specified events, it is possible to influence the flow of the payment program. The exact specification of the program interfaces and detailed documentation and notes on implementation can be found in the system. For more information see the documentation for the associated example function modules FKK_SAMPLE_06xx (i.e. the function modules specific to the payment program are in the 600’s).
222
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
The following events are available within the payment program: • • • • • • • • •
0600 Payment: Enter grouping criteria for items 0601 Payment: Deactivate items after grouping 0610 Block items or initiate partial payments 0615 Choose line-items to be cleared 0620 Create clearing document lines (when clearing) 0630 Additional data for payment (PAYH) 0640 Additional data on paid items (PAYP) 0650 Select house bank and account 0690 Delete payment data
Figure 157: Run-Time Parameters in the Payment Program
Payment runs can be protected by freely definable authorization groups. An accounting clerk may only process a payment run (change parameters, start a payment run, etc.) if he is authorized for this activity and he is in the appropriate authorization group. Selection criteria according to business partner, contract account and dynamic selections are available for use in the test-run phase. Selection according to company code is mandatory. The defined payment method is country-specific. For this reason it is only possible to select company codes within a country that has the same currency in each payment run.
2006/Q2
© 2006 SAP AG. All rights reserved.
223
Unit 5: Payment Run
IUT240
The posting date of the payment run is applied as the baseline date for determining the due date, unless: • •
•
If a deferral date has been entered in an item, it is used in every case to determine the due date. If the cash discount date is prior to the posting date, then the cash discount due date is used when determining the due date and the item will be paid minus cash discount where applicable. If the cash discount period has expired then the due date for net payment is used. Hint: The due date for an item that is determined in this manner must fall within the due date interval entered in the “general selections” section of the payment run parameters for the item to be paid.
You can restrict the payment run to one payment card type. You can then run separate payment runs for each payment card type, event though the payment method from the “card payment” category is always the same. Grouping of Open Items • • • • • • • • •
Business Partner Alternative payer Payer’s bank details Responsible company code payment lock Contract account by which payment transactions are made / offset Payment method Currency key Grouping term for open item Free grouping of application area
A business partner’s items are grouped together into payable groups. Items can only be grouped together if a business partner’s items are not selected by contract account. The responsible company code and the account being offset are determined via the assigned contract account in the document. The application area can enter data in its own grouping field in the designated Event 0600. This data could, for example, include reference details from the contract. This event can also be used to block items while the payment program is running.
224
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
Figure 158: Determination of Payment Method and Banks
Several payment methods can be specified for outgoing payments in a contract account’s or contracts object’s master data. In this case the checks outlined in steps within the graphic above are carried out for each payment method until a valid payment method is found. If payment optimization is not required, the house bank with the highest priority is always selected (see bank selection in parameter maintenance).
Figure 159: Run Parameters - Selection of Banks
The payment program has been realized as a mass activity. Once open items have been grouped the system determines the appropriate payment method and selects a bank from the bank parameters entered in the payment run. Currently it is only possible to prioritize banks for bank selection optimization. It is not yet possible to enter available amounts for each of the respective bank accounts.
2006/Q2
© 2006 SAP AG. All rights reserved.
225
Unit 5: Payment Run
IUT240
You can maintain bank selection for all company codes simultaneously. For cross-company code postings, the company code belonging to the contract account must also be the responsible company code for the company codes in the line items. If other company codes are billed using the contract account, incoming payments on receivables in these company codes are always posted to a company code settlement account in the responsible company code first. This procedure is the same for outgoing payments.
Figure 160: Example: Item Grouping (1 of 2)
Figure 161: Example: Item Grouping (2 of 2)
226
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
Figure 162: Payment List
Extended checks for outgoing payment creation: In addition to processing blocks on an account or contract object and payment blocks on an account or document, you also have the option in FI-CA of excluding items from payment by the payment program. In Customizing you can define the necessary payment block reasons to exclude certain items from automatic payment. This type of payment block always refers to both incoming and outgoing payments. Items that cannot be paid automatically on the basis of their item and contract account categories are excluded from further processing by the payment program and appear in the exception list of the payment program. Payment and exception list: Using the list-viewer functionality, the payment data list structure can be tailored to an individual user. This means that the display layout of the payment list report can be structured and defined by an individual user.
Figure 163: Additional Features of Payment Program
2006/Q2
© 2006 SAP AG. All rights reserved.
227
Unit 5: Payment Run
IUT240
The activity log gives information on the executed activities (changing parameters, scheduling, deleting data) and by whom and when the activities were executed. The additional log clarifies the working method of the payment program. In particular, information is provided on how the items have been grouped and why it was not possible to make a payment. The user can define what is to be logged. The copy template contains pre-defined parameters and may be used to create a payment run, but the template itself cannot be executed as a payment run. A copy template will not be deleted if a payment run that was created by using that copy template is itself deleted. Payment runs can be deleted.
Figure 164: Creation of Payment Run
You must initiate a process for each payment medium, and must take into account the country-specific requirements such as the currency and the note to payee. You can change the structure of the note to payee in Customizing. The use of symbols such as “&TABLE-FIELD&” is supported, as used in SAPscript. In addition, it is possible to edit or structure the note to payee (free text field) in the technical programming of the application area. If you use the payment media formats EDIFACT and S.W.I.F.T. (MT 100,101, 103, 104, 200, and 202), (customer development), you can define correspondence banks. This means that you can specify a bank chain with up to three intermediary banks (correspondence banks) in Customizing for the transfer from one bank to another. You can define general and recipient-specific bank chains. You then specify recipient-specific bank chains in the transactions for creating and changing
228
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
business partner data (FPP1, FPP2) on the tab page Payment Transactions, in the Bank Chains area. The function module FI_PAYMENT_BANK_CHAIN_SET determines the bank chains during the payment media creation and places them in the corresponding structures.
Figure 165: Note to Payee Content Hint
You can set that payment media are to be created in the language of the business partner. If this flag is not set, then the system will look into the content table depicted above and look for language key ‘“ ”‘ (blank) and use the parameters associated with this table entry. Therefore it is important to place an entry in the content table for language key ‘“ ”‘ for each note to payee category. To determine whether or not this flag has been set, go transaction “SE38”, enter program ID “SAPFKPY3”, execute, then search for the “Text in recipient’s language” flag. In the user-defined specifications, you can specify the number of items to be prepared only once per payment. This avoids the contents of PAYH and PAYHX being output per item, even though these are the same for all items. In the definition of the line content (FQP5 → Note to Payee: Content), the sequence (line number) decides whether the content is prepared per payment or per item. If, for example, you have specified 2 information items per payment and 1 information line per item, you have to provide a total of 3 lines with content. The first two apply per payment, which means that here only the fields from the structures PAYH and PAYHX are useful. The third line is then repeated for each item. The fields from the structure PAYP are useful here.
2006/Q2
© 2006 SAP AG. All rights reserved.
229
Unit 5: Payment Run
IUT240
Figure 166: Direct Debit/Repayments: Customizing
Customizing of payments includes: • • •
• •
•
230
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, payment 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).
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
217
Lesson: Payment Program
Exercise 8: Payment Run Processing Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Make payments • Create payment media.
Business Example The receivables that are due from business partners who participate in the direct debit procedure are paid.
Task: You are responsible for making the payments for business partner PICA0510## (PI0501C0##). 1.
Start the payment run for business partner PICA0510## (PI0501C0##) in the “Start Immediately in Background” mode. 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. What is the result of the payment run? 2.
What changes do you have to make to enable the payment run to pay your business partner’s items? _____________________________
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
231
Unit 5: Payment Run
IUT240
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 “P20##” identifier. Determine the document number of the payment: _____________________________
232
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
Solution 8: Payment Run Processing Task: You are responsible for making the payments for business partner PICA0510## (PI0501C0##). 1.
Start the payment run for business partner PICA0510## (PI0501C0##) in the “Start Immediately in Background” mode. 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. What is the result of the payment run? a)
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 11.16.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##. Save your parameters and use the Schedule Program Run (F8) button to start the payment program. After the payment run is complete, choose Logs → Application Log to go to the payment run log. You can analyze the payment run notifications in the info messages. The result is “Contract account locked”. A payment lock is entered in your business partner’s contract account. Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
233
Unit 5: Payment Run
2.
IUT240
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 “P20##” identifier. Determine the document number of the payment: _____________________________ a)
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 8-1.
234
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Program
Lesson Summary You should now be able to: • Carry out postings and repayments using the payment run.
2006/Q2
© 2006 SAP AG. All rights reserved.
235
Unit 5: Payment Run
Lesson: 222
IUT240
Payment Cards Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Make payments with credit cards.
Business Example
Figure 167: Direct Debits Using Payment Cards
When processing open items to be paid by payment cards, card data instead of bank details with direct debiting in business partner master record is used. The card number as well as locks, and validity intervals are checked. The card ID is saved in the contract account and possibly in the contract object. A separate card ID may be stored for outgoing payments. The payment method uses the “payment card” processing type.
236
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Cards
Figure 168: Payment Cards
When processing open items to be paid by payment cards, data from the card with the debit memo, which exist in the business partner master record, is used rather than the bank data. • •
Card number checked Locks, validity periods
If the customer uses a payment card to pay for goods and services, then open receivables have to be reported to the payment card institution. The payment program clears the customer’s open items and creates new open items on the payment company’s clearing account (reporting account). The open items to be reported to the payment card company (those open items of customers cleared by the payment program) are then determined. When credit card payments are processed in the payment run, no entries have to be made in the bank selection. You must define a card account in posting area 1120. The amounts reported to a credit card institute are posted here, as are the receivables that are sent to the credit card institute when the notification is created (transfer posting). The final step is to carry out billing. Billing can be repeated.
2006/Q2
© 2006 SAP AG. All rights reserved.
237
Unit 5: Payment Run
IUT240
Figure 169: Payment Cards: Issuing Bank / Card Institution
Figure 170: Payment Cards: Returns
238
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Cards
Figure 171: Formats
Figure 172: Payment Cards: Customizing
You can make the basic settings for the payment card configuration in the IMG menu under: Cross Application Components -> Payment Cards -> Basic Settings.
2006/Q2
© 2006 SAP AG. All rights reserved.
239
Unit 5: Payment Run
240
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
227
Lesson: Payment Cards
Exercise 9: Payment by Credit Card Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Execute and bill payments by credit card.
Business Example The receivables due are paid using the specified credit card for the business partner.
Task: 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. 2.
First, post a miscellaneous receivable to the amount of USD 100.00. Use the following information: Document date:
01.04.2006
Posting date:
01.04.2006
Currency:
EUR (USD)
Company code:
U100 (U300)
Tax:
Calculate automatically → x
Enter the additional data with the “Business Partner Item List” function.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
241
Unit 5: Payment Run
3.
IUT240
Business partner:
PICA0510## (PI0501C0##)
Contract account:
PICA0510## (PI0501C0##)
Transaction:
6000 / 0020
Amount:
100,00
Now make the payment. Use the information from exercise 8-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##).
4.
Display all the items that have not been billed to card issuer “American Express” yet.
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 9-3 for your selection. Enter the following file name: pcard## ## = Group number
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: _______________________________
7.
242
Once you know the identifier of your billing run, you can navigate to the display of the billing data.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Cards
Solution 9: Payment by Credit Card Task: 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. a)
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 use the appropriate button to set these card details as the standard details should there be more than one set of card details. Save the change made to your business partner. In the detail screen now displayed, enter the credit card details as the Credit Card payment card category, and enter a validity date. Your changes are saved when you confirm the details screen. Choose: Utilities Industry → Business Master Data → Contract Account → Change. Change the incoming payment method to “K” in the payments/taxes and enter the card ID (F4 help).
2.
First, post a miscellaneous receivable to the amount of USD 100.00. Use the following information:
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
243
Unit 5: Payment Run
IUT240
Document date:
01.04.2006
Posting date:
01.04.2006
Currency:
EUR (USD)
Company code:
U100 (U300)
Tax:
Calculate automatically → x
Enter the additional data with the “Business Partner Item List” function. Business partner:
PICA0510## (PI0501C0##)
Contract account:
PICA0510## (PI0501C0##)
Transaction:
6000 / 0020
Amount:
100,00
a) 3.
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Document → Post and enter the required values.
Now make the payment. Use the information from exercise 8-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##). a)
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 8-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.
Continued on next page
244
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Cards
4.
Display all the items that have not been billed to card issuer “American Express” yet. a)
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 9-3 in the selection criteria for the payment run. Choose ’Not Yet Settled’ as the selection criterion for the billing run. To start the evaluation, choose Program → Execute or the corresponding icon.
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 9-3 for your selection. Enter the following file name: pcard## ## = Group number a)
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 9-3 in the Selection for payment run fields. To start the evaluation, choose Program → Execute or the corresponding icon.
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: _______________________________ a)
Choose Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance and select the standard list type (all items) variant. 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 Data screen block.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
245
Unit 5: Payment Run
7.
IUT240
Once you know the identifier of your billing run, you can navigate to the display of the billing data. a)
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 9-6.
246
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Payment Cards
Lesson Summary You should now be able to: • Make payments with credit cards.
2006/Q2
© 2006 SAP AG. All rights reserved.
247
Unit 5: Payment Run
Lesson: 234
IUT240
Check Management Lesson Duration: 15 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Identify the options for creating and processing outgoing checks.
Business Example
Figure 173: Introduction: Process Overview
A check can have the following status: • • • •
248
Open Cashed Invalid Locked (new as of release 4.72)
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Check Management
As of release 4.72 you can lock a check and report the lock to the bank, without having to reverse the related payment or issue a replacement check. The check is locked in check management and reported to the bank using transaction FPCHX. After a specific deadline (usually 24 hours) the bank guarantees that this check can no longer be cashed. You reverse the related payment document after this deadline by regularly scheduling transaction FPCHS so that the cleared items are open again. By running the payment run again you can create a new check if required. If checks are cashed within the deadline, you can define, in the settings for the voiding reason, whether the checks are to be deemed “cashed” automatically or whether clarification cases are to be created. This procedure is interesting for US customers and is known by the name “Stop Payment”. It is an alternative to the previous way of issuing a replacement check. Invalid checks that have not yet left the company premises should be voided and reissued as previously. A check lock is not necessary in these cases.
Figure 174: Maintaining Outgoing Check Processing
The bank clearing account used in the payment document must be defined in Customizing to enable the system to determine bank data, and the valid for online printing indicator must be set. When you set the flag, the applicable clearing account must be used in online check printing. Application form FI_CA_DME_CHECK_SAMPLE serves as a template for a check form with an accompanying letter. The check is printed. The checks for the document are managed in the check repository together with the check numbers used. If you try to print a check again for the same payment document, a replacement check is created in the check repository with a new check number.
2006/Q2
© 2006 SAP AG. All rights reserved.
249
Unit 5: Payment Run
IUT240
The program makes the following available: • • • •
•
A chronological log of any special event (when a check is invalidated, for example). You can display the log for the check or for the payment document. The status of checks can be changed. This allows you to record in check management which checks have been cashed. You can invalidate checks separately, but you must define a reason for it. If you use pre-numbered checks, you can use a check issue file to record which checks have actually been issued. This allows you to keep tabs on existing pre-numbered checks that have not yet been issued. If you need to state the name of more than one recipient on a check (two-party checks), you can enter additional recipient information separately and save this.
Figure 175: Direct Debit/Repayments: Customizing
250
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Check Management
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
251
Unit 5: Payment Run
IUT240
Lesson Summary You should now be able to: • Identify the options for creating and processing outgoing checks.
252
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 238
Lesson: FSCM Biller Direct
FSCM Biller Direct Lesson Duration: 10 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the Internet self-services for displays, and the options for paying bills in the Biller Direct component.
Business Example
Figure 176: FI-CA & Biller Direct: The Internet Customer Account
s
2006/Q2
© 2006 SAP AG. All rights reserved.
253
Unit 5: Payment Run
IUT240
Figure 177: SAP’s Concept of the Customer Account
Figure 178: One Customer Account - Different Receivable Types
254
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: FSCM Biller Direct
Figure 179: SAP FSCM: Biller Direct
2006/Q2
© 2006 SAP AG. All rights reserved.
255
Unit 5: Payment Run
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
256
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: FSCM Biller Direct
Lesson Summary You should now be able to: • Explain the Internet self-services for displays, and the options for paying bills in the Biller Direct component.
2006/Q2
© 2006 SAP AG. All rights reserved.
257
Unit 5: Payment Run
Lesson: 242
IUT240
Revenue Distribution Lesson Duration: 15 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Define the concept of revenue distribution to final recipients in Contract Accounts Receivable and Payable.
Business Example Revenue Distribution: Definition •
Definition of “revenue distribution”: Distribution of revenues (i.e. sales, motor fuels and trade taxes, exchange of information function, the use of value-added services, or the deregulated telephone market) to final recipients based on established distribution rules.
•
Definition of “final recipient”: Entity (natural or legal person) that is the receiver of the distributed revenue.
In addition to managing your own receivables, you can use the FI-CA component Revenue Distribution to manage receivables for third parties. Incoming payments for third parties that you receive for example, as part of the exchange of information function, the use of value-added services, or the deregulated telephone market are automatically paid over to the final recipient. The payments to be distributed to the final recipient are created in the form of totals postings. The payment program uses these to create a transfer. However, in this transfer for the final recipient, it is not visible which business partners have paid which open items. For the final recipient to see which paid items make up the payment amount transferred, in data medium creation you can create a payment advice note, in which you explain which payments make up the totals posting to the final recipient. SAP delivers the following example forms of form class FI_CA_PAYMENT : FI_CA_PAYMENT_REV_DIST_SF (SmartForm) and FI_CA_PAYMENT_REV_DIST_PDF (PDF).
258
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Revenue Distribution
There has been no manual or automatic clearing in the account of the final recipient, which means that you can use the payment program for payment. To prevent clearing, when you post the distribution documents, set the clearing restriction Z. This has the effect that only the payment program can perform clearing. To set the clearing restriction, make the corresponding setting in the Implementation Guide for Contract Accounts Receivable and Payable, under Business Transactions → Distribution of Revenues → Define Specifications for Distribution of Revenues. In theory, in a distribution run, it may be the case that the revenues to be distributed and the adjustment postings that, for example, arise from a clearing reset or reversal of payments, balance to zero. If this is the case, no documents have yet been created on the final recipient’s account. In release 6.00, the posting logic was changed for this special case. In the future, two distribution documents with opposite +/- signs are posted. This enables you to create a payment advice note for the final recipient.
Figure 180: Revenue Distribution: Overview
FP60M The distribution revenue mass activity 0094 reads cleared items and writes detailed information in table DFKKRDI. FP60P With this transaction the system creates postings for final recipient by reading the detailed information. FP60R or FP60R2 or reports RFKKRD01 and RFKKRD02 Reporting Detailed Information
2006/Q2
© 2006 SAP AG. All rights reserved.
259
Unit 5: Payment Run
IUT240
The final recipient can: •
Be automatically derived –
•
in Customizing (posting area 1380): The derivation of the final recipient is based on company code /main transaction and subtransaction/account determination ID/division/period key – Event 0045 Be entered manually in the document
Depending on the original main and sub transaction for the distribution posting, you can derive the same or an alternative main and sub transaction. Separate output process for mass activity 0094 • •
Takes into account all payments that have been distributed Updates DFKKRDI – –
•
Contains data on the output run and payments made Explains which incoming payments have been forwarded with which outgoing posting Generates summary postings for the final recipient.
In event 5415 you can exclude individual documents or line items from the revenue distribution. For example, you can allow a period of four weeks before you forward a payment received to the final recipient. Distribution Information in Posting lines •
Distribution status in posting lines:
– – –
“1” to distribute “2” incoming payment distributed “3” Clearing reset/reversal distributed
The payments are identified using the clearing reason. Both the current and the previous distribution statuses are saved. Each distribution sets the last distribution status as the current status. The distribution program only takes into account items with the current status “1”. To prevent an inconsistent status in the distribution history after the reversal of a distribution document, the reversal of revenue distribution documents has been suppressed.
260
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Revenue Distribution
In revenue distribution, several revenues are usually transferred to the final recipient as a total. From Release 6.00, for individual cases, you can forward a document to the final recipient separately (without summarizing it with other documents). You can use this posting of individual documents, for example, in the Public Sector for administrative purposes.
Figure 181: Evaluation of Revenue Distribution (FP60P)
You can use transaction FP60R2 to evaluate the revenue distribution for a final recipient account or for all final recipient accounts of a business partner.
2006/Q2
© 2006 SAP AG. All rights reserved.
261
Unit 5: Payment Run
IUT240
In the report, for each final recipient account and currency, totals items are displayed for the following evaluation categories: •
Posted for distribution to final recipient These totals contain all posted documents that are forwarded to the final recipient for an incoming payment. In these documents the final recipient account is filled with the final recipient selected.
•
Distributed for final recipient In this evaluation category, for the final recipients selected, the total of all entries written in the distribution table DFKKRDI by the Distribute Revenues transaction is displayed. The total is displayed in the Total field. The other totals fields have no meaning for this evaluation.
•
Posted to final recipient These totals contain all documents posted to the contract account of the final recipient. These can be the distribution documents posted to the contract account of the final recipient by the Post Distribution transaction (SAP menu: Periodic Processing -> For Contract Accounts -> Revenue Distribution). Documents that were posted to the account manually are also included in the totals. The different totals (for example, posted and reversed totals) are calculated as for the evaluation Posted for Distribution to Final Recipient.
Figure 182: Revenue Distribution: Customizing
262
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Revenue Distribution
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
263
Unit 5: Payment Run
IUT240
Lesson Summary You should now be able to: • Define the concept of revenue distribution to final recipients in Contract Accounts Receivable and Payable.
264
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Explain the prerequisites for the payment program and the posting logic. • Carry out postings and repayments using the payment run. • Make payments with credit cards. • Identify the options for creating and processing outgoing checks. • Explain the Internet self-services for displays, and the options for paying bills in the Biller Direct component. • Define the concept of revenue distribution to final recipients in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
265
Unit Summary
266
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 6 Returns Processing
249
Unit Overview
Unit Objectives After completing this unit, you will be able to: • •
Configure return reasons, activities, and changes. Process returns in Contract Accounts Receivable and Payable.
Unit Contents Lesson: Configuration of Returns.............................................268 Lesson: Processing of Returns ...............................................281 Exercise 10: Configuration and Processing of Returns ...............287
2006/Q2
© 2006 SAP AG. All rights reserved.
267
Unit 6: Returns Processing
Lesson: 250
IUT240
Configuration of Returns Lesson Duration: 45 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Configure return reasons, activities, and changes.
Business Example Your organization has been notified by its bank that it has been unable to collect a payment from the business partner’s bank (insufficient funds, expired account, invalid account, and so on).
Figure 183: Returns and Returns Lot: Definition
The returns component enables you to process bank returns which may occur as part of a debit memo or collection procedure, or with check deposits or outgoing payments. Returns are combined in return lots. The returns lots can be created either manually (using return slips), or automatically by copying return data from the electronic bank account statement file.
268
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Returns can occur in connection with the following payment methods: • • •
Checks Debit memos Credit card collections
Returns typically result from expired or closed accounts, insufficient funds in an account, false accounts, stop-payment on a check, and so on. After a return has been included in a return lot, an additional document is posted. This document varies from a reversal posting in that it is posted to a settlement account for returns. Data can be entered in the lot either automatically or manually.
Figure 184: Returns Processing: Structure
First the system determines the receivables or payables that were cleared by incoming or outgoing payments. This payment clearing can then be (normal case) canceled so that the original receivables or payables are open again. The system then generates a return document containing the offsetting items for the items in the payment document. Bank charges are posted in the general ledger. You can charge any bank fees to your business partners. You may choose to make your business partner liable for other charges as well. The return charges for the business partner can be posted either statistically or to the general ledger. Possible follow-up activities are: Changes in the item, setting a deferral date, setting a dunning block and/or a payment block, setting an outgoing payment block and/or changing the incoming payment method (from direct debiting to payment on demand, for example).
2006/Q2
© 2006 SAP AG. All rights reserved.
269
Unit 6: Returns Processing
IUT240
Other activities such as workflow connection, creation of information for the clerk, or the creation of correspondence for the business partner are also possible. The industry solutions offer these activities, but customers can adapt them to suit own needs. The system records all relevant data in a returns history. This history is referred to when determining creditworthiness. The returns history is used, for example, to determine the number of returns for a business partner.
Figure 185: Posting: With Bank Charges 1
1. 2.
270
Debit entry from invoicing (tax not shown) Payment settlement by bank collection
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Figure 186: Posting: With Bank Charges 2
1. 2. 3.
2006/Q2
Debit entry from invoicing (tax not shown) Payment settlement by bank collection Incoming payment (account statement)
© 2006 SAP AG. All rights reserved.
271
Unit 6: Returns Processing
IUT240
Figure 187: Posting: With Bank Charges 3
1. 2. 3. 4.
Debit entry from invoicing (tax not shown) Payment settlement by bank collection Incoming payment (account statement) Incoming payment (account statement) Returns are processed automatically in the following steps: First the system determines the receivables and payables that are cleared through incoming and outgoing payments. This payment clearing is then canceled so that the original receivables or payables are open again. The system then generates a return document containing the offsetting items for the items in the payment document. Additional postings, which are required for taxes or charges, are then generated and the follow-up activities are triggered.
There are different types of returns postings: • • • •
Net returns (returns document does not contain charges) Gross returns (returns document does contain charges) Charges including taxes (gross charges) Charges without taxes (net charges)
The allocation takes place using the source document number (note to payee).
272
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Figure 188: Posting: With Bank Charges 4
1. 2. 3. 4. 5.
2006/Q2
Debit entry from invoicing (tax not shown) Payment settlement by bank collection Incoming payment (account statement) Incoming payment (account statement) Reverse clearing (return in subledger account)
© 2006 SAP AG. All rights reserved.
273
Unit 6: Returns Processing
IUT240
Figure 189: Posting: With Bank Charges 5
1. 2. 3. 4. 5. 6.
274
Debit entry from invoicing (tax not shown) Payment settlement by bank collection Incoming payment (account statement) Incoming payment (account statement) Reverse clearing (return in subledger account) Post expense from bank charges
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Figure 190: Posting: With Bank Charges 6
1. 2. 3. 4. 5. 6. 7. 8.
Debit entry from invoicing (tax not shown) Payment settlement by bank collection Incoming payment (account statement) Incoming payment (account statement) Reverse clearing (return in subledger account) Post expense from bank charges Pass on bank charges to business partner 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
275
Unit 6: Returns Processing
IUT240
Figure 191: Returns Reasons
Using activity keys in Customizing, you can define multiple activities to be performed in the event of a return. In Customizing you must assign the returns reasons given by banks to your own organization-specific returns reasons. This allows you to treat different returns reasons as defined by individual banks in a uniform way. Hint: You can only assign a returns reason to a house bank when you define the reason for the first time. Afterwards only changes are possible but not a reassignment to a house bank. The activity key is made up of the Company Code, No. of Returns, Creditworthiness, and Tolerance Group fields. The returns reason triggers a number of activities. The return reason is used to automatically determine the general ledger accounts that will be posted to for returns charges (and its offsetting revenue account). It is also used for the bank clearing. Two charges revenue accounts and expense accounts (each) are possible for the clearing of charges. History days define the maximum number of days in the past in which a posting may lie so as to be considered in the return history evaluation. If you set the value 0 then all postings will be considered when viewing the returns history. The number of returns is determined from the returns history and always refers to a business partner and a contract account. (= F1 help)
276
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Figure 192: Returns Reasons and Activities: Structure
Number of returns: Hint: When defining activities to take place based on the number of returns, the system takes the first return that takes place on an account to be return number 0, NOT return number 1. Account or item dunning block: In case of a return, the dunning block reason entered here is stored in the contract account master record (or in the item if using an item dunning block) of the business partner in question. The system determines the new due date for the receivable by taking the document date of the return and adding the number of deferral days (if an entry is made in the “deferral days” field). NOTE: Dunning cannot be performed on an item or account with an incoming payment method of direct debit or bank collection. Using “further activities” allows you to use additional events (function modules) to be used. Event 295 (Returns: Process contract account) is the function module that is used in conjunction with these settings. For example, correspondence could be triggered.
2006/Q2
© 2006 SAP AG. All rights reserved.
277
Unit 6: Returns Processing
IUT240
Figure 193: Returns Activity: Charging
You can configure charges handling to have all returns fees that are charged by the bank(s) passed on to the business partner (“pass charges on”). If desired, you can charge the customer an extra fee for the processing of returns (“calculate graduated charge” flag). Charges can be posted statistically or non-statistically (with update to the general ledger). Default main and sub transactions for these receivables (for both debit and credit postings) are assigned in Customizing (posting area 0111). The amount limit (total of the return items) must be reached for the currency in question in order for lot charges to be calculated and debited to a customer’s account. This makes it possible to scale charges. The maximum difference between the return amount of the house bank and the original payment amount that is tolerated for automatic posting of charges. As long as the difference amount falls short of the maximum difference, it will always be interpreted by the system as a charge and posted. If you do not specify an amount, no difference will be tolerated and posting will only take place automatically when the return amount is the same as the original payment amount. Technical note: The standard function module “FKK_SAMPLE_0270” is for determining differences in charges.
278
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of Returns
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
279
Unit 6: Returns Processing
IUT240
Lesson Summary You should now be able to: • Configure return reasons, activities, and changes.
280
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 261
Lesson: Processing of Returns
Processing of Returns Lesson Duration: 20 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Process returns in Contract Accounts Receivable and Payable.
Business Example
Figure 194: Returns Lot: Processing Steps
2006/Q2
© 2006 SAP AG. All rights reserved.
281
Unit 6: Returns Processing
IUT240
Processing steps: 1. 2. 3.
4. 5.
Create: A lot can be created interactively or by a program (for example a returns lot for account statement returns). 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. 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. Post: Once the lot has been closed, returns posting is carried out with the processing step Posting. 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, 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.
Figure 195: Manual Return Lot Creation (1 of 2)
282
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Returns
If the “Amount includes charges” indicator is set, all return amounts belonging to this return lot are evaluated by the system as gross amounts. The net amount is then calculated as follows: Net amount = Return amount - charge amount. If the indicator is not set, the return amounts are evaluated as net amounts (net amount = return amount). If you set the indicator “Charge includes tax”, then all charges relating to this returns lot, such as bank charges or charges passed on, are evaluated by the system as gross charges. The net charge is then calculated as follows: Net charge = Charge amount - tax amount; otherwise Net charge = Charge amount. The selection categories available here are the same ones that are available when posting a payment lot. You can also specify your own selection criteria and code the function module that is behind it to your own specifications. It is possible to define a field status definition for the fields in the header of a return lot. Delivered selection categories include document and check number. You can define your own selection categories using event 0255. Previously returns could not be posted to payments that contained down payments or postings on account where these items had been cleared again. Using the indicator “enhanced return processing” you can now reverse the clearing in these situations.
Figure 196: Manual Return Lot Creation (2 of 2)
Within configuration, defaults can be set for document type, clearing reason, company code, screen variant, and selection category that will be used when posting a return lot. If you do not enter a bank clearing account number in the returns lot item, the system will automatically use the bank clearing account defined in Customizing for the given return type (for example, bank return, check return, and payment card return) when the return lot is posted. If you do not know the actual bank clearing account number, but you do know the house bank and account ID, you can enter both and the system will determine the appropriate clearing account.
2006/Q2
© 2006 SAP AG. All rights reserved.
283
Unit 6: Returns Processing
IUT240
If you set the “Line item” indicator, then a separate line item is created in the general ledger transfer document for this line item. This item is not summarized with other line items (as is the case when creating summary records), even if there is identical account assignment. This is most often used in conjunction with a return lot for an outgoing checks account.
Figure 197: Return Processing: Technical Flow
The conversion or allocation of (external to ERP) organization-specific return reasons to each house-bank return reason is defined in Customizing for table TFK045D.
284
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Returns
General returns process: Create return header; create return items; close the return; write history or write error log (if necessary). Hint: Technical notes: The following events occur when processing returns (table TFKFBM): •
• •
• •
• •
260: Determination of charges to be debited on a contract account. Passes on bank return charges & additional graduated charges, if applicable. 270: Determination of the difference in return amount and original payment amount. Maximum difference allowed is checked. 280/1: Determination of the contract account for the first/second bank charge, if charges were debited before the actual charges are determined. 285/6: Enhanced account determination after charges were determined (optional) 290: Releases complete return document after it is generated but prior to it being checked and updated (prior to call-up of posting module) 291: Submitting of individual document line items after set up 295: Changing of contract accounts after posting and implementation of further activities (workflow, correspondence)
Figure 198: Returns: Customizing
Classification of returns according to bank and check returns.
2006/Q2
© 2006 SAP AG. All rights reserved.
285
Unit 6: Returns Processing
IUT240
Definition and assignment of own return reasons to the house bank(s) reasons. Customize returns and processing activities: • • • • • • • •
286
Charges/debiting of charges Deferral days Define locks and forms Define information for accounting clerk Amount limits, creditworthiness. Clearing accounts, revenue and expense accounts, receivables account and clarification account. Configuration of entry lines for the dialog processing returns lots Define account assignments for new items with returns: When posting returns, you can define a mode that generates new open items. You can define the main and subtransactions for these new items.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
267
Lesson: Processing of Returns
Exercise 10: Configuration and Processing of Returns Exercise Duration: 30 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Configure and process returns in FI-CA.
Business Example 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.
Task 1: Configuring the returns reason 1.
Configure return reason G## (## = group number) using the following parameters and activities: Returns category:
Bank return
History days:
30
Creditworthiness number:
5
The returns activities must be as follows:The incoming payment method of the contract account must be blocked for 7 days for the combination of company code U100 (U300), 0 number of returns, 0 creditworthiness and the tolerance group 001 of the contract account. Charges must be passed on, statistically booked, 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 EUR (USD), and 7.50 EUR (USD) for amounts above 50.00 EUR (USD). If the difference between the original payment amount and returns amount is 20.00 EUR (USD) or less, the system interprets it as a bank charge.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
287
Unit 6: Returns Processing
IUT240
Task 2: Enter returns. Enter a returns posting for the payment made by business partner PICA0510## (PI0501C0##). 1.
Use the following information: Returns lot:
RL06010##
Search term:
Returns Group 0##
Currency:
EUR (USD)
Company code:
U100 (U300)
Amounts contain bank charges:
X
Calculate charges:
X
Enter the returns item: B Selection value:
Document number from the Payment unit.
Returns reason:
G##
Once you have confirmed with “Enter”, the original payment amount that the system has determined is displayed in the ‘Returns Amount’ field. Increase this amount by 10.00. Once you have chosen “Enter” again, the system interprets the difference as a bank charge and displays the amount in the “Bank Charge 1” field. Save your entries Close and post the returns lot. 2.
288
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
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Returns
Solution 10: Configuration and Processing of Returns Task 1: Configuring the returns reason 1.
Configure return reason G## (## = group number) using the following parameters and activities: Returns category:
Bank return
History days:
30
Creditworthiness number:
5
The returns activities must be as follows:The incoming payment method of the contract account must be blocked for 7 days for the combination of company code U100 (U300), 0 number of returns, 0 creditworthiness and the tolerance group 001 of the contract account. Charges must be passed on, statistically booked, 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 EUR (USD), and 7.50 EUR (USD) for amounts above 50.00 EUR (USD). If the difference between the original payment amount and returns amount is 20.00 EUR (USD) or less, the system interprets it as a bank charge. a)
In the IMG, choose: Financial Accounting → Contract Accounts Receivable and Payable → Business Transactions → Returns → Configure Returns Reasons. Choose New Entries and enter G## (## = group number) as identification with Returns Reason ID 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 Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
289
Unit 6: Returns Processing
IUT240
Tolerance group
0001
Incoming payment lock contract account
A
Lock duration days
7
Pass charges on
X
Post charges statistically
X
Calculate graduated charges
X
Create correspondence:
X
Double click on the “Returns Charges” level in the document structure. Confirm the information message that appears and select “New Entries”. Enter the following data: Currency
EUR (USD)
Amount limit
20
Graduated charge
5
Select F8 and enter the following data: Currency
EUR (USD)
Amount limit
50
Graduated charge
7,5
Select the “Automatic Charges Determination” level from the dialog structure and choose “New Entries”. Enter the following data: Currency
EUR (USD)
Max. difference
20
Save your entries
Task 2: Enter returns. Enter a returns posting for the payment made by business partner PICA0510## (PI0501C0##). 1.
Use the following information: Continued on next page
290
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Returns
Returns lot:
RL06010##
Search term:
Returns Group 0##
Currency:
EUR (USD)
Company code:
U100 (U300)
Amounts contain bank charges:
X
Calculate charges:
X
Enter the returns item: B Selection value:
Document number from the Payment unit.
Returns reason:
G##
Once you have confirmed with “Enter”, the original payment amount that the system has determined is displayed in the ‘Returns Amount’ field. Increase this amount by 10.00. Once you have chosen “Enter” again, the system interprets the difference as a bank charge and displays the amount in the “Bank Charge 1” field. Save your entries Close and post the returns lot. a)
Choose Utilities Industry → Contract Account Receivables and Payables → Payments → Returns → Returns Lot. Choose Create lot. 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##.
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 a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance. A new document has been posted with the transaction text “Return Receivable”. Select the “Contract Account” button (ctrl + F6) and check the payment lock in the “Payments/Taxes” tab page.
2006/Q2
© 2006 SAP AG. All rights reserved.
291
Unit 6: Returns Processing
IUT240
Lesson Summary You should now be able to: • Process returns in Contract Accounts Receivable and Payable.
292
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Configure return reasons, activities, and changes. • Process returns in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
293
Unit Summary
294
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 7 Clearing Control
275
Unit 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
Unit Objectives After completing this unit, you will be able to: • • •
Explain the terms and principles of the clearing control. Name the tools for defining a clearing strategy in Contract Accounts Receivable and Payable. Handle special cases in clearing control.
Unit Contents Lesson: Terminology and Definitions.........................................296 Lesson: Configuration of the Clearing Strategy.............................303 Lesson: Special Cases: ........................................................319 Exercise 11: Configuration of Clearing Variants ........................327
2006/Q2
© 2006 SAP AG. All rights reserved.
295
Unit 7: Clearing Control
Lesson: 276
IUT240
Terminology and Definitions Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the terms and principles of the clearing control.
Business Example
Figure 199: Clearing Control: Orientation
296
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Terminology and Definitions
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.
Figure 200: Clearing Control: Overview
Clearing variants are determined depending on the clearing type of the underlying business processes and, optionally, on the clearing category of the contract account in which the clearing is to take place. The clearing type represents the business transaction in which items are allocated or grouped for clearing postings. • •
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).
Clearing types are hard-coded in the system. Although possible, do not add entries not found on TFK001 except a customer-specific form of the FI-CA event R400 (IS-U Invoicing). Clearing types are structured according to their areas of use (for example, incoming payment, account maintenance).
2006/Q2
© 2006 SAP AG. All rights reserved.
297
Unit 7: Clearing Control
IUT240
Clearing categories are defined in the contract account. As a result, you can use the clearing category to allocate individual clearing rules to different customer groups, such as household, commercial, and industrial customers. If no clearing category is assigned, the clearing variant defined for the clearing type will be taken.
Figure 201: Clearing Control: Clearing Types
Clearing type 06 (Payment Run) is used in the configuration of the enhanced payment grouping. Normally the payment run does not consider the clearing control.
298
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Terminology and Definitions
Figure 202: Example 1 - Payment
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.
Figure 203: Example 2 - Account Maintenance
2006/Q2
© 2006 SAP AG. All rights reserved.
299
Unit 7: Clearing Control
IUT240
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 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.
300
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Terminology and Definitions
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
301
Unit 7: Clearing Control
IUT240
Lesson Summary You should now be able to: • Explain the terms and principles of the clearing control.
302
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 281
Lesson: Configuration of the Clearing Strategy
Configuration of the Clearing Strategy Lesson Duration: 50 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Name the tools for defining a clearing strategy in Contract Accounts Receivable and Payable.
Business Example
Figure 204: Clearing Control: Integration
In order to be able to react to differing clearing scenarios, the standard solution for the clearing control should not be supported by rigidly programmed scenarios.
2006/Q2
© 2006 SAP AG. All rights reserved.
303
Unit 7: Clearing Control
IUT240
Clearing control is used: •
•
•
When creating a clearing proposal during payment assignment or account maintenance. (Function module FKK_CLEARING_PROPOSAL_GEN_0110, processed in event 0110). When splitting a clearing amount arising from an installment plan/collective bill back into the original items of this installment plan/collective bill (function module FKK_CLEARING_PROPOSAL_GEN_0120, processed in event 0120). When distributing the clearing amount of a summarization group to the original receivables that can be displayed as groups for the manual clearing process (function module FKK_CLEARING_PROPOSAL_GEN_0130, processed with event 0130).
Clearing proposals are determined automatically when payment lots are posted or during automatic clearing. They can also be requested manually (for example, for manual account maintenance, for the cash desk, or for the clarification of payments).
Figure 205: Clearing Variant
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.
304
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Items that are completely cleared in a clearing step are not included in subsequent steps.
Figure 206: Clearing Control: Characteristics
Characteristics usually describe a specific feature of an item (for example, item is a payment on account or item is due) or the occurrence of a certain event (for example, a document number is specified on payment). Characteristics are used in: •
• •
•
2006/Q2
The grouping of open items. Open items that have identical values for the grouping characteristics in a clearing step are considered as one unit in this clearing step (for example, all items that belong to the same company code). The specification (Filter) of which items should be processed in the clearing step (for example, only those due, or only those in company code 0001). The definition (switch) of the condition of whether a clearing step should be executed at all (for example, only carry out step if a document number is specified on payment) The sorting of open items. Through sorting, both the order of processing the groups is defined and the order of clearing within the group.
© 2006 SAP AG. All rights reserved.
305
Unit 7: Clearing Control
IUT240
Figure 207: Clearing Control: Clearing Step
Up to 5 grouping characteristics can be defined in a 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. Examples: In order to control two attributes of a characteristic in a group (company code 0001 = company code 0002), 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 0001). 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 a group. 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 group that contains the item with the oldest due date is sorted at the front of the sequence. If no partial clearing proposal has been made, you may wish to stop the clearing program (enter value “1” in field for end of assignment).
306
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Figure 208: Clearing Control: Grouping Characteristics
Grouping characteristics can be attributes in table “FKKOP”, or can be specifically derived in a function module (use customer name space).
Figure 209: Clearing Control: Sorting Characteristics
2006/Q2
© 2006 SAP AG. All rights reserved.
307
Unit 7: Clearing Control
IUT240
Sorting is generally used when a company is not sure how a sold-to-party will group his payments, and the company has its own self-defined priority for items. For example, the company may wish to clear any open items on a certain revenue type before any additional charges and interest.
Figure 210: Clearing Control: Sorting Derived by Characteristics
308
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Figure 211: Clearing Control: Grouping by Derived Characteristics
Figure 212: Clearing Control: Grouping String
2006/Q2
© 2006 SAP AG. All rights reserved.
309
Unit 7: Clearing Control
IUT240
Figure 213: Clearing Control: Alternative Grouping
You can use the rules to influence the grouping string, and thus the grouping. The following grouping rules are available: • •
•
•
“” - group by the value of the characteristic “1” - group definition (use if you want to combine several groups to a single group). Any values for the characteristic that cannot be grouped will be its own group based upon the characteristic value. For example, you are grouping by product group and there are three possible values. Product groups 1 and 2 are grouped using an alternative grouping, and form one group. Product group 3 forms a second grouping. ‘“2” - group definition like “1”, except that any non-specified values for the characteristic all contain the value SPACE and are therefore grouped into one additional group. Used to exclude certain groups. “3” - group definition where any values for the characteristic not specified in the grouping rule will not be considered for payment.
To enter an alternative grouping (not available with rule ‘ ‘) click the Alternative Grouping button that appears immediately to the right of the grouping rule. You may have to hit Enter first.
310
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Figure 214: Clearing Control: Alternative Grouping
Figure 215: Clearing Control: Sorting Within Groups
It may make sense in certain cases to use both grouping and sorting at the same time. For example, it could be possible that two or more different groups could have the same amount due, but one group should have priority over the others. In this case you sort the groups and not the items.
2006/Q2
© 2006 SAP AG. All rights reserved.
311
Unit 7: Clearing Control
IUT240
Figure 216: Clearing Control: Sorting String
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 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. The following four values are delivered: • •
• •
“” - sort by the value of the characteristic (for example, due date). “1” - sort by value ranking first and then by the value of the characteristic. Not all values must be specified explicitly. For example, there are 4 items with values 1, 2, 3, 4. In ranking, value 4 is given a priority of 1st, and no ranking is given to the other values. Sorted results will be items 1 and 4 (same ranking), 2, then 3. “2” - unranked items have top priority (1st), others then handled in ranked order (1, 2, 3, 4). “3” - unranked items have lowest priority (come after all ranked items) (4, 1, 2, 3).
To enter an alternative sorting (not available with rule “‘ ‘”) click the Alternative Sorting button that appears immediately to the right of the grouping rule. You may have to hit Enter first.
312
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Figure 217: Clearing Control: Group Rules
Group rules are allocated in the grouping string. Amount rules ‘ ‘, 0, 1, 2, 3, and 4 are used most often: • • • • • •
•
“‘ ‘” - no amount restriction (only use when not using a ‘grouping’). “0” - clear only when amounts are equal. “1” - no partial clearing allowed, but overpayment permitted “2” - no overpayment allowed, but partial clearing permitted “3” - maximum amount difference according to tolerance group. Post tolerance. “4” - maximum amount difference according to amount check group. Partial clearing takes place (difference is not written off when using a tolerance group). If the difference between the payment amount and open item amount is greater than this amount, then the payment will be posted on account. Amounts specified here are not “added” to tolerance group amounts. See online documentation for information on the other rules.
With clearing rule “1”, the system makes proportional payments. For example, a payment of 90 is made to two open items with 100 and 50: The system makes a partial payment of (100 / 150) * 90. This means that a payment of 60 is made to the item with 100, and a payment of 30 is made to the item with 50.
2006/Q2
© 2006 SAP AG. All rights reserved.
313
Unit 7: Clearing Control
IUT240
Figure 218: Amount Check Groups
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 must make sure 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.
314
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Figure 219: Defaults and Selection Restrictions
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. 2. 3. 4.
Clearing category, main transaction, subtransaction Clearing category, main transaction, not specified Clearing category, not specified, not specified 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. The selection criteria can be used to exclude items with specific main and sub transactions or to define how many days into the future the system should look for open items for possible clearing (Grace Days column). By marking the box NC this will exclude items with the associated main and subtransactions. You can also exclude items from clearing in the corresponding clearing step. Statistical items can be written off automatically in several ways when posting a payment to an account with statistical postings on it. Control data payment on account allows rules to be set for when posting ‘on account’. For example, it could be set that any amount over X amount will be posted directly to the clarification (interim) account and not posted on account (payment lot status would be not posted).
2006/Q2
© 2006 SAP AG. All rights reserved.
315
Unit 7: Clearing Control
IUT240
Program enhancements allow for the use of two function modules, one for the selection of open-items, and the other for how statistical items should be written off. 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
Figure 220: Clearing Control: Customizing
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.
316
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration of the Clearing Strategy
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
317
Unit 7: Clearing Control
IUT240
Lesson Summary You should now be able to: • Name the tools for defining a clearing strategy in Contract Accounts Receivable and Payable.
318
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 296
Lesson: Special Cases:
Special Cases: Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Handle special cases in clearing control.
Business Example
Figure 221: Clearing Control: Account Maintenance (1)
Example: Since a characteristic has not been entered, the open items from documents 4710, 4711 and 4712 form a group. Within the group, the items are sorted according their due dates. The bill credit (30 USD) is calculated step-by-step in the following way: • •
2006/Q2
The bill receivable for 10 USD from 09/15 is cleared first of all. The remaining credit of 20 USD is cleared against the budget billing request from 12/5. The budget billing request remains open at 40.- USD.
© 2006 SAP AG. All rights reserved.
319
Unit 7: Clearing Control
IUT240
Figure 222: Clearing Control: Account Maintenance (2)
Example: Since a characteristic has not been entered, the open items from documents 4709, 4710, 4711 and 4712 form a group. Within the group, the items are sorted according their due dates. The clearing algorithm produces the following processing steps: • • • •
320
The payment on account of 20.- USD is cleared against the bill receivable from 09/15 This is completely cleared using the bill credit from 11/15. The remaining credit of 25 USD can be used for partially clearing the bill receivable from November 11/15 in the gas division. The budget billing repayment request (10 USD) is cleared against the remaining bill receivable in the gas division dated 11/15. The remaining receivable from the bill 4711 is still 65 USD.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Special Cases:
Figure 223: Clearing Control: Account Maintenance (3)
Example: Clearing step 1 produces the following processing steps: Document number and due date are specified as characteristics with the result that the following groups are created: • • • • •
Group1: Group3: Group2: Group4: Group5:
Open item document 4709 Open item document 4711 Open item document 4710 Open item document 4712 of due date 12/05 Open item document 4712 of due date 01/05.
The following clearing steps take place: • • •
In group 1, group 2, and group 5 no clearing takes place. In group 3, the credit of 30 USD from the division electricity is cleared against the gas receivable of 100 USD so that a receivable of 70 USD is left. In group 4, the budget billing repayment requests from 12/05 are balanced so that a budget billing amount of 140 USD is due on 12/05.
The second clearing step leads to the following results: • •
2006/Q2
No further characteristics have been specified. As a result, all items still open are grouped together. The payment in account of 20 USD can still be used for clearing and is used for clearing the bill that has been open for the longest amount of time. There is still a receivable of 5 USD.
© 2006 SAP AG. All rights reserved.
321
Unit 7: Clearing Control
IUT240
Caution: Grouping by due date is necessary because the due dates of a budget billing plan or installment plan have the same number. The clearing consideration should usually take place at the level of the individual due dates.
Figure 224: Clearing Control: Account Maintenance (4)
Figure 225: Clearing Control: Incoming Payment
322
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Special Cases:
The additional grouping according to due date is required because a document may have items with different due dates (for example, installment plan or budget billing plan). For example, the customer wants to pay the invoice 4709. They can, for example, pay the full amount of 25 USD or the remaining amount of 5 USD after taking account of the credit of 20 USD (doc. 4710).
Figure 226: Clearing Control: Special Features
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. – – –
–
2006/Q2
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.
© 2006 SAP AG. All rights reserved.
323
Unit 7: Clearing Control
IUT240
Control data payment on account allows rules to be set for when posting ‘on account’. For example, it could be set that any posting over X amount will be posted directly for clarification and not posted on account (payment lot status would be “not posted”).
Figure 227: Clearing Control: Writing Off Statistical Items
Write-off statistical items allows for one of three options when posting a payment to an account with statistical postings on it: “‘ ‘” - always write off “1” - write off statistical items if no ‘real’ open receivables exist: Open items 100 and 15 (15 is statistical). When payment of 100 is received, the 15 will be written off. “2” - write off up to the next ’real’ open receivable: Statistical items with a due date before the due date of the next open ’real’ receivable are written off.
324
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Special Cases:
Figure 228: Clearing Control: Clearing Strategies (1)
Figure 229: Clearing Control: Clearing Strategies (2)
2006/Q2
© 2006 SAP AG. All rights reserved.
325
Unit 7: Clearing Control
IUT240
Figure 230: Clearing Control: Clearing Strategies (3)
Figure 231: Clearing Control: How Can I Test It?
326
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
305
Lesson: Special Cases:
Exercise 11: Configuration of Clearing Variants Exercise Duration: 40 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Configure and use a clearing variant.
Business Example 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.
Task: Configure a clearing variant G## (## = group number), Clearing Group ## that covers the clearing strategy described above.
2006/Q2
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.
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).
3.
Assign clearing category G## to contract account PICA0930## (PI0903C0##).
4.
Use the cash desk (transaction FPCJ) to test whether your clearing variant determines the correct clearing proposal for contract account PICA0930## (PI0903C0##).
© 2006 SAP AG. All rights reserved.
327
Unit 7: Clearing Control
IUT240
Solution 11: Configuration of Clearing Variants Task: Configure a clearing variant G## (## = group number), Clearing Group ## that covers the clearing strategy described above. 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. a)
In the IMG, choose: 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. Choose 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.)
0010
Due Date
Continued on next page
328
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Special Cases:
Choose “Enter”. You can now use the “Alternative Sorting” button (to the right of the rank number) to make the following entries for the two characteristics: 1. Company code Characteristic value: U100 (U300)
Ranking: 1
Characteristic value: U110 (U400)
Ranking: 2
Save your sorting step. 2. Main transaction Characteristic value: 6000
Ranking: 1
Characteristic value: 0100
Ranking: 2
Save each of your sorting steps and the clearing variant. 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). a)
Choose: Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Open Item Management → Clearing Control → Clearing Variants → 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##.
3.
Assign clearing category G## to contract account PICA0930## (PI0903C0##). a)
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 ##. Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
329
Unit 7: Clearing Control
4.
IUT240
Use the cash desk (transaction FPCJ) to test whether your clearing variant determines the correct clearing proposal for contract account PICA0930## (PI0903C0##). a)
In the application menu, choose Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal. Choose the “To Cash Desk” button and enter contract account PICA0930## (PI0903C0##) and an amount. Select the Post Online button. The items allocated using your clearing variant are activated. Do not save until your clearing variant is correct.
330
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Special Cases:
Lesson Summary You should now be able to: • Handle special cases in clearing control.
2006/Q2
© 2006 SAP AG. All rights reserved.
331
Unit Summary
IUT240
Unit Summary You should now be able to: • Explain the terms and principles of the clearing control. • Name the tools for defining a clearing strategy in Contract Accounts Receivable and Payable. • Handle special cases in clearing control.
332
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 8 Dunning and Collections
311
Unit Overview
Unit Objectives After completing this unit, you will be able to: • • •
Define the dunning terms used in Contract Accounts Receivable and Payable. Configure appropriate dunning procedures and know how to execute a dunning run in Contract Accounts Receivable and Payable. Submit receivables to external collection agencies, and know how to update further information on released items.
Unit Contents Lesson: Dunning - Terminology ..............................................334 Lesson: Configuration and Execution of the Dunning Run ................339 Exercise 12: Dunning ......................................................355 Lesson: Submission to External Collection..................................364 Exercise 13: Submitting Receivables to External Collection Agencies .....................................................................373
2006/Q2
© 2006 SAP AG. All rights reserved.
333
Unit 8: Dunning and Collections
Lesson: 312
IUT240
Dunning - Terminology Lesson Duration: 10 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Define the dunning terms used in Contract Accounts Receivable and Payable.
Business Example
Figure 232: Dunning Procedure: Definition
An additional receivables is a receivable, which is caused by another receivable, e.g. dunning charges or interest. In many cases these additional receivables shall not be dunned and/or calculated interest without at least on main receivable. An item not marked as additional receivable in its transaction attributes (a main receivable) kann be subjetc to interest calculation or trigger dunning if no blocks are set.
334
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Dunning - Terminology
Figure 233: Dunning Procedure: Function
A dunning procedure is made up of individual dunning levels. You make a number of specifications for each dunning level, including the minimum amount of an overdue item and the number of days in arrears to be reached in order for the item to reach the next dunning level. One of the most frequently used dunning activities is the creation of a dunning notice. Other examples of dunning activities are posting interest and charges, processing a note for an agent, or starting a work-flow.
Figure 234: Dunning - Example
The dunning level indicates how often this item has already been included in a dunning run. The highest dunning level reached by any of the items recorded determines the dunning activities.
2006/Q2
© 2006 SAP AG. All rights reserved.
335
Unit 8: Dunning and Collections
IUT240
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).
336
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Dunning - Terminology
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
337
Unit 8: Dunning and Collections
IUT240
Lesson Summary You should now be able to: • Define the dunning terms used in Contract Accounts Receivable and Payable.
338
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 316
Lesson: Configuration and Execution of the Dunning Run
Configuration and Execution of the Dunning Run Lesson Duration: 45 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Configure appropriate dunning procedures and know how to execute a dunning run in Contract Accounts Receivable and Payable.
Business Example
Figure 235: Dunning Procedure: Configuration
The “dunning procedure” is the driver for dunning. You can define different dunning levels for each dunning procedure. These “dunning levels” determine the dunning frequency, the calculation method by which the dunning charges are determined, and how interest is calculated and posted. For each dunning level you can also define currency-specific minimum amounts and “dunning activities”.
2006/Q2
© 2006 SAP AG. All rights reserved.
339
Unit 8: Dunning and Collections
IUT240
You should select “Always dunn. notice?” for the last dunning level so that items at this level are not skipped. You can allocate a dunning procedure to contract accounts or for each individual line item in a document. IS-U: The move-in/out dunning procedure in the contract overrides the dunning procedure after the move-out date in the case of a move-out. The move-in/out dunning procedure in the contract account is valid as of the latest move-out date of all contracts for a contract account. The dunning data is saved in the dunning history. In Customizing for the dunning procedure you can set an indicator (“do not reduce dunning levels”), which prevents the system from reducing dunning levels. This indicator is processed by the dunning proposal run. Furthermore, for the interest calculation integrated into the dunning run for each dunning level, you can define how high the interest amount must be to be posted.
Figure 236: Dunning Level - Customizing Example
Dunning frequency: Minimum number of days that must have passed since the issue date of the last dunning notice. Print all items: If you set this indicator, all items that fulfill the same criteria for dunning grouping are printed on a dunning notice, regardless of whether the item is due or not.
340
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Always dun: Causes a dunning notice to be initiated on this dunning level as soon as the dunning frequency is reached in the execution of the dunning program, regardless of whether the days in arrears or minimum amounts have been reached. Charges: key defining a scheme for determining dunning charges which are usually levied in connection with the creation of dunning notices and other correspondence. You can use the indicator “Interest before Charges” in Customizing for the dunning level, in order to make the calculation of dunning charges dependent on whether interest has been calculated for items due for dunning. SAP provides the FKK_SPECIALCHARGE_0360 function module as an example of a calculation of this type. As standard procedure the interest in the dunning activity run are calculated and posted according to charges. Additionally, you can restrict the amount of dunning charges, if dunning interest (penalty charges) is charged as well as dunning charges. SAP provides the FKK_SPECIALCHARGE_0360 module as a template.
Figure 237: Dunning Activities
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
341
Unit 8: Dunning and Collections
IUT240
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. In IS-T you can generate a disconnection file, which is forwarded to the external billing system and triggers the disconnection of specified telephone numbers there. A workflow can be used, for example, to trigger an agent 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.
Figure 238: Dunning: Telephone Lists
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. 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
342
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
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.
Figure 239: Customizing Dunning Activities
Dunning activities consist of a function module (such as FKK_SAMPLE_0350_CCC) and a correspondence form (optional). It is a key representing an activity that is carried out in connection with the execution of a dunning run. Form for correspondence: If this is an activity for creating paper records as part of correspondence, you need to define the application form for the printout. You can assign any number of dunning activities to various dunning levels. Examples: • • • •
Print dunning form with different recipients Start workflow Send note to agent using SAP Office Deactivate installment plan
You can define your own function modules for standard activities. Example: You can trigger an activity in a dunning procedure, which informs the contract system (via RFC) that it should trigger a contract due to a payment not having been made.
2006/Q2
© 2006 SAP AG. All rights reserved.
343
Unit 8: Dunning and Collections
IUT240
Figure 240: Dunning Additional Receivables
Each combination of main and sub transaction can be assigned an additional receivables rule. The maintenance takes place in the Customizing for the additional receivables. You can set the exact properties of the additional receivables, depending on the operational company code: • • •
Subject to interest calculation (for additional receivables) Triggers dunning Take into account when calculating dunning balance
An indicator can be set to ensure that dunning charges and interest are considered with the dunning level, in which they were posted. This is necessary if grouping is executed by dunning level, and the additional receivables are to be dunned with their main receivables in the next dunning. Note that a dunning charge can reach a high dunning level in this way, which would not have been reached due to the days in arrears up to this point.
344
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Figure 241: Charge Schedule: Definition
Figure 242: Dunning Terminology - Charges
A charges schedule can manage the charges data for a maximum of three charges categories. These charge categories can be dunning charges, disconnection and reconnection charges, processing charges, payment document charges, postage charges, or customer defined charges. For the charge category, the main transaction and subtransaction are determined, with which the charge is to be posted (actual or statistical posting). For each combination of a charge schedule and a charge category, you can set up how charges are to be calculated depending on the currency, the dunning balance and credit-worthiness.
2006/Q2
© 2006 SAP AG. All rights reserved.
345
Unit 8: Dunning and Collections
IUT240
When you define a correspondence variant, you can assign a charge schedule to some correspondence types. When these correspondences are created, the system automatically posts the charges defined in the charge schedule. When defining processing variants for disconnection documents, you can also store a disconnection charges schedule in order to post a charge when entering a disconnection.
Figure 243: Charge Calculation
You can levy dunning charges as absolute charges, or as percentage charges. Percentage charges refer to the dunning balance.
346
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Figure 244: Using the Dunning Program
Before starting the dunning run, you should ensure that the posting situation is as up-to-date as is possible, which means that all existing payments should be posted and a clearing run executed. This means that you avoid dunning items which have already been paid. You can schedule the dunning proposal run and the dunning activity run together or separately. If you schedule both runs together, you lose the option of deleting and recreating the dunning proposal. You can reverse dunning notices from the dunning proposal. If you would like to have a different dunning proposal, you can delete it, make the necessary changes in the master data, open items or Customizing and then start the dunning proposal run again. A dunning run results in the dunning history and, for example, correspondence, a note to an agent, a charge or interest postings.
Figure 245: Dunning Proposal: Maintain Parameters
2006/Q2
© 2006 SAP AG. All rights reserved.
347
Unit 8: Dunning and Collections
IUT240
You need to enter parameters for a dunning proposal run whenever you want to create a dunning proposal. Alternatively, you can also define templates which can then be used to create a dunning proposal run. The system looks at the “date of issue” and compares this date to the due date within the document to determine which dunning level is appropriate (see “days in arrears” in Customizing of a dunning level) and to determine appropriate charges, if applicable. Note 429810 - Structure of Dunning Proposal Run in FI-CA - outlines the key points in the coding of the dunning proposal run. You get an overview of the dunning proposal run. This allows you, for example, to find out the correct events for a customer-specific request, or to modify the program.
Figure 246: Dunning Proposal Run
The dunning proposal run determines all items due for dunning and combines them in a dunning grouping. Hint: Once a business partner is included in a dunning proposal he/she will not be included in another proposal run. Only the dunning activity run enters the system date as the execution date of the dunning (MDRKD) in the dunning header. The dunning proposal then becomes dunning history. This check prevents duplicate dunning letters in case you postpone the dunning activity run. You cannot run a second proposal run over the same items/accounts unless the first is deleted (go to Environment → Delete Dunning Proposal Run). You can use history modules, event modules and function modules to define new dunning levels.
348
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
The dunning proposal run also takes into account the dunning reductions resulting from clarification cases in Dispute Management (function module FKK_SAMPLE_0335_DISPUTE). At event 0335 the dunning groups (I_FKKMAGRP) and dunning lines (I_FKKMAVS) are also transferred. The allocated dunning reduction amounts are also returned in the C_FKKMARED table.
Figure 247: Dunning Grouping
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 then enter grouping key in the contract accounts for which the grouping is to be valid.
2006/Q2
© 2006 SAP AG. All rights reserved.
349
Unit 8: Dunning and Collections
IUT240
Figure 248: Dunning Activity Run
You initiate a dunning activity run in much the same way as a dunning proposal run. First you enter the necessary parameters and then schedule the program run. If you have made the correct settings in Customizing, the date you entered in the issue date field will appear on the dunning letter. It will also be displayed in the dunning history as the dunning execution date (MDRKD). The dunning levels and appropriate dunning activities are determined based on the dunning groupings and items for dunning. A dunning activity run can result in a charge or interest posting, or updates in the dunning history and dunning activity history. Hint: Unlike a proposal run you cannot delete a dunning activity run after its execution, even if the intended action was not executed. Instead you must reverse the dunning run (transaction FPVC) or cancel the dunning for certain items. Go to Environment → Dunning History → Overview → Cancel… (the button with the red arrow).
350
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Figure 249: Dunning Activity Run: Technical Information
Hint: Technical notes: The following events are used in conjunction with the dunning printing/activity run: • • • • • • •
2006/Q2
310 (Called within Event 1797) Before the first process interval in the dunning activity run (set application-specific data) 320 (Called within Event 1798) After the first process interval in the dunning activity run (reorganize or delete application-specific data) 330 Event before processing a new dunning header 340 Once all data on a dunning header has been read, you can modify it prior to final processing Any number of activities can be triggered by each dunning notice (correspondence, work-flows, and so on) 360/361/362 Calculation of charges and structuring of charges documents 370 Calculation of interest and structuring of interest document
© 2006 SAP AG. All rights reserved.
351
Unit 8: Dunning and Collections
IUT240
Figure 250: Dunning History
You can call dunning history information using the account balance display (FPL9) or selecting “Dunning History” (FPM3) from the menu. In the dunning history you can see dunning activities (charge documents and interest documents). On the selection screen you can specify (Selection by Print Date) whether you want to display dunning notices that have been executed or not executed. This allows you, for example, to specify that only dunnings without print date are to be selected. In the dunning history, you can display a text for the business partner. To do this you must set the Read Business Partner Details indicator. In this case, the system runs event 0391. As standard, a text appears with the name and address of the business partner. With a customer-specific function module defined in event 4700, you can adjust this text to meet your requirements. For performance reasons you should not set the Read Business Partner Details indicator if you want an overview of a large number of dunnings.
352
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Figure 251: Dunning: Customizing
The dunning proposal run evaluates the execution variants at event 300. It only makes sense to specify an execution variant if you have defined an event.
2006/Q2
© 2006 SAP AG. All rights reserved.
353
Unit 8: Dunning and Collections
354
© 2006 SAP AG. All rights reserved.
IUT240
2006/Q2
IUT240
331
Lesson: Configuration and Execution of the Dunning Run
Exercise 12: Dunning Exercise Duration: 30 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Create and implement a dunning procedure with the predefined dunning levels and activities.
Business Example 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.
Task 1: Configuring a dunning procedure 1.
Create a dunning procedure that contains two dunning levels with the following parameters and activities: Dunning procedure
Use a key that has not yet been assigned (e.g. Z9, X8…), Name: “Dunning group ##”.
Factory calendar
Use the factory calendar 01 (German standard) or US (USA). This enables you to set the payment target and calculate the days in arrears according to working days.
Dunning levels: Dunning level
01 “01 Payment reminder group ##”
Days in arrears
7 days
Dunning frequency
7 days
Payment deadline
7 days
Charges schedule
01
Creditworthiness number 5
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
355
Unit 8: Dunning and Collections
IUT240
Amount limits: Currency
EUR (USD)
Amount limit
5
Dunning activities: Amount limit
5
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Dunning activities: Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Dunning levels: Dunning level
02, “Dunning and collection group ##”
Days in arrears
14 days
Dunning frequency
14 days
Payment deadline
14 days
Charges schedule
01
Creditworthiness
15
Determine interest
Yes
Interest key
01
Update key
1
Amount limits: Currency
EUR (USD)
Amount limit
10
Continued on next page
356
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Dunning activities: Amount limit
10
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Dunning activities: Amount limit
10
Currency
EUR (USD)
Creditworthiness
0
Number
2
Activity
0006
Dunning activities: Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Task 2: Using the new dunning procedure 1.
Allocate your new dunning procedure to contract account PICA0910## (PI0901C0##) and delete the incoming payment method for this contract account. Execute the dunning run for May 2nd 2006 and for business partner PICA0910## (PI0901C0##). Use dunning run MAH99 (DUN99) from May 2nd, 2006 as a template for your dunning run. Use the following information: Date identifier: 02.05.2006 Identification: MAH## (DUN##) Enter the following parameters: Date of issue: 02.05.2006 Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
357
Unit 8: Dunning and Collections
IUT240
Company code: U100 (U300) Business partner: PICA0910## (PI0901C0##) Start active run: Yes Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner. Save your entries and start the dunning run including 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. Display the dunning letter using System → Own Spool Requests.
358
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Solution 12: Dunning Task 1: Configuring a dunning procedure 1.
Create a dunning procedure that contains two dunning levels with the following parameters and activities: Dunning procedure
Use a key that has not yet been assigned (e.g. Z9, X8…), Name: “Dunning group ##”.
Factory calendar
Use the factory calendar 01 (German standard) or US (USA). This enables you to set the payment target and calculate the days in arrears according to working days.
Dunning levels: Dunning level
01 “01 Payment reminder group ##”
Days in arrears
7 days
Dunning frequency
7 days
Payment deadline
7 days
Charges schedule
01
Creditworthiness number 5 Amount limits: Currency
EUR (USD)
Amount limit
5
Dunning activities: Amount limit
5
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
359
Unit 8: Dunning and Collections
IUT240
Dunning activities: Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Dunning levels: Dunning level
02, “Dunning and collection group ##”
Days in arrears
14 days
Dunning frequency
14 days
Payment deadline
14 days
Charges schedule
01
Creditworthiness
15
Determine interest
Yes
Interest key
01
Update key
1
Amount limits: Currency
EUR (USD)
Amount limit
10
Dunning activities: Amount limit
10
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
Dunning activities: Amount limit
10
Currency
EUR (USD)
Continued on next page
360
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Creditworthiness
0
Number
2
Activity
0006
Dunning activities: Amount limit
0
Currency
EUR (USD)
Creditworthiness
0
Number
1
Activity
R001
a)
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 (for example, 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.
Task 2: Using the new dunning procedure 1.
Allocate your new dunning procedure to contract account PICA0910## (PI0901C0##) and delete the incoming payment method for this contract account. Execute the dunning run for May 2nd 2006 and for business partner PICA0910## (PI0901C0##). Use dunning run MAH99 (DUN99) from May 2nd, 2006 as a template for your dunning run. Use the following information: Date identifier: 02.05.2006 Identification: MAH## (DUN##) Enter the following parameters: Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
361
Unit 8: Dunning and Collections
IUT240
Date of issue: 02.05.2006 Company code: U100 (U300) Business partner: PICA0910## (PI0901C0##) Start active run: Yes Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner. Save your entries and start the dunning run including 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. Display the dunning letter using System → Own Spool Requests. a)
In the application menu, choose: Utilities Industry → Business Master Data → Contract Account → Change. On the “Payment/Taxes” tab page, delete 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, 2006. 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. Display the dunning letter using System → Own Spool Requests.
362
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Configuration and Execution of the Dunning Run
Lesson Summary You should now be able to: • Configure appropriate dunning procedures and know how to execute a dunning run in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
363
Unit 8: Dunning and Collections
Lesson: 340
IUT240
Submission to External Collection Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Submit receivables to external collection agencies, and know how to update further information on released items.
Business Example
Figure 252: Submission to External Collection Agencies
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.
364
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
Receivables submission is made up of two steps: 1.
Entry of database table DFKKCOLL, in which all submitted receivables and receivables to be released (Release for Submission) are managed.
2.
Selection of receivables to be submitted from the DFKKCOLL database table, and physical
submission of the receivables using report RFKKCOL2, which creates a file for each collection agency (Submission to Collection Agency). The dunning activity (FKK_COLL_AGENCY_RELEASE_0350) releases a receivable to an external collection agency. The submission of receivables to collection agencies is possible for the following items: • •
Receivables (also statistical items) Credit memos
The external collection agency is determined by derivation rules defined in Customizing (event 5060). Submission status 01: Release Receivable is set. The periodic submission flow (transaction FP03D or FP03DM) selects the documents and creates a list and/or a submission file (the submission file can also be generated in XML format). The following data is updated: •
•
In the collection agency item (DFKKCOLL): Submission date, submission status (02: Receivable submitted), and possible submission amount, if not identical to the amount in the open item. In the document: Payment block, dunning block, or alternative payer (posting area 1054).
Logs, which are listed in the DFKKOPCOLL table by the mass run for submitting receivables to collection agencies (FP03DM), can be deleted using the FP03DML transaction.
2006/Q2
© 2006 SAP AG. All rights reserved.
365
Unit 8: Dunning and Collections
IUT240
Submission Status •
01: Receivable released for submission Release process (dunning, mass release)
•
02: Receivable submitted Submission run
• • •
03: Receivable paid by collection agency (event 0020) 04: Receivable partially paid by collection agency (event 0020) 05: Submission of receivable reversed Dunning run reversal
• • • •
06: Submission of receivable failed (event 0020) 07: Receivable partially paid and submission of outstanding receivable reversed 08: Receivable partially paid and partially uncollectible (event 0020) 09: Receivable recalled Recall receivable
• • • •
10: 11: 12: 13:
Receivable paid directly by customer (event 0020) Receivable partially paid directly by customer (event 0020) Receivable cleared (event 0020) Receivable partially cleared (event 0020)
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. Under no circumstances should you change them.
366
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
Figure 253: Submission of Receivables to External Collection Agencies
In the Define Derivation Rules for Responsible Collection Agency you can define which collection agency is to be used, depending on the data in the document. The derivation rules defined in Customizing are evaluated by the derivation tool. The derivation tool is always called in the FKK_COLL_AG_SAMPLE_5060 function module when items are released for submission individually in transaction FP03E or in mass release using transaction FP03M. The derivation tool determines the responsible collection agency in one or a number of steps from a range of source fields of the enhanceable structure FKKCOLLAG. The number of derivation steps corresponds to the number of derivation rules you define in Customizing. If you want to continue using the old IMG activity because, for example, you have not transferred the derivation to the new IMG activity, define the function module FMCA_COLLAG_SAMPLE_5060 for event 5060.
2006/Q2
© 2006 SAP AG. All rights reserved.
367
Unit 8: Dunning and Collections
IUT240
Management of submitted receivables •
Receivables that were submitted to external collection agencies can be managed using transaction FP03. The following functions are available in transaction FP03: – – – – –
Change submission status (change document is generated) Indicator that the receivables were sold to the collection agency Submit receivables Recall receivables Create list of collection items
Inbound collection agency information •
The collection agency file contains:
– – – –
Collected payments Uncollected payments interest Charges
A RFKK60PM collection agency has completed a collection order and now forwards a file to the sold-to-party informing of the receivables that were collected, and those that were only partially collected or not at all.
Figure 254: Collection Agency Payment - Incoming Payment
368
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
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.
Figure 255: Collection Agency Payments: Postings
2006/Q2
© 2006 SAP AG. All rights reserved.
369
Unit 8: Dunning and Collections
IUT240
Figure 256: Information for Incoming Payment
If you want to ensure that the responsible processor is informed about incoming payments to collection items, the system can send a message when a payment is posted. The sample function module FMCA_CLERK_COLL_AG_0020 and the rule FMCA_COLL_AC (02100019) are delivered for this. As soon as a payment is made to a collections item, the processor receives an incoming document which is displayed in the SAP Business Workplace. Using this notification, the processor can decide whether an item has to be called back from the collections agency or whether other steps should be carried out.
Figure 257: Collection: Information for Collection Agency
370
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
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.
Figure 258: Collection: Customizing
2006/Q2
© 2006 SAP AG. All rights reserved.
371
Unit 8: Dunning and Collections
372
© 2006 SAP AG. All rights reserved.
IUT240
2006/Q2
IUT240
349
Lesson: Submission to External Collection
Exercise 13: Submitting Receivables to External Collection Agencies Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Submit released receivables for collection agencies.
Business Example The configured dunning procedure contains the release of receivables to external collection agencies in the second dunning step. After the dunning procedure you submit the released receivables to external collections.
Task: 1.
Execute a second dunning run for this business partner from unit 12-2. To do this, copy your dunning run MAH## (DUN##) from May 2nd 2006 (unit 12-2-1) to June 2nd 2006. Use the following information: Date identifier:
02.06.2006
Identification:
MAX## (DUX##)
Enter the following parameters: Date of issue:
02.06.2006
Company code:
U100 (U300)
Business partner:
PICA0910## (PI0901C0##)
Start active run:
Yes
Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner. Save your entries and start the dunning run including the dunning activities immediately. Check that the dunned items were released for collection.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
373
Unit 8: Dunning and Collections
2.
IUT240
Submit the receivables from business partner PICA0910## (PI0903C0##) to the collection agency GELDHER (COLLECT_IT). 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.
374
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
Solution 13: Submitting Receivables to External Collection Agencies Task: 1.
Execute a second dunning run for this business partner from unit 12-2. To do this, copy your dunning run MAH## (DUN##) from May 2nd 2006 (unit 12-2-1) to June 2nd 2006. Use the following information: Date identifier:
02.06.2006
Identification:
MAX## (DUX##)
Enter the following parameters: Date of issue:
02.06.2006
Company code:
U100 (U300)
Business partner:
PICA0910## (PI0901C0##)
Start active run:
Yes
Activate the log class for Additional information in the Logs tab page, in order to track all the dunning activities for your business partner. Save your entries and start the dunning run including the dunning activities immediately. Check that the dunned items were released for collection. a)
Copy your dunning run from exercise 12-2. Change the date to June 2nd, 2006 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.
Submit the receivables from business partner PICA0910## (PI0903C0##) to the collection agency GELDHER (COLLECT_IT). Display the status information of the submission. Which changes are made at document level when the item is submitted to the external collection agency?
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
375
Unit 8: Dunning and Collections
IUT240
Analyze the document changes. a)
376
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 the document number. Another double click on the business partner item takes you to the detail screen for the business partner item. The collection agency is recorded as alternative partner for payments (Payment Data tab page). Payment and dunning lock reasons have also been set (depending on the Customizing settings).
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Submission to External Collection
Lesson Summary You should now be able to: • Submit receivables to external collection agencies, and know how to update further information on released items.
2006/Q2
© 2006 SAP AG. All rights reserved.
377
Unit Summary
IUT240
Unit Summary You should now be able to: • Define the dunning terms used in Contract Accounts Receivable and Payable. • Configure appropriate dunning procedures and know how to execute a dunning run in Contract Accounts Receivable and Payable. • Submit receivables to external collection agencies, and know how to update further information on released items.
378
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 9 Interest Calculation
355
Unit Overview
Unit Objectives After completing this unit, you will be able to: • • •
Know the principles and transactions for interest calculation in Contract Accounts Receivable and Payable. Configure interest keys and calculation rules for interest on items. Execute interest calculation.
Unit Contents Lesson: Calculation of Interest on Items ....................................380 Lesson: Interest Keys and Calculation Rules ..............................384 Lesson: Processing of Interest Calculation..................................396 Exercise 14: Calculation of Interest on Items ...........................405
2006/Q2
© 2006 SAP AG. All rights reserved.
379
Unit 9: Interest Calculation
Lesson: 356
IUT240
Calculation of Interest on Items Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Know the principles and transactions for interest calculation in Contract Accounts Receivable and Payable.
Business Example
Figure 259: Interest Calculation: Considerations
380
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Calculation of Interest on Items
Figure 260: Business Transactions for Posting Interest
•
Debit interest: Interest on open debit items is calculated for the period from the due date to 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 to the date of clearing, 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 is to take place (for example, interest must not be calculated for items having the clearing reason “Reversal”).
•
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 is calculated for information only; it is not posted.
2006/Q2
© 2006 SAP AG. All rights reserved.
381
Unit 9: Interest Calculation
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
382
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Calculation of Interest on Items
Lesson Summary You should now be able to: • Know the principles and transactions for interest calculation in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
383
Unit 9: Interest Calculation
Lesson: 359
IUT240
Interest Keys and Calculation Rules Lesson Duration: 40 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Configure interest keys and calculation rules for interest on items.
Business Example
Figure 261: Interest parameters
The interest key contains all control parameters for calculating interest, for example, the parameters for selecting items and the reference to the calculation rule.
384
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Priority of interest key determination •
• •
An interest key entered in the item has the highest priority. You can enter the interest key manually, or it can be determined from the transactions and entered in the item by the system at the time of posting. If interest is calculated for an item within the framework of the dunning procedure, an interest key can be stored in the dunning level. The interest key can also be entered in the contract account.
If an interest key cannot be determined, interest calculation is not possible. The valid interest rates are found using the interest calculation rule. Additional conditions can also be stored in the interest calculation rule. The interest rates depend on: • •
The reference interest rates (optional) The analysis period
Item interest calculation is controlled via the ‘interest key’ parameter. An interest key is determined for each item for which interest should be calculated. An interest key consists of all control parameters for interest calculation and interest posting. •
Parameters for item selection
Figure 262: Posting Interest
The interest key controls interest calculation and can be assigned to contract accounts, a security deposit, individual line items or dunning levels.
2006/Q2
© 2006 SAP AG. All rights reserved.
385
Unit 9: Interest Calculation
IUT240
To avoid charging your business partners very small amounts, you can carry out amount checks per customer or industry. Interest locks enable you to prevent interest from being calculated on certain items. You can also exclude certain business transactions (such as reversal postings or additional receivables for interest calculation). Interest can be posted so that it is also posted to the general ledger. Debit interest can also be posted as a statistical item (in other words, not posted to the general ledger). An interest document is generated when interest is posted. Posting interest is integrated into some business transactions. In addition to the usual document data, an interest document also contains information about the basis of interest posting. This information is contained in the interest supplement. The interest supplement contains the items for which interest was calculated, as well as the relevant amounts and intervals. The interest key is retained in the interest supplement. This allows you to find out which factors were valid for interest calculation and posting. When interest is posted (via manual posting, installment plan, dunning procedure, etc) the resulting document contains a ‘source key’ in its header. The source key identifies the business process that generated the interest calculation. For example, source key “28” identifies that the interest document resulted from a dunning procedure (you can see the possible source keys in the TFK001 table).
Figure 263: Interest Calculation: Configuration
386
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Item interest calculation is controlled via the ‘interest key’ parameter. An interest key is determined for each item for which interest should be calculated. An interest key consists of all control parameters for interest calculation and interest posting. • •
Parameters for item selection Reference to a calculation rule
Figure 264: Interest Calculation: Configuration
Tolerance days (grace period): Minimum number of days that must have passed since the due date for net payment of a receivable before calculating interest. If the receivable is cleared within the tolerance days, no interest calculation or interest posting can take place. Hint: Tolerance days are not taken into account for interest calculations in the future (such as installment plan interest). Interest frequency: Interest calculation frequency determines the earliest point at which interest will be calculated for an item if interest has already been calculated (for example, days, months, years). Transfer days: Refers to the period that it takes a bank to clear a payment and provide the clearing information. This ensures that interest calculation does not take place on a receivable for which payment is delayed by the bank. Baseline date for interest calculation = due date for net payment + grace period + transfer days.
2006/Q2
© 2006 SAP AG. All rights reserved.
387
Unit 9: Interest Calculation
IUT240
Figure 265: Configuration of the Interest Calculation Rule
The interest calculation rule contains the parameters for interest calculation: • •
Reference to a reference interest rate (dynamic interest rate) Fixed rates (static interest rate)
Interest calculation rules: Interest rates are stored per currency and debit/credit indicator according to date. They can also be based on a reference interest rate such as the federal funds rate. Interest calculation can be carried out on a monthly basis. For example, interest can be 2% for each month.
388
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Figure 266: Interest Calculation Rules: Details
The interest calculation method dictates how interest is to be calculated. Most customers use method “act/365”, which tells the system to calculate interest based on a 365 day period, although other methods are also available. The flag for “scale types” is used if the interest rate used is based on amounts. For example, you may wish to charge an interest rate of 5% on the first 1000 balance and then 6% for any balance above 1000. The interest interval can be set to a day, week, month, or year. In most countries this indicator is set to “years”. However, some countries with high inflation rates use “days” or “weeks” (such as Brazil). • • •
You can round interim interest calculations. Rounding rules can differ and must be customized. Example: Interest is to be calculated on an amount for the period from 01/01 to 01/20, using a higher interest rate from 01/10 on. Interest from 01/01 to 01/09: 10.12345 Interest from 01/01 to 01/20: 30.34437
If the amount is to be calculated to two decimal places, the total interest without flagging “Round interim interest totals” is 40.47 (10.12345 + 30.34437 = 40.46782). If the indicator is set, then the total interest is 40.46 (10.12 + 30.34). Interest on total amount. This indicator is used in conjunction with the option “staggered interest rate types”. For example, if the interest rate varies according to amounts and this indicator is set, then the interest rate used will be applied to the entire amount. If the indicator is not set, then the interest rate set per amount is used.
2006/Q2
© 2006 SAP AG. All rights reserved.
389
Unit 9: Interest Calculation
IUT240
Figure 267: Interest Calculation: Rounding Rules
Rounding rules are assigned to interest calculation rules in the ‘interest terms’ section of interest calculation Customizing. Three rounding rules are provided for interest calculation: • • •
“’ ’” round to the nearest whole number “-” always round down to the nearest whole number “+” always round up to the nearest whole number Grouping of items before interest calculation
Event 2085 provides you with further, more extensive options for grouping items before the interest calculation - provided you have set the “Group Subitems before Interest Calculation” indicator in the interest key. See the documentation for the FKK_SAMPLE_2085 and FKK_CONDENSE_2085 function modules. Therefore, for example, if you use different interest rates to calculate interest on receivables and payables, you can group items in event 2085 before the interest calculation and use the interest rate for receivables if the amount of the receivables exceeds that of the payables. Using a function module processed in event 2075 you can round the result of the interest calculation up or down. If you enter function module FKK_ROUND_INT_AMOUNT in event 2075, you can round the interest calculated using function module FKK_INTEREST_CALC according to the values defined in Customizing.
390
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Figure 268: Interest Calculation: Additional Receivables
For additional receivables (interest and charges) that are generated by FI-CA, it is possible to define interest calculation rules. The “interest calculation” indicator informs the system whether or not the additional receivable should be included when calculating interest You may also specify a specific interest key for these additional receivables for each responsible company code.
Figure 269: Interest Key: Determination
2006/Q2
© 2006 SAP AG. All rights reserved.
391
Unit 9: Interest Calculation
IUT240
The system looks for an interest key in the sequence 1 to 4. If no interest key can be determined, interest calculation is not possible and interest will not be calculated for the item. The system only calculates interest on those items for which it is able to determine an interest key. An interest key can be assigned to a contract account, items or dunning levels. The system normally determines the interest key for each industry, but can also do so on a customer-by-customer basis. Hint: This hierarchy is defined in event 2000. If desired, you can change the coding of the event to change this hierarchy.
Figure 270: Dunning Level - Customizing for Interest
You set the “calculate interest” flag if you wish to calculate interest when this dunning level is reached. In general, the “interest key” determines the calculation rule and the period control. The “update key” has three possible settings: •
• •
392
“’ ’” = interest is only calculated, not posted. An organization can send a letter to a customer, informing them that they could have charged interest, but opted not to. “1” = interest is calculated and posted statistically (you do not expect to complete the transaction or collect the interest). “2” = interest is calculated and posted. The general ledger is updated as a result.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Figure 271: Interest Calculation: Customizing
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 are client-dependent. Interest calculation rules are used in different application components. Therefore, interest calculation rules may already be maintained here. Interest calculation rules are allocated to interest keys in the ’Define Interest Keys’ process step. You must enter the interest calculation rule in the interest key. You can also allocate other parameters to the interest key. In the additional functions for interest calculation, you can determine whether the following takes place when interest is calculated for line items: • •
Interest calculation based on net amounts Interest calculation for source items when installment plan items are cleared
In the Customizing settings for transactions, you must set the interest transactions, the allocation to internal transactions, assignment of the statistical transactions, and account determination.
2006/Q2
© 2006 SAP AG. All rights reserved.
393
Unit 9: Interest Calculation
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
394
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Interest Keys and Calculation Rules
Lesson Summary You should now be able to: • Configure interest keys and calculation rules for interest on items.
2006/Q2
© 2006 SAP AG. All rights reserved.
395
Unit 9: Interest Calculation
Lesson: 370
IUT240
Processing of Interest Calculation Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Execute interest calculation.
Business Example
Figure 272: Interest Calculation: Timeline
With a function module processed in event 2065 you can change the date for the Interest Calculation To for clearing items. For amounts cleared in the account maintenance, the due date of the bill and clearing date of both items are used as standard to calculate the interest. In event 2065 you can use the due date of the bill amount and the value date of the payment amount to calculate the interest for amounts cleared in the account maintenance.
396
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Figure 273: Mass Invoice Processing: Selection
Figure 274: Individual Interest Calculation: Preparation
The default document type and statistical key displayed on this screen are defined in Customizing and may be overwritten at the time of posting. The “single document” indicator shows whether or not the system will create a separate document in the SAP ERP general ledger for this each line item, for which interest is calculated. The number of the document posted in FI-CA is stored as the reference document number in the general ledger document.
2006/Q2
© 2006 SAP AG. All rights reserved.
397
Unit 9: Interest Calculation
IUT240
You must tell the system if you wish to calculate interest on debit or credit items. Hint: (It is not possible to select “credit items” and indicate “only open debit items” at the same time.) By selecting the option “cleared items only”, the user ensures that if any partial payments (resulting in 2 sub-items) are made that interest calculation only takes place when the item is totally cleared. In the calculate interest to field you inform the system the date, up to which interest is to be calculated. Hint: Interest calculations are usually posted using the “interest run” function and not manually.
Figure 275: Item Selection for Interest Calculation
Green light means that interest may be calculated; red light means that the item is blocked for interest calculation. You can double-click on a red light to find out why interest cannot be calculated for that particular item.
398
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Figure 276: Summarization of Interest Items
In order to minimize the number of interest documents that the system must post, only one interest document per matching summarization criteria is posted in the system. The summarization criteria (fields) for interest items are transferred from source items to the interest items. SAP delivers several default fields for summarization. You cannot delete these criteria. Standard delivered fields include: Company code, business area, business partner number, contract account number, division, and so on. You can also add more fields (up to a maximum of 12 criteria, including the standard delivered summarization fields). Hint: Technical note: The summarization criteria are defined in the structure FKKIV.
2006/Q2
© 2006 SAP AG. All rights reserved.
399
Unit 9: Interest Calculation
IUT240
Figure 277: Calculation Exceptions: Interest Lock
Interest locks enable you to prevent interest from being calculated on certain items. You can also exclude certain business transactions (such as reversal postings or additional receivables for interest calculation). Moreover an item will not be selected in the following cases: • •
• • • •
If it does not meet selection criteria If it is excluded from interest calculation in event 2010. The function module called up with event 2010 checks whether interest can be calculated on a line item. In the reference function module, statistical items can be excluded from interest calculation. If it is an additional receivable and interest calculation was excluded If it is not due If it is not ready as a result of Customizing settings for transfer days, tolerance days (grace period), or interest period If interest has already been calculated for the item for the given period.
In Customizing you define the clearing reasons (table TFK056C) for cases when the interest calculation is not calculated retroactively (for example, reversals).
400
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Figure 278: Interest Calculation: Exceptions
Because interest keys are linked to calculation rules, which in turn are linked to a currency type, an interest document can only be created in one currency at a time. If you had items in different currencies, the system would have no way of determining which currency the interest document should be posted in. If postings exist in several currencies for an account then interest posting must be called up for each currency.
Figure 279: Exception for Posting Interest: Amount Limit
Debit interest is requested if the calculated interest is over a minimum amount limit that is set in Customizing.
2006/Q2
© 2006 SAP AG. All rights reserved.
401
Unit 9: Interest Calculation
IUT240
The amount limit for posting interest is dependent on the company code, the debit/credit indicator, and the currency. Items are first summarized by criteria, and then interest must reach the defined minimum level to be posted. Standard check: Total amounts for all interest for a company code are compared with the minimum amount limit defined in the TFK057 table. For item interest calculation you can round items before the interest calculation. If interest is calculated on several items together, each item is rounded individually. You can group subitems before the interest calculation so that a split item is subject to interest in exactly the same way as an item that has not been split. Event 2085 provides you with further, more extensive options for grouping items before the interest calculation - provided you have set the “Group Subitems before Interest Calculation” indicator in the interest key. Therefore, for example, if you use different interest rates to calculate interest on receivables and payables, you can group items in event 2085 before the interest calculation and use the interest rate for receivables if the amount of the receivables exceeds that of the payables.
Figure 280: Additional Functions
402
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Figure 281: Interest Supplement and Interest History
An interest document includes the structures of a document in FI-CA: Document header, line items and general ledger (G/L) items. In addition to the usual document data, an interest document also contains information about the basis of interest posting. This information is contained in the interest supplement. For each interest item, the interest supplement tells you how the interest amount was determined, including source items, interest period and interest rate. This allows you to reconstruct how interest was determined at a later date. The interest supplement can be accessed via an interest document. An interest history records the interest calculation period for each line item on which interest has been calculated. During interest calculation, the selected items and the interest are considered jointly. This ensures that interest is only calculated for items once for a certain period. Interest → Select line items. Select the items for which you want to calculate interest. Hint: If the system settings for the interest calculation rule or for the interest rule are changed at a later time, you will no longer be able to retrace interest calculation using the interest supplement. If the rate is changed for dates in the past, nothing will happen. The system will, however, issue a warning if you attempt such a change.
2006/Q2
© 2006 SAP AG. All rights reserved.
403
Unit 9: Interest Calculation
IUT240
Figure 282: Interest Document Structures and Technical Details
This slide shows some of the technical information necessary for customers that may wish to add events to standard interest related programs.
404
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
379
Lesson: Processing of Interest Calculation
Exercise 14: Calculation of Interest on Items Exercise Duration: 20 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Calculate debit and credit interest for open and delayed cleared items. You will be able to post interest online and in a mass run.
Business Example One of your business partners has not paid his bill. You want to calculate interest for this overdue item.
Task: Interest Calculation 1.
Manual calculation of interest for debit items. Calculate the interest for the overdue items of business partner PICA1010## (PI1001C0##). Use the following information: Document date:
Today’s date
Posting date:
Today’s date
Business partner:
PICA1010## (PI1001C0##)
Currency:
EUR (USD)
Debit items:
X
All items:
X
Calculate interest to:
Today’s date
Once you have selected the “Line Items” function, the system displays as message stating that the account contains credit items. Confirm the message that appears by choosing Enter. Select the overdue items, use the Display Interest function to display the calculated interest, and post the interest. Write down the document number: ______________________________ Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
405
Unit 9: Interest Calculation
2.
IUT240
Mass calculation of interest First of all, post another receivable to the amount of EUR (USD) 800 for business partner PICA1010## (PI1001C0##). Use the following information: Document date:
01.02.2006
Posting date:
01.02.2006
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:
01.02.2006
Contract account:
PICA1010## (PI1001C0##)
Transaction:
6000 / 0020
Amount:
800,00
Start the mass calculation of interest. Use the interest run from June 1st, 2006 with identification ZIN99 (INT99) as a copy template for your payment run with today’s date as the date identifier and identification: ZI0##
(## = Group number)
Change the following parameters: Date of issue:
Today’s date
Posting date:
Today’s date
Calculate interest to:
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.
406
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Solution 14: Calculation of Interest on Items Task: Interest Calculation 1.
Manual calculation of interest for debit items. Calculate the interest for the overdue items of business partner PICA1010## (PI1001C0##). Use the following information: Document date:
Today’s date
Posting date:
Today’s date
Business partner:
PICA1010## (PI1001C0##)
Currency:
EUR (USD)
Debit items:
X
All items:
X
Calculate interest to:
Today’s date
Once you have selected the “Line Items” function, the system displays as message stating that the account contains credit items. Confirm the message that appears by choosing Enter. Select the overdue items, use the Display Interest function to display the calculated interest, and post the interest. Write down the document number: ______________________________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Interest → Post Enter the required information and select the debit items. Use the Line Items function 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.
2.
Mass calculation of interest First of all, post another receivable to the amount of EUR (USD) 800 for business partner PICA1010## (PI1001C0##). Use the following information: Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
407
Unit 9: Interest Calculation
IUT240
Document date:
01.02.2006
Posting date:
01.02.2006
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:
01.02.2006
Contract account:
PICA1010## (PI1001C0##)
Transaction:
6000 / 0020
Amount:
800,00
Start the mass calculation of interest. Use the interest run from June 1st, 2006 with identification ZIN99 (INT99) as a copy template for your payment run with today’s date as the date identifier and identification: ZI0##
(## = Group number)
Change the following parameters: Date of issue:
Today’s date
Posting date:
Today’s date
Calculate interest to:
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.
Continued on next page
408
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Processing of Interest Calculation
Check the interest calculated in the account display. a)
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, 2006 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
409
Unit 9: Interest Calculation
IUT240
Lesson Summary You should now be able to: • Execute interest calculation.
410
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Know the principles and transactions for interest calculation in Contract Accounts Receivable and Payable. • Configure interest keys and calculation rules for interest on items. • Execute interest calculation.
2006/Q2
© 2006 SAP AG. All rights reserved.
411
Unit Summary
412
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 10 Deferral/Installment Plan
387
Unit Overview
Unit Objectives After completing this unit, you will be able to: • •
Enter a deferral for an open item. Create and process installment plans for open items.
Unit Contents Lesson: Deferral: Definition and Processing ...............................414 Exercise 15: Manual Deferral of Open Items ...........................417 Lesson: Installment Plan: Definition and Processing .....................420 Exercise 16: Creating an Installment Plan ..............................429
2006/Q2
© 2006 SAP AG. All rights reserved.
413
Unit 10: Deferral/Installment Plan
Lesson: 388
IUT240
Deferral: Definition and Processing Lesson Duration: 10 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Enter a deferral for an open item.
Business Example Deferral: Definition • •
If the business partner is temporarily unable to settle his/her open items, the due date is postponed. As a rule, additional surcharges, charges, or interest are charged.
Until the date specified the deferred item will not be dunned in a dunning run and will not be collected from the bank by the payment program. Once the deferral date has passed, or if you have deleted the date from the item, the item can be dunned again and collected.
414
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Deferral: Definition and Processing
Figure 283: Deferral: Processing (1)
Deferral can be performed manually in the document change transaction or automatically during returns processing. You can enter a deferral date when you post the document or when you change the line items in the document. The deferral does not change the original due date. The deferral date is used instead of the due date to automatically create dunning notices or debit memos. Document → Change Enter the document number. Choose Goto → List and display the business partner items (or choose the corresponding pushbutton). Double click on the amount to be deferred. Enter a deferral date (in the field to the right of the due date). DO NOT OVERWRITE THE DUE DATE. Save the document. To reverse a deferral, delete the deferral date in the item (transaction: Change Document).
2006/Q2
© 2006 SAP AG. All rights reserved.
415
Unit 10: Deferral/Installment Plan
IUT240
Figure 284: Deferral: Processing (2)
Debit interest: Interest on open debit items is calculated for the period from the due date to 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 to the date of clearing, 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 is to take place (for example, interest must not be calculated for items having the clearing reason “Reversal”). 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 is calculated for information only; it is not posted.
416
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
391
Lesson: Deferral: Definition and Processing
Exercise 15: Manual Deferral of Open Items Exercise Duration: 10 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Defer open items manually.
Business Example 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.
Task: Deferral 1.
Manual deferral of an open item. Defer an open receivable for business partner PICA1110## (PI1101C0##). Use the following information: Deferral date:
15. of the following month
Save your entries
2006/Q2
© 2006 SAP AG. All rights reserved.
417
Unit 10: Deferral/Installment Plan
IUT240
Solution 15: Manual Deferral of Open Items Task: Deferral 1.
Manual deferral of an open item. Defer an open receivable for business partner PICA1110## (PI1101C0##). Use the following information: Deferral date:
15. of the following month
Save your entries a)
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.
418
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Deferral: Definition and Processing
Lesson Summary You should now be able to: • Enter a deferral for an open item.
2006/Q2
© 2006 SAP AG. All rights reserved.
419
Unit 10: Deferral/Installment Plan
Lesson: 394
IUT240
Installment Plan: Definition and Processing Lesson Duration: 30 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Create and process installment plans for open items.
Business Example
Figure 285: Installment Plan: Definition
420
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Figure 286: Installment Plan: Processing
With an installment plan you divide source items into several installment receivables that have a due date in the future or in the past. Once an installment plan has been posted, the items of the installment plan and not the source items are referred to when a bank collection is made, or when a dunning run is carried out. An installment plan consists of a statistical document with several installment receivables. The individual installment receivable is cleared upon payment. The number of the installment plan is saved in the source items. If interest is payable on an installment plan, the installment plan will also have an interest supplement. You can use the installment plan history to determine the source items on which an installment plan is based (Account → Other Information → Installment Plan History →).
Figure 287: Installment Plan: Technical View
2006/Q2
© 2006 SAP AG. All rights reserved.
421
Unit 10: Deferral/Installment Plan
IUT240
One or more open items can be broken down into a particular installment plan. The number of installments within the plan, the interest key are defined when creating an installment plan. The interest key controls the grace period, interest frequency, interest interval unit, and the interest calculation rule Frequently occurring installment terms and conditions can be stored in the system as default installment plans. If the agreement for payment in installments is canceled, you can deactivate the installment plan manually. This means that the original receivable becomes active again and the link between the original receivable and the installment plan is deleted.
Figure 288: Installment Plan: Document Structure
Installments linked to installment plans are mapped as repetition documents. A sample business partner item (repetition group) is structured and repetition items are mapped for the individual due dates. Legend: • • • • • •
422
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
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Figure 289: Transaction Flow: Create Installment Plan
Installment plans can be created for one or more open items for an account (provided they have the same currency).
Figure 290: Installment Plan: Configuration
2006/Q2
© 2006 SAP AG. All rights reserved.
423
Unit 10: Deferral/Installment Plan
IUT240
As of release ERP 2005 you can define an alternative payer to the business partner for installment plan items. Use the new input field Partner for Payment to do this. There you can maintain an alternative payer for each installment. Previously, you could only define a bank details ID for installment plan items but not a payment card ID. You can now use the new input field Card ID to enter a payment card ID.
Figure 291: Installment Plan Category: Configuration
You can create an installment plan category in Customizing, which can then be used to post an installment plan. Installment intervals define the length of the intervals between installments. An interval category defines the interval between installments (for example, month). Distribute interest and charges to all installments: Definition whether installment interest and charges for the installment plan are to be distributed to all installments. The interest and charges are distributed according to the size of the installment. The individual installment amounts are rounded to a multiple of this amount. Residual amounts that result from the rounding process are added to the first or last installment. The rounding amount can be entered with up to three decimal places. If the amount is rounded, the system takes into account the currency in question and rounds the amount to the reduced number of decimal places. The installment amount is the amount of the individual installment payments. The installment amount can be entered as an alternative to the rounding amount and number of installments. A charge can be calculated for granting an installment plan. If a charge is entered, the system automatically posts a charge document when creating the installment plan, and adds the charge to the first installment.
424
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Remaining amount: A remaining amount can result when calculating the size of the individual installments of an installment plan. Residual amounts that result from the rounding process are added to the first or last installment, or a separate installment. If you do not specify a value here, then the remaining amount is automatically added to the last installment. Installment plan categories can be used to group installment plans. You can define an alternative subtransaction for an installment plan.
Figure 292: Transaction Flow: Change Installment Plan
You can make the following changes in an installment plan: 1. 2.
2006/Q2
Delete installments or add further installments Change the due date and amount for an individual installment receivable, provided that the installment receivable has not yet been paid.
© 2006 SAP AG. All rights reserved.
425
Unit 10: Deferral/Installment Plan
IUT240
Figure 293: Installment Plan: Deactivation
If the installment plan has not yet been paid or has only been partially paid, it is possible to carry out automatic cancellation of the interest document and the charge document for this installment plan. Interest items can be reversed. From the menu, select Account → Installment Plan → Change Installment Plan. Enter the number of the installment plan and select Continue → Installment Plan → Deactivate. The system displays a dialog box in which you select interest document. Choose Continue. The installment plan interest document is then reversed automatically.
426
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Figure 294: Transaction Flow: Post Installment Plan Interest
Interest is calculated for the duration of the installment plan. Interest can again be recalculated and posted if the customer falls behind with his payments again. Example: The customer phones and requests an installment plan that is to consist of 6 installments from Jan 1 through to June 1. However, on August 1 the customer still has an outstanding balance. It is possible to calculate and post interest on the unpaid balance that exists after June 1. It is also possible to integrate interest in the installation plan at a later date using the FPR2 Change Installment Plan transaction.
2006/Q2
© 2006 SAP AG. All rights reserved.
427
Unit 10: Deferral/Installment Plan
IUT240
Figure 295: Installment Plan: Interest Calculation
Figure 296: Installment Plan: Customizing
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).
428
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
403
Lesson: Installment Plan: Definition and Processing
Exercise 16: Creating an Installment Plan Exercise Duration: 15 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Use the installment plan functionality in FI-CA. • Include interest and charges in installment plans.
Business Example One of your business partners calls. He cannot pay his bills at the present time and asks you to defer his payment. You have already deferred one item with a smaller amount. For the larger amount, you offer the business partner the opportunity to pay using an installment plan. The customer accepts.
Task: Installment Plan 1.
Creating an installment plan. Now create an installment plan for the open and due items from your business partner’s consumption bill. Use the following information: Business partner:
PICA1110## (PI1101C0##)
Contract account:
PICA1110## (PI1101C0##)
Currency:
EUR (USD)
Posting date: Today’s date Use the function for displaying the account balances and select the required item. Create an installment plan with installment plan category E002 (0002). Start date:
Today’s date
Now use the “Installment plan” function to go to the next screen.
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
429
Unit 10: Deferral/Installment Plan
IUT240
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: ___________________________
430
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Solution 16: Creating an Installment Plan Task: Installment Plan 1.
Creating an installment plan. Now create an installment plan for the open and due items from your business partner’s consumption bill. Use the following information: Business partner:
PICA1110## (PI1101C0##)
Contract account:
PICA1110## (PI1101C0##)
Currency:
EUR (USD)
Posting date: Today’s date Use the function for displaying the account balances and select the required item. Create an installment plan with installment plan category E002 (0002). Start date:
Today’s date
Now use the “Installment plan” function to go to the next screen. Change the installments here (for example, due date and installment amounts). When you change the amounts, make sure the total of the installments corresponds to the source receivable. Do not post the installment plan yet. Use the “Calculate interest” function to calculate the interest for the installment plan. Enter today’s date as the date for starting interest calculation. Post the installment plan. Write down the installment plan number:
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
431
Unit 10: Deferral/Installment Plan
IUT240
___________________________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Installment →Plan → Create. Select Display Account Balances and then choose 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. Use the “Calculate interest” function to calculate the interest for the installment plan. Choose Save to save the installment plan.
432
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Installment Plan: Definition and Processing
Lesson Summary You should now be able to: • Create and process installment plans for open items.
2006/Q2
© 2006 SAP AG. All rights reserved.
433
Unit Summary
IUT240
Unit Summary You should now be able to: • Enter a deferral for an open item. • Create and process installment plans for open items.
434
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 11 Other Business Transactions
409
Unit Overview This unit will provide you with an overview of: • • • • • •
The options in account maintenance The reversal of documents Clearing reset Transfer posting of documents Marking documents as doubtful entries and individual value adjustment Writing off documents
Unit Objectives After completing this unit, you will be able to: • • • • •
Explain account maintenance in Contract Accounts Receivable and Payable. Explain the principles involved in reversing documents and resetting clearing in Contract Accounts Receivable and Payable. Transfer a document in Contract Accounts Receivable and Payable. Explain the procedures and postings for doubtful postings and value adjustment of open items. Write off uncollectible receivables in Contract Accounts Receivable and Payable.
Unit Contents Lesson: Account Maintenance ................................................437 Exercise 17: Manual Account Maintenance ............................443
2006/Q2
© 2006 SAP AG. All rights reserved.
435
Unit 11: Other Business Transactions
IUT240
Lesson: Reversing Documents and Resetting Clearing ...................446 Lesson: Document Transfer ...................................................456 Lesson: Mark as Doubtful / Individual Value Adjustment .................460 Lesson: Write Off ...............................................................465 Exercise 18: Manual Write Off ............................................469
436
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 410
Lesson: Account Maintenance
Account Maintenance Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain account maintenance in Contract Accounts Receivable and Payable.
Business Example
Figure 297: Account Maintenance in FI-CA
2006/Q2
© 2006 SAP AG. All rights reserved.
437
Unit 11: Other Business Transactions
IUT240
Figure 298: Account Maintenance: Process
You can select open items in the initial screen for account maintenance. In the processing screen, you can change or add items to this selection, as well as include other contract accounts or business partners. Items allocated to the proposal from clearing control are already active. However, you can change the allocation and ignore the proposal.
Figure 299: Example: Manual Account Maintenance
You can have the system automatically create a clearing proposal for you (results can be edited) or you may create and modify the proposal manually (often necessary when processing partial payments) when performing manual account maintenance.
438
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Maintenance
Figure 300: Manual Account Maintenance FP06 - View 1: Clear
As of ERP 2005 in account maintenance you can perform document changes as well as carry out clearing. You can switch between both processing views in the transaction.
Figure 301: Manual Account Maintenance FP06 - View 2: Change
For the document changes, you can define the line variants with different modifiable fields in Customizing (structure FKKOP_CHG). You can make document changes directly in the line item. Alternatively, you can make a change for several selected lines simultaneously.
2006/Q2
© 2006 SAP AG. All rights reserved.
439
Unit 11: Other Business Transactions
IUT240
In addition to document changes, you can also split line items. You can combine clearing, splitting, and changing with few restrictions. You can split line items into several sub-items. However, this function is not available for items displayed summarized. You must first cancel the summarization. To split an item, place the cursor on the item required and then choose the function ’Split Item’. The system inserts a new item beneath the item to be split. The amount of the new sub-item is initially zero. Enter the required partial amount. The system automatically reduces the amount of the original item accordingly. You can no longer split an item that has been selected for full clearing. If you split an item for which partial clearing is planned, the system automatically proposes the partial amount that is not to be cleared in the sub-item. You can reduce this amount manually, but not increase it. In this case too, you can no longer split an item for which clearing has been planned. For new sub-items created, you can make the same changes as for original items. You can clear the new sub-items either partially or in full. You can reset all of the changes you have made to an item provided you have not saved the data yet. Select the required item(s) and then choose the function ’Reset Change’. To reset a split, place the cursor on the sub-item and choose the ’Reset Split’ function. If several split items have been created for an item, and you want to reset all of them, place the cursor on the original item and then choose ’Reset Split’.
Figure 302: Account Maintenance: Customizing
440
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Maintenance
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
441
Unit 11: Other Business Transactions
442
© 2006 SAP AG. All rights reserved.
IUT240
2006/Q2
IUT240
415
Lesson: Account Maintenance
Exercise 17: Manual Account Maintenance Exercise Duration: 15 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Clear credits and receivables within account maintenance.
Business Example In addition to receivables, one of your business partners also has credit from a payment on account. You clear the credit against the receivables.
Task: Manual Account Maintenance 1.
Clear the receivable using the payment on account in contract account PICA1210## (PI1201C0##) of the business partner with the same number. Use the following information: Business partner:
PICA1210## (PI1201C0##)
Contract account:
PICA1210## (PI1201C0##)
Company code:
U100 (U300)
Currency:
EUR (USD)
Posting date:
Today’s date
Instruct the system to generate a clearing proposal. Check the proposal and post the clearing. Write down the document number: ______________________________
2006/Q2
© 2006 SAP AG. All rights reserved.
443
Unit 11: Other Business Transactions
IUT240
Solution 17: Manual Account Maintenance Task: Manual Account Maintenance 1.
Clear the receivable using the payment on account in contract account PICA1210## (PI1201C0##) of the business partner with the same number. Use the following information: Business partner:
PICA1210## (PI1201C0##)
Contract account:
PICA1210## (PI1201C0##)
Company code:
U100 (U300)
Currency:
EUR (USD)
Posting date:
Today’s date
Instruct the system to generate a clearing proposal. Check the proposal and post the clearing. Write down the document number: ______________________________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Maintain. Set the “Create proposal” field and choose Open Items. Check the proposal and post the clearing with function Account → Post.
444
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Account Maintenance
Lesson Summary You should now be able to: • Explain account maintenance in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
445
Unit 11: Other Business Transactions
Lesson: 418
IUT240
Reversing Documents and Resetting Clearing Lesson Duration: 20 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Explain the principles involved in reversing documents and resetting clearing in Contract Accounts Receivable and Payable.
Business Example
Figure 303: Reversal of Documents: Restrictions
446
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Reversing Documents and Resetting Clearing
Figure 304: Reversal of Documents
Document to be reversed: •
After reversal, the business partner items have the clearing document number of the reverse document.
Indicator: reverse document: • •
2006/Q2
Reference to the reversed document using the document number from the reversed document in the document header. In the reversal document, an item is created for every G/L. These items have the opposite +/- sign to the G/L item.
© 2006 SAP AG. All rights reserved.
447
Unit 11: Other Business Transactions
IUT240
Figure 305: Mass Reversal: Parameters
Figure 306: Negative Postings
A negative posting reduces the transaction figures for the account posted to in the general ledger. A debit posting as negative posting therefore does not lead to an increase of the debit transaction figures; it leads to a reduction of the credit transaction figures. This enables you to show transaction figures for accounts after an incorrect posting and subsequent correction (for example, invoice posting and reversal) as if neither the incorrect posting nor the correction had taken place.
448
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Reversing Documents and Resetting Clearing
Negative postings have been supported in the general ledger (FI-GL) for a long time. You decide whether to permit negative postings at company code level. The corresponding setting in the company code table is also effective for Contract Accounts Receivable and Payable. In addition, in Contract Accounts Receivable and Payable, the document type decides whether a posting is to be posted negatively. You can designate a document type such that negative postings are always created, or such that negative postings are only created for corrections in the same fiscal year. For more information about the setting for the document type, see the Customizing for the document types and the field documentation for the field Negative Posting. A description of negative postings for the most important business transaction follows: •
Reversal – – – –
•
For a reversal, the document type used decides: Whether a negative posting is never permitted Whether a negative posting is always permitted That a negative posting is created if the posting and reversal are in the same fiscal year – A special feature is that the items in the reversal document for which the account to be posted to has been swapped in comparison to the original document are not posted negatively. This can be the case for aperiodic reversals (swap of P&L accounts) or for posting incoming payments where the reversal is used to post back to the clarification account. Resetting Clearing –
•
After resetting clearing, all accounts should appear as if the clearing had not taken place. This means that the inverse posting of cash discount, small differences, exchange rate differences, and taxes that were posted due to the clearing are to be posted negatively. The display in the receivables accounts is retained. – Example – You reset clearing for a payment received. After the clearing reset, the payment with clearing of open items becomes a type of payment on account again, which means that the credit from the payment is an open item in the receivables account. From the view of the account balance in the receivables account, it is irrelevant whether there was a payment on account or whether items were cleared. Returns –
2006/Q2
Returns should be treated like reversals. The first item in a returns clearing account is, however, never posted negatively; the same applies to returns charges.
© 2006 SAP AG. All rights reserved.
449
Unit 11: Other Business Transactions
–
–
IUT240
Individual Identification of Individual Posting Items If you want to post a document for which negative postings are required for all items manually, all you have to do is select an appropriate document type. However, if you only want to post individual items negatively, you have to enter the entire transaction in two documents. Example Transfer posting from an incorrect G/L account to the correct G/L account. The reset in the incorrect G/L account should be posted negatively, the posting to the correct account not. First enter a negative posting: Clearing account to incorrect G/L account. Then a “normal” posting: Correct G/L account to clearing account.
•
Payments on Account If, on receipt of payment, you first post on account instead of clearing immediately and then carry out clearing later, (for example, via account maintenance or during processing of a subsequent payment), the debit and credit side of the receivables account increases by the amount of the payment on account. If you want to avoid this effect, make sure that every clearing of a posting on account is posted negatively. To do this, you have to indicate in Customizing for the main and subtransaction used for payments on account that each clearing of this item is to be posted negatively.
You make the setting for the company code (negative postings possible) in the Implementation Guide for Financial Accounting under Financial Accounting Global Settings → Company Code → Check and Supplement Global Parameters. You make the setting for the document type in the Implementation Guide for Contract Accounts Receivable and Payable under Basic Functions → Postings and Documents → Document → Maintain Document Account Assignments → Document Types → Maintain Document Types and Assign Number Ranges. The main and subtransactions that you want to define for a negative clearing (example: Payments on Account) are in the Implementation Guide for Contract Accounts Receivable and Payable under Basic Functions → Postings and Documents → Document → Maintain Document Account Assignments → Maintain Subtransactions.
450
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Reversing Documents and Resetting Clearing
Figure 307: Negative Postings: Example
Figure 308: Negative Postings: Payment on Account
2006/Q2
© 2006 SAP AG. All rights reserved.
451
Unit 11: Other Business Transactions
IUT240
Figure 309: Clearing Reset
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: • • • • • • •
452
Business partner Contract account Contract Company code Business area Division Collective bill number
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Reversing Documents and Resetting Clearing
Figure 310: Reverse / Reset Clearing: Customizing
2006/Q2
© 2006 SAP AG. All rights reserved.
453
Unit 11: Other Business Transactions
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
454
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Reversing Documents and Resetting Clearing
Lesson Summary You should now be able to: • Explain the principles involved in reversing documents and resetting clearing in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
455
Unit 11: Other Business Transactions
Lesson: 427
IUT240
Document Transfer Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Transfer a document in Contract Accounts Receivable and Payable.
Business Example
Figure 311: Document Transfer
456
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Transfer
You can only transfer open receivables or credits. You can transfer the following: • • • • •
•
Individual items - receivables and credit All items of a business partner All items of a contract account All items of a contract Items that are still contained in an installment plan. Existing installment plans are automatically deactivated and a new installment plan is created for the amount of the source receivable(s) still open. Items that belong to a collective bill. The collective bill is automatically updated.
The transfer posting document can be reversed. When transfer posting a customer account, you can allocate documents that already refer to contracts (account assignment) to a target contract account without having to specify a target contract. In doing so the transfer posting document is not longer assigned to a contract. Contracts should not already be allocated to the target contract account.
Figure 312: Transfers - Customizing
2006/Q2
© 2006 SAP AG. All rights reserved.
457
Unit 11: Other Business Transactions
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
458
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Document Transfer
Lesson Summary You should now be able to: • Transfer a document in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
459
Unit 11: Other Business Transactions
Lesson: 430
IUT240
Mark as Doubtful / Individual Value Adjustment Lesson Duration: 20 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the procedures and postings for doubtful postings and value adjustment of open items.
Business Example
Figure 313: Mark as Doubtful / Individual Value Adjustment
460
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Mark as Doubtful / Individual Value Adjustment
Figure 314: Mark as Doubtful/Individual Value Adjustment: Posting
Posting records: 1. 2. 3. 4. 5.
Bill creation Post incoming payment in general ledger accounting (bank statement) Post payment in sub-ledger accounting and allocate the payment Mark the receivable as doubtful 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
461
Unit 11: Other Business Transactions
IUT240
Figure 315: Mark as Doubtful/Individual Value Adjustment: Customizing
Exceptions for Adjustment: In this activity you define, for each application area, the main and subtransactions that create postings that you want to exclude from a doubtful entry or value adjustment. You can define the scope of the exception as follows: • • •
Manual doubtful entry or value adjustment Automatic doubtful entry or value adjustment Manual and automatic doubtful entry or value adjustment
User Exits: In this activity you can define methods to be used for making value adjustments for the items. You can enter the method on the initial screen for the Adjust receivables according to age mass activity. You must define the special features for the methods in event 2950. In this event you can implement customer-specific checks as well as value adjustment methods.
462
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Mark as Doubtful / Individual Value Adjustment
Facilitated Discussion Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
463
Unit 11: Other Business Transactions
IUT240
Lesson Summary You should now be able to: • Explain the procedures and postings for doubtful postings and value adjustment of open items.
464
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 434
Lesson: Write Off
Write Off Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Write off uncollectible receivables in Contract Accounts Receivable and Payable.
Business Example
Figure 316: Manual Write Off: Process
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
2006/Q2
© 2006 SAP AG. All rights reserved.
465
Unit 11: Other Business Transactions
IUT240
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.
Figure 317: Write Off: Posting 1
Posting records: 1. 2. 3. 4.
466
Bill creation Post incoming payment in general ledger accounting Post payment in sub-ledger accounting and allocate the payment Write off the open item
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Write Off
Figure 318: Write Off: Posting 2
Posting records: 1. 2. 3. 4. 5.
Bill creation Post incoming payment in general ledger accounting (bank statement) Post payment in sub-ledger accounting and allocate the payment Mark the receivable as doubtful Individual value adjustment Steps 4 and 5 generate FI-CA documents that are only relevant for General Ledger Accounting. This means that they do not have any business partner items.
6. 7. 8.
2006/Q2
Write off the open item Reset doubtful entry Reset IVA
© 2006 SAP AG. All rights reserved.
467
Unit 11: Other Business Transactions
IUT240
Figure 319: Write-Off History
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.
Figure 320: Write Off: Customizing
You should only enter an execution variant if the event 5015 has been defined.
468
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
439
Lesson: Write Off
Exercise 18: Manual Write Off Exercise Duration: 15 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Write off receivables that cannot be collected.
Business Example The remaining receivables for the business partner have to be written off later.
Task: Writing off receivables 1.
Once account maintenance has been executed, you determine that another receivable from business partner PICA1210## (PI1201C0##) cannot be collected. Use the following information: Business partner:
PICA1210## (PI1201C0##)
Contract account:
PICA1210## (PI1201C0##)
Posting date:
Today’s date
Currency:
EUR (USD)
Clearing reason:
04
Write-off reason:
04 “Uncollectible”
Write off the receivable. Write down the document number of the write-off document: ______________________________________________ 2.
2006/Q2
Check the write-off in the account display and navigate to the write-off history.
© 2006 SAP AG. All rights reserved.
469
Unit 11: Other Business Transactions
IUT240
Solution 18: Manual Write Off Task: Writing off receivables 1.
Once account maintenance has been executed, you determine that another receivable from business partner PICA1210## (PI1201C0##) cannot be collected. Use the following information: Business partner:
PICA1210## (PI1201C0##)
Contract account:
PICA1210## (PI1201C0##)
Posting date:
Today’s date
Currency:
EUR (USD)
Clearing reason:
04
Write-off reason:
04 “Uncollectible”
Write off the receivable. Write down the document number of the write-off document: ______________________________________________ a)
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 “Uncollectible” ....... Choosing 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. Choose Save to execute the write-off.
Continued on next page
470
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Write Off
2.
Check the write-off in the account display and navigate to the write-off history. a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Account Balance with a list variant that also displays cleared items. Choose 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 choose Execute to start the analysis.
2006/Q2
© 2006 SAP AG. All rights reserved.
471
Unit 11: Other Business Transactions
IUT240
Lesson Summary You should now be able to: • Write off uncollectible receivables in Contract Accounts Receivable and Payable.
472
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Explain account maintenance in Contract Accounts Receivable and Payable. • Explain the principles involved in reversing documents and resetting clearing in Contract Accounts Receivable and Payable. • Transfer a document in Contract Accounts Receivable and Payable. • Explain the procedures and postings for doubtful postings and value adjustment of open items. • Write off uncollectible receivables in Contract Accounts Receivable and Payable.
2006/Q2
© 2006 SAP AG. All rights reserved.
473
Unit Summary
474
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 12 Security Deposits
445
Unit Overview This unit will provide you with an overview of: • • •
The request for cash and non-cash security deposits Non-cash security deposits The request, payment and settlement of cash security deposits
Unit Objectives After completing this unit, you will be able to: • •
Explain how cash and non-cash security deposits are processed in Contract Accounts Receivable and Payable. Request and settle cash security deposits.
Unit Contents Lesson: Cash and Non-Cash Security Deposits............................476 Lesson: Request, Payment and Settlement of Cash Security Deposits .481 Exercise 19: Processing Cash Security Deposits ......................491
2006/Q2
© 2006 SAP AG. All rights reserved.
475
Unit 12: Security Deposits
Lesson: 446
IUT240
Cash and Non-Cash Security Deposits Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain how cash and non-cash security deposits are processed in Contract Accounts Receivable and Payable.
Business Example You assess the credit rating of your business partner such, that you agree on cash security deposits for this business partner. • •
476
A request for cash security deposit is created for the business partner in the system. After the incoming payment, the request for cash security deposit is cleared and accounted for as a down payment.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash and Non-Cash Security Deposits
Figure 321: Security Deposits
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
477
Unit 12: Security Deposits
IUT240
Figure 322: Cash security deposits
In IS-U, a cash security deposit is cleared with the final bill. Otherwise, cash security deposits can be paid 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. Non-cash security deposits can be returned or cashed. Interest must be calculated for cash security deposits.
478
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash and Non-Cash Security Deposits
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
479
Unit 12: Security Deposits
IUT240
Lesson Summary You should now be able to: • Explain how cash and non-cash security deposits are processed in Contract Accounts Receivable and Payable.
480
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 449
Lesson: Request, Payment and Settlement of Cash Security Deposits
Request, Payment and Settlement of Cash Security Deposits Lesson Duration: 40 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Request and settle cash security deposits.
Business Example
Figure 323: Request Cash Security Deposit
2006/Q2
© 2006 SAP AG. All rights reserved.
481
Unit 12: Security Deposits
IUT240
SAP Menu: Account → Security Deposit → Create 1.
The cash security deposit is created either manually or automatically in the Utilities Industry component when a move-in is entered in the system. The cash security deposit has the status Requested. A request document is a statistical document with a document header and a line item Using the function module FKK_EVENT_0820_PAYMFORM_DET, you can create a payment form number automatically when you create a cash security deposit request.
2. 3.
4. 5.
As long as the request document has not yet been cleared, you can reverse the security deposit. A deposit that has been reversed cannot be used again. If you receive a (partial) cash security deposit payment and this clears the request document either completely or partially, the status changes to (Partially) Paid. When the valid for date is reached, or when an early manual release occurs, the status changes to Released. If the cash security deposit payment is cleared by repayment or settlement against open receivables, the end status Returned is reached. In the menu under Periodic Processing → For Contract Accounts → Security Deposits → Release, you can use the report RFKK_SECURITY_RELEASE to release the securities.
1.
Non-cash security deposits are created manually. When you save the security deposit, the status Requested is given. Further processing is triggered by changing the status. For non-cash deposits, you can define the status in Customizing. For each change of status, a BOR event is triggered; this can start a workflow, whereby you have to model your own workflows.
2.
2.You can display an overview of all security deposits. To do this, choose one of the following paths: Roles: Cash Security Deposits/Security Deposits (SAP_FI_CA_CASH_DEPOSIT) → Security Deposit Statistics Report SAP Menu: Periodic Processing → For Contract Accounts → Security Deposits → Statistics You can select using the following criteria: Start date Return date Cash security deposits Non-cash security deposits Status of security deposits in the case of non-cash security deposits
482
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Request, Payment and Settlement of Cash Security Deposits
For event 0860, you can define follow-on actions for security deposits that meet certain criteria. For example, that a clerk retrieves a non-cash security deposit from storage if the return date is reached within the next week.
Figure 324: Process Security Deposit
SAP menu: Account → Security Deposit → Display or Change Enter the number of the security deposit required and select Continue. The following table lists the functions available when changing or displaying a security deposit. Functions with Display and Change
Menu path
Important information
Print notification
Environment → Form Printing
A request form is printed as sample
Edit → Reverse
A deposit that has been reversed cannot be used again.
Functions only with Change Reverse
2006/Q2
© 2006 SAP AG. All rights reserved.
483
Unit 12: Security Deposits
484
IUT240
Functions with Display and Change
Menu path
Important information
Release cash deposit
Edit → Release
The clearing restriction of the cash security deposit payment is removed. This means that the payment can now be cleared.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
2006/Q2
Lesson: Request, Payment and Settlement of Cash Security Deposits
Functions with Display and Change
Menu path
Release cash security deposit in part
Edit → Release Partially You can offset the released portion or pay it out if a payment method is defined in the partial release. Prerequisite for partial release:The status must be either Paid or Released Partially.
Change amount of cash security
Edit → Clear Remaining You can subsequently Receivable → Clear New reduce the amount of the Receivable cash security deposit receivable deposit using the Remaining Receivable function, or increase it using the New Receivable function. In the case of the New Receivable, part of the original receivable is written off, in the second case a new cash security deposit receivable is posted with reference to an existing cash security, provided that this has not been reversed or released. The Clear Remaining Receivable function refers to all cash security requests in the contract that are still open. A release means that all security deposits are released.
Post new receivable
Edit → New Receivable
© 2006 SAP AG. All rights reserved.
Important information
Instead of creating a new security deposit, you can post a new receivable. You can define the same amount of information (such as request reason) as is the case when creating a new security deposit.
485
Unit 12: Security Deposits
IUT240
Activities If you want to automatically release and create cash security deposits when the payment method in the contract account changes, define an installation-specific function module for event 1025 in the Implementation Guide for Contract Accounts Receivable and Payable under Program Enhancements → Define Customer-Specific Function Modules. To do this, copy the function module FKK_EVENT_1025_DEPOSIT_CHANGE and adjust the copy to meet your requirements, for example, the amount of the cash security deposit requested, the currency, the request reason, and the reversal reason. Example If a direct payer changes his payment method to bank collection, all of the cash security deposits in the contract account of the business partner are released automatically, since there is no longer any reason to retain the security deposit. However, if a business partner who has previously paid his receivables by bank collection becomes a direct payer, you can automatically request a cash security deposit.
Figure 325: Release Security Deposit
486
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Request, Payment and Settlement of Cash Security Deposits
Figure 326: Security Deposits: Posting (1)
[1] Posting the request for the cash security deposit in FI-CA: • •
The cash security deposit is posted statistically so that no transaction relevant to the general ledger is generated. A notification containing the requested amount, the terms and methods of payment, etc. can be generated.
Figure 327: Security Deposits: Posting (2)
[2] Posting incoming payment in FI. The business partner pays by bank transfer.
2006/Q2
© 2006 SAP AG. All rights reserved.
487
Unit 12: Security Deposits
IUT240
Figure 328: Security Deposits: Posting (3)
[3] Allocation of the payment in FI-CA and FI. When payment is allocated to the request for the cash security deposit, credit corresponding to the payment amount is posted. The statistical request is cleared.
Figure 329: Security Deposits: Posting (4)
[4] Posting an IS-U 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 66,-.
488
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Request, Payment and Settlement of Cash Security Deposits
Figure 330: Interest for Cash Security Deposits
The way in which the interest key for a cash security payment is determined differs to the standard way of calculating interest on items: • •
If an interest key is specified in a payment, this is the one that applies. If no interest key is specified in a payment, the system tries to determine a key from the relevant security deposit. If no interest key can be found, no interest calculation takes place.
An interest lock at the level of contract account-dependent data is not considered during the calculation of interest on cash security deposits. To calculate interest on individual cash security deposit payments, choose one of the following paths: • •
SAP menu: Account → Security Deposit → Interest CalculationThe procedure is similar to posting debit and credit interest. SAP Menu: Periodic Processing → Security Deposits → Calculation of Interest on Cash Security Deposits
You can display cash security deposit interest that has been posted in the security deposit maintenance. In the menu under Environment → Interest Calculation List, you can display an overview for the interest run.
2006/Q2
© 2006 SAP AG. All rights reserved.
489
Unit 12: Security Deposits
IUT240
Figure 331: Security Deposits: Customizing
490
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
459
Lesson: Request, Payment and Settlement of Cash Security Deposits
Exercise 19: Processing Cash Security Deposits Exercise Duration: 15 Minutes
Exercise Objectives After completing this exercise, you will be able to: • Create and further process a cash security deposit.
Business Example 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.
Task: Security Deposits Creating a cash security deposit. 1.
Create a cash security deposit request. Use the following information: Contract account:
PICA1310## (PI1301C0##)
Type of security deposit:
Cash Security Deposit
Reasons for request
Payment history
Requested amount:
EUR (USD)
Start date:
01.04.2006
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:__________ Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
491
Unit 12: Security Deposits
2.
IUT240
Now pay the cash security deposit request at the cash desk. Use the following information: Amount:
500.00 EUR (USD)
Company code:
U100 (U300)
Bank clearing account:
113100
Value date:
02.04.2006
Posting date:
02.04.2006
Document date:
02.04.2006
Select the “Post Online” variant, deactivate the bill receivables 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? 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?
492
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Request, Payment and Settlement of Cash Security Deposits
Solution 19: Processing Cash Security Deposits Task: Security Deposits Creating a cash security deposit. 1.
Create a cash security deposit request. Use the following information: Contract account:
PICA1310## (PI1301C0##)
Type of security deposit:
Cash Security Deposit
Reasons for request
Payment history
Requested amount:
EUR (USD)
Start date:
01.04.2006
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:__________ a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Security Deposit → Enter. Choose Type of security deposit: Cash security deposit Confirm with Enter. Fill in the fields according to the information described and save your entries.
2.
Now pay the cash security deposit request at the cash desk. Use the following information:
Continued on next page
2006/Q2
© 2006 SAP AG. All rights reserved.
493
Unit 12: Security Deposits
IUT240
Amount:
500.00 EUR (USD)
Company code:
U100 (U300)
Bank clearing account:
113100
Value date:
02.04.2006
Posting date:
02.04.2006
Document date:
02.04.2006
Select the “Post Online” variant, deactivate the bill receivables 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? a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Payments → Cash Journal → Cash Journal and then choose To Cash Desk. Enter the data specified in the task for the payment. Select Post Online, deactivate the bill receivables 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: Not Clearing Permitted”.
3.
Release the security deposit payment. What happens to the security deposit payment?
Continued on next page
494
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Request, Payment and Settlement of Cash Security Deposits
Clear the security deposit payment with open receivables. What is the status of the security deposit now? a)
Choose: Utilities Industry → Contract Accounts Receivable and Payable → Account → Security Deposit → 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 clearing restriction was removed from the security payment document. 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
495
Unit 12: Security Deposits
IUT240
Lesson Summary You should now be able to: • Request and settle cash security deposits.
496
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Explain how cash and non-cash security deposits are processed in Contract Accounts Receivable and Payable. • Request and settle cash security deposits.
2006/Q2
© 2006 SAP AG. All rights reserved.
497
Unit Summary
498
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 13 Correspondence
467
Unit Overview
Unit Objectives After completing this unit, you will be able to: • • •
Define and explain the different types of correspondence in Contract Accounts Receivable and Payable Configure and handle correspondence. Explain the principles of the print workbench.
Unit Contents Lesson: Definition and Types .................................................500 Lesson: Handling and Customizing ..........................................508 Lesson: The Print Workbench.................................................518
2006/Q2
© 2006 SAP AG. All rights reserved.
499
Unit 13: Correspondence
Lesson: 468
IUT240
Definition and Types Lesson Duration: 15 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Define and explain the different types of correspondence in Contract Accounts Receivable and Payable
Business Example Your company wishes to create account statements and other correspondence in Contract Accounts Receivable and Payable.
Figure 332: Correspondence: Definitions
500
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Definition and Types
Figure 333: Correspondence: Use
SAP provides several correspondence types, for example: • •
Business Partner Statement = All open items that were posted after the last business partner statement (event 1913) Account Information = All items for a certain contract account
Use business partner statements if for example: •
•
Several contract accounts exist for a business partner and you only want to use one correspondence to inform your business partner of the status of the account relationship. Several contracts exist for one business partner and you only want to use one correspondence to inform the business partner of the status of the customer relationship.
Use balance notifications if for example: • •
2006/Q2
External auditors want to inform a group of customers about the current status of their customer accounts. Customers must be informed about the account balance once in each period (requirement in specific countries).
© 2006 SAP AG. All rights reserved.
501
Unit 13: Correspondence
IUT240
Figure 334: Correspondence Types (1 of 2)
The account statement is a correspondence type whose output cannot be influenced by user selections. For example, if the user requests an account statement for contract account ABC then he will receive output that consists of all of the items that have been posted against this account (you cannot specify any limiting search criteria when viewing this type of correspondence). The account information contains exactly those items that were selected in the account balance display (transaction FLP9). The bill processing function is used to inform business partners of receivables for which you are responsible and to send them printed payment requests. The business partner then pays for the open items listed. Bill processing is a mass activity fully integrated in the Correspondence component. A bill groups all open items into a payment amount. The bill with this amount is then sent to the customer. Depending on your customizing settings, the notification sent to the customer is a printed bill with (or without) an attached payment document.
502
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Definition and Types
Figure 335: Correspondence Types (2 of 2)
You can define your own correspondence types. You can now set the application form that you want to use for all individual correspondence.
Figure 336: Bill Creation (IS-PS-CA)
The system uses the payment program to determine which items should be included in bill processing.
2006/Q2
© 2006 SAP AG. All rights reserved.
503
Unit 13: Correspondence
IUT240
The system checks whether you have maintained an incoming payment method. If you have, this allows you to initiate payment yourself and you need not bill your business partner. If not, then the system will include the open items in the billing run. The basic steps are as follows: • • • • • •
Those open items that have not been printed on a bill are selected Open items are grouped and the bill type is determined (from the master data) No bill is created if a lock is active A unique bill number (payment form number) is created The open items are saved under this number A correspondence header is stored
Depending on what is stored in the master data, different bill types can be printed. The bill type determines the items to be printed and what the bill looks like. Additional texts should be added to the bill at the time of printing (PSCD Print Workbench) by an exit in the application form. You can define whether the mass activity for creating bills only groups together items for bills that have no incoming payment method (as was the case until now), or whether all items, irrespective of their payment method, are included (event 0600, FMCA_INV_ALL_ITEMS_0600).
Figure 337: Correspondence Type Configuration
Recipient control is set at the level of correspondence type. For example, you can specify for a given correspondence type that no alternative recipient is allowed.
504
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Definition and Types
There are two necessary events associated with a correspondence type. The first is a “print” event (function module that is needed to print a correspondence request for a given correspondence type after the correspondence container has been read). The other is a “generation” event (function module needed to create or generate a correspondence request). The other settings control which application area can use a given correspondence type and/or if the correspondence type event is periodic, and so on.
2006/Q2
© 2006 SAP AG. All rights reserved.
505
Unit 13: Correspondence
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
506
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Definition and Types
Lesson Summary You should now be able to: • Define and explain the different types of correspondence in Contract Accounts Receivable and Payable
2006/Q2
© 2006 SAP AG. All rights reserved.
507
Unit 13: Correspondence
Lesson: 475
IUT240
Handling and Customizing Lesson Duration: 25 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Configure and handle correspondence.
Business Example
Figure 338: Underlying Concept
The correspondence “data container” is a set of tables (technical tip: the main one is DFKKCOH); each entry within this table represents an object that can be sent to a business partner.
508
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Handling and Customizing
The printing run is done in a separate step within the menu “correspondence”. From the correspondence data container, you can select any data that you wish to print. It is recommended that printing be carried out not too long after correspondence is generated. For example, if there is a significant delay in the printing of the generated dunning notices, customers may be dunned who have paid their balances in the meantime.
Figure 339: Handling Correspondence Data
Correspondence data is stored in an abstract manner. Key data from dunning, returns, account statements etc., are all stored in the same location. In general, the data container references additional data that resides in the originating program.
2006/Q2
© 2006 SAP AG. All rights reserved.
509
Unit 13: Correspondence
IUT240
Figure 340: Additional Features of Correspondence
Correspondence History: Stores information about all correspondence, including inbound correspondence. History features – Archiving of correspondence; pixel viewer for letters. The pixel viewer is a viewing tool similar to Acrobat Reader used to read optically archived documents. Introduction of additional print options such as “shipping control”. In shipping control you define the underlying options for shipping. Shipping control is primarily used by the correspondence variants. The correspondence variant summarizes correspondence type in order to control periodic correspondence and can be assigned to contract accounts at contract account and business partner level.
510
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Handling and Customizing
Figure 341: Correspondence Control
If an entry exists in the “Correspondence Recipient” field then this business partner will replace the original recipient in all cases except if any specific correspondence types are defined to go elsewhere (for example, recipients for individual correspondence types). If the “Alternate or Additional Correspondence Recipient” flag specifies whether a correspondence recipient is acting as substitute for the original recipient. If this flag is not selected, then any partners listed will receive a copy of the correspondence. If the flag is selected, only the alternative correspondence recipient receives a copy. The correspondence is not sent to the actual business partner.
2006/Q2
© 2006 SAP AG. All rights reserved.
511
Unit 13: Correspondence
IUT240
Figure 342: Correspondence Output Options
You select the print setting via the appropriate indicator in print dialog. There are five possible settings: • • • • •
* SAPscript Formu settings are essential X Raw data interface (output mode: spool) I Raw data interface (output mode: IDoc) S Raw data interface (output mode: spool (simple RDI)) - Formatting by SAPscript (OTF)
Raw data is sent to the print workbench and processed there, instead of creating separate forms in each program.
512
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Handling and Customizing
Figure 343: Creation of Correspondence: Overview
General steps for creation of correspondence: • • • •
2006/Q2
Correspondence requests are created using business transactions or correspondence runs. Reference data is stored in the correspondence container. Select the correspondence data from the correspondence container and prepare the data for print out via a correspondence print run. Print out of correspondence data via SapScript, print-workbench, or use the raw data interface to print via an external printing system.
© 2006 SAP AG. All rights reserved.
513
Unit 13: Correspondence
IUT240
Figure 344: Customizing of Correspondence Variants
(Correspondence) charge schedules are charges that can be set per correspondence type. For example, if you wanted to charge your customer a small fee for re-invoicing you would configure a charge schedule and then enter it in the correspondence variant. Dispatch Control is used to send a document, such as an invoice or dunning notice, in different forms and in multiple copies (for instance by email or fax). Customizing of dispatch control is performed in the “print workbench” area of the IMG (General Application Functions>Print Workbench>Shipping Control). You can assign correspondence variants to contract accounts and/or contract objects. The control parameters defined in a correspondence variant are evaluated when the correspondence is created. All “periodic” correspondence (for example, type 0002 – account statement) must be defined in the correspondence variant.
514
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Handling and Customizing
Figure 345: Correspondence: Customizing
2006/Q2
© 2006 SAP AG. All rights reserved.
515
Unit 13: Correspondence
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
516
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Handling and Customizing
Lesson Summary You should now be able to: • Configure and handle correspondence.
2006/Q2
© 2006 SAP AG. All rights reserved.
517
Unit 13: Correspondence
Lesson: 483
IUT240
The Print Workbench Lesson Duration: 20 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the principles of the print workbench.
Business Example
518
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: The Print Workbench
Figure 346: The Print Workbench
The print workbench is not a replacement for SAPscript/Smart Forms. It is simply a tool enabling you to work with SAPscript/ Smart Forms and PDF-based forms more easily. The print workbench offers an improved means of creating of forms. In addition, it makes data retrieval flexible and easy to understand. The print workbench separates data retrieval from the layout design of a form and makes creating and maintaining forms easier. You can find more details about the Print Workbench in the documentation for SAP component CA-GTF-PWB.
2006/Q2
© 2006 SAP AG. All rights reserved.
519
Unit 13: Correspondence
IUT240
Figure 347: Overview
The form class library is created by an SAP developer and represents a “super-set” of data that is available for use in an application form. It is also an ABAP program and its coding is copied to the print program when generated. In the application form you define the sequence of text modules. The business partner determines what data is printed on a specific piece of correspondence. The SAPscript/Smart Form is an independent object. It is used to define where and how data defined in the application form is to be printed.
520
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: The Print Workbench
Figure 348: The Form Class
Form classes form the basis for all forms of the print workbench. The form classes are updated every time the system is updated by SAP.
Figure 349: The Application Form
2006/Q2
© 2006 SAP AG. All rights reserved.
521
Unit 13: Correspondence
IUT240
In the print workbench, in addition to SAPscript, you can also use Smart Forms to create and maintain application forms. The previous use of SAPscript is not affected by this function enhancement. Smart Forms have the following advantages over SAPscript: • • • • • • •
More flexible creation of form layout (for example, with tables and templates) More efficient creation and maintenance of forms (reduces the time by half) Form adjustment without programming knowledge as a result of completely graphical user interface Web publishing using a generated XML output Performance improvement Clear separation between data selection, form preparation, and form logic XML-based SAP standard interfaces (XSF, XDF) for external further processing
As of release ERP 2005 the print workbench supports the use of PDF-based forms for creating and issuing outgoing standardized correspondence. SAP therefore provides the new form category PDF-based form for application forms. You can use the new XML-based raw data interface (XFP) for PDF-based forms to prepare raw data outside of the SAP system. Existing implementations in SAPscript and Smart Forms are not affected by this change.
522
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: The Print Workbench
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
523
Unit 13: Correspondence
IUT240
Lesson Summary You should now be able to: • Explain the principles of the print workbench.
524
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • Define and explain the different types of correspondence in Contract Accounts Receivable and Payable • Configure and handle correspondence. • Explain the principles of the print workbench.
2006/Q2
© 2006 SAP AG. All rights reserved.
525
Unit Summary
526
IUT240
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 14 Further Integration of FI-CA in SAP Modules
489
Unit Overview Unit Objectives After completing this unit, you will be able to: • • • • • • • • •
• •
2006/Q2
Explain the integration of Contract Accounts Receivable and Payable with other SAP components and applications. Explain the Funds Management update logic in FI-CA Explain the accounting derivation in Funds Management Allocate business partners to debtors and vendors Explain the connection between Funds Management and FI-CA Describe the update of the financial status from Contract Accounts Receivable and Payable Explain the connection of SD orders in Contract Accounts Receivable and Payable Explain the derivation of segments for the new G/L accounting in Contract Accounts Receivables and Payables. Explain the main features of risk-based customer segmentation and credit monitoring with SAP Credit Management and its integration with Contract Accounts Receivable and Payable. To explain the main features of financial customer services in the IC WebClient based Financial Customer Care. Explain the FI-CA Content for Business Intelligence.
© 2006 SAP AG. All rights reserved.
527
Unit 14: Further Integration of FI-CA in SAP Modules
•
IUT240
Explain the outbound interface for postings in Contract Accounts Receivable and Payable
Unit Contents Lesson: Integration of Contract Accounts Receivable and Payable: Overview .........................................................................529 Lesson: Funds Management ..................................................533 Lesson: Cash Management ...................................................544 Lesson: Contract Accounts Receivable and Payable and SD Integration........................................................................549 Lesson: Integration of New G/L (Segment Reporting) .....................558 Lesson: Credit Management ..................................................563 Lesson: Financial Customer Care ............................................571 Lesson: Business Intelligence.................................................578 Lesson: Outbound Interface ...................................................583
528
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 491
Lesson: Integration of Contract Accounts Receivable and Payable: Overview
Integration of Contract Accounts Receivable and Payable: Overview Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the integration of Contract Accounts Receivable and Payable with other SAP components and applications.
Business Example
Figure 350: Integration - Overview
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
529
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
You can use a standardized IDoc interface to import billing documents from external billing systems into FI-CA, and to process them there. Invoicing in FI-CA enables the transfer of billing documents from external systems and their invoicing and posting into FI-CA. 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 objects. The CO-PA component is supplied with the necessary information from the invoicing applications for different update types. This information is transferred regularly using transfer reports, which are triggered in FI-CA. 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. The Credit Management component provides the option of risk-based customer segmentation and credit risk management. 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 Financial Customer Care.
530
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration of Contract Accounts Receivable and Payable: Overview
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
531
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Lesson Summary You should now be able to: • Explain the integration of Contract Accounts Receivable and Payable with other SAP components and applications.
532
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 494
Lesson: Funds Management
Funds Management Lesson Duration: 10 Minutes
Lesson Overview At the conclusion of this lesson you will know the update logic of FI-CA. You will also be able to explain how the accounting derivation takes place in Funds Management, how business partners are assigned to the debtors and vendors, as well as the connection between PSM and FI-CA.
Lesson Objectives After completing this lesson, you will be able to: • • • •
Explain the Funds Management update logic in FI-CA Explain the accounting derivation in Funds Management Allocate business partners to debtors and vendors Explain the connection between Funds Management and FI-CA
Business Example Some companies and organizations use Funds Management for budgetary control and financial reporting. All postings are automatically updated in Funds Management in order to: • •
Fulfill legal reporting requirements Increase the expenditure budget by the revenues budget
In addition, your company wants to use the Budget Availability Control in PSM.
2006/Q2
© 2006 SAP AG. All rights reserved.
533
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Funds Management Integration
Figure 351: Funds Management Integration: Structure in FM
You can activate Funds Management by activating the FICA_FM switch (FI-CA Core, Funds Management). The FM table fields are then activated automatically by the structures SI_FKKFMOP and SI_FKKFMOPK. These structures replace the customer includes CI_FKKFMOP and CI_FKKFMOPK. Note that even if you already use FI-CA integrated with Funds Management, when you upgrade to Release ERP 2005, the FICA_FM switch (FI-CA Core, Funds Management) is activated. This causes activation errors during the upgrade, since the FM table fields are inserted again and are therefore duplicated. You have to delete the duplicates from the customer includes CI_FKKFMOP and CI_FKKFMOPK after the upgrade. Proceed as described in SAP Note 834815.
534
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Funds Management
Figure 352: Funds Management Integration
You have to assign an FM account in the items. If you do not enter the FM account, it is automatically derived by the derivation tool (FMDERIVE) when you save your data as determined in Customizing. Each document is classified by a transaction class and is also assigned an FM type. This type determines whether or not an item is updated in Funds Management. The line items are summarized and transferred to the general ledger and to Funds Management by means of report RFKKGL00. The FM account assignment is one criteria for summarization. The business partner items and the G/L-partner items have to be balanced for each account assignment so that they can be posted in FI-CA. In order to activate Funds Management you have to activate a customer include for the Funds Management fields. Use the following menu path in Customizing: Financial Accounting → Contract Accounts Receivable and Payable → Integration → Funds Management (PSM-FM). Payment reconciliation with Funds Management can only be done for posted and transferred reconciliation keys. Restriction: Taxes can only be updated in the same commitment item as the revenue item (net update).
2006/Q2
© 2006 SAP AG. All rights reserved.
535
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 353: Funds Management Integration
Figure 354: FM Update Logic: Interpretation of Documents
FM account assignment and FM type are also stored in table DFKKSUM. When DFKKSUM is posted into FI, FM document lines are created from FM types. The transaction class is automatically determined from the business transaction and the G/L accounts used. The transaction class is stored in the document header.
536
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Funds Management
The FM type is interpreted for the update of the FM value type in Funds Management. For example, a line with FM value type (54) is created for a bill (A). The bill (54) is reduced in FM for a paid bill (B) and a payment line (57) is created. For FM type payment on account, only one payment line (57) is created for the customized default FM account.
Figure 355: Fiscal Year Change in FI-CA
Report “Transfer Open Items from FI-CA” (RFKKFMCF) carries over all open amounts in FM into the new fiscal year for each account assignment. The fiscal year change is not executed for each single document but the totals of each account assignment are transferred to the new fiscal year according to certain fields. The restriction takes place by the value types bill, down payment, and clarification worklist. The report can be used several times for a FM-account. Each execution creates a new carryover document. Activation of Funds Management Integration: Step 1 • •
2006/Q2
Activation of FM fields for document tables as defined in Customizing (DFKKOP, DFKKOPK). Allocation of the relevant commitment items (financial transaction 30,60,90) to the relevant G/L accounts.
© 2006 SAP AG. All rights reserved.
537
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Activation of Funds Management Integration: Step 2 •
The following derivation rules must be defined in FMDERIVE: – –
– – – –
Derivation of commitment item with financial transaction 60/2 for reconciliation accounts used within the FI-CA environment. Derivation of commitment item with financial transaction 30 for specific main and sub-transactions (for example, 0060/0600 Payments on Account). For main and subtransactions that represent payment transactions, the “Payment” indicator must be set for the main and subtransaction. Derivation of commitment item with financial transaction 90 for bank accounts and bank clearing accounts. Derivation of commitment item with financial transaction 50/3 for clarification accounts used within the clarification process. Also see note 686383 for more information.
Derivation Tool • •
Predefined derivation rules Derivation steps
Figure 356: Step types for derivation
538
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Funds Management
Figure 357: Assignment
Figure 358: Define Derivation Rules
2006/Q2
© 2006 SAP AG. All rights reserved.
539
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 359: Table Access
Figure 360: Derivation of FM Accounts
540
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Funds Management
Fund Accounting
Figure 361: Fund Accounting in FI-CA
Figure 362: Example Posting in FI-CA
Contract Accounts Receivable and Payable splits the FM account assignments into expenses and revenues as soon as Funds Management is activated.
2006/Q2
© 2006 SAP AG. All rights reserved.
541
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
542
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Funds Management
Lesson Summary You should now be able to: • Explain the Funds Management update logic in FI-CA • Explain the accounting derivation in Funds Management • Allocate business partners to debtors and vendors • Explain the connection between Funds Management and FI-CA
2006/Q2
© 2006 SAP AG. All rights reserved.
543
Unit 14: Further Integration of FI-CA in SAP Modules
Lesson: 504
IUT240
Cash Management Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Describe the update of the financial status from Contract Accounts Receivable and Payable
Business Example
Figure 363: Integration Treasury - Cash Management
This update is made directly when you post a document in FI-CA. This means that the Cash Management liquidity forecast and cash position are always up-to-date.
544
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Management
In the contract account master record you can define the following data for updating the liquidity forecast: •
Planning group This way contract accounts with collection authorization can be considered separately from contract accounts to be paid on demand. The system proposes the planning group when you enter a document.
•
Additional days These days are considered when determining the expected cash receipt date. The due date for net payment or the cash discount date is used as the baseline date for this.
You define a planning level in the G/L account master record for G/L accounts which require the cash position to be updated. The system determines the planning level when you post the document and enters it in the G/L item. For mass postings that run in parallel processes, waiting times may occur due to competing accesses during the update of Cash Management data. For these postings, FI-CA offers a parallel update mode that you can activate for specific types of mass runs in the IMG under Technical Settings → Activate Parallel Update of Cash Management. Cash Management is then updated at the end of each process. If the process is terminated before the Cash Management update, the update takes place when you close the relevant reconciliation key.
Figure 364: Treasury - Determination of Planning Level
2006/Q2
© 2006 SAP AG. All rights reserved.
545
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 365: Integration Controlling
546
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Cash Management
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
547
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Lesson Summary You should now be able to: • Describe the update of the financial status from Contract Accounts Receivable and Payable
548
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 508
Lesson: Contract Accounts Receivable and Payable and SD Integration
Contract Accounts Receivable and Payable and SD Integration Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the connection of SD orders in Contract Accounts Receivable and Payable
Business Example
Business Partner: SD Customer and BP in FI-CA •
• •
When you create a contract partner in FI-CA, it is possible to create an SD customer in the background at the same time. A standard customer can – Make use of services – Purchase goods A standard customer is created based on a predefined reference customer Different integration scenarios are possible: – –
2006/Q2
You can post SD invoices in FI-CA SD invoicing requests can be integrated in an IS-U bill
© 2006 SAP AG. All rights reserved.
549
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 366: FI/SD Integration: Standard Process
Figure 367: SD billing document
550
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Contract Accounts Receivable and Payable and SD Integration
Figure 368: What To Do To Use SD Integration
Transferring SD Billing Documents to FI-CA Prerequisites If you want to transfer SD bills to Contract Accounts Receivable and Payable, you must make various settings in the implementation guides for both Contract Accounts Receivable and Payable and Sales and Distribution (SD). You define for each account group whether a bill is to be transferred to Accounts Receivable Accounting (FI-AR) or to Contract Accounts Receivable and Payable (FI-CA). In the account group you define whether the related customers are to be transferred to FI-AR or FI-CA during SD billing. Prerequisites in Sales and Distribution The receivables accounts for Contract Accounts Receivable and Payable must be defined in the reconciliation account determination in Sales and Distribution (see IMG structure: Sales and Distribution → Basic Functions → Account Assignment/Costing → Reconciliation Account Determination). The customer master record must contain a reconciliation account for customers (in the FI-AR sense), even if you do not want to transfer to FI-AR. Due to the general checks during transfer, you have to enter a reconciliation account for customers (in the sense of FI-AR reconciliation accounts) in the company code relevant data for customers. When entering an SD order, you must select a contract account. This contract account must be assigned to the FI-CA business partner. If there is exactly one contract account for the payer, this is transferred automatically to the order. Prerequisites in Contract Accounts Receivable and Payable
2006/Q2
© 2006 SAP AG. All rights reserved.
551
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
When you create a business partner for the customer in Contract Accounts Receivable and Payable, you must specify an SD sample customer so that the SD views required for creating the order are available in the background. An SD customer is created whose customer number is identical to that of the FI-CA business partner. The transfer from SD to FI-CA is activated at the accounts receivable account group level. This means that for each account group, you define whether SD bills for these customers should be transferred to FI-AR or to FI-CA (see IMG structure: Contract Accounts Receivable and Payable → Integration → Sales and Distribution → Define Posting in FI-CA for Customer Account Groups). Note that when you create an order you can only enter customers from one of the two account groups as being the payer. This means only customers that trigger a posting in FI-AR during invoicing or customers that trigger a posting in FI-CA. Note that you are unable to activate the SD/FI-CA transfer for one-time account groups. The main and sub-transactions used in Contract Accounts Receivable and Payable are derived from the SD bills during transfer (see IMG structure: Contract Accounts Receivable and Payable → Integration → Sales and Distribution → Derive Main/Sub-Transaction With SD Information). The document type with which SD bills are posted in Contract Accounts Receivable and Payable is derived from the SD bills during transfer (see IMG structure: Contract Accounts Receivable and Payable → Integration → Sales and Distribution → Derive Document Type with SD Billing Doc Data). At event 4000 you can supplement the billing data (see IMG structure: Contract Accounts Receivable and Payable → Program Enhancements → Define Customer-Specific Function Modules). Features Automatic Reconciliation Key Determination The reconciliation key is determined automatically during transfer of SD bills. There is no difference between individual bills or mass runs. In both SD billing methods the reconciliation key is assigned according to the same procedure. Composition of reconciliation key: SDxxxxyyy_zz Part of Key Meaning XXX Current year YYY Current day in year ZZ
552
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Contract Accounts Receivable and Payable and SD Integration
Sequence number A new reconciliation key is given to SD bills for every day of the year. If this reconciliation key is closed during the course of the day or if two processes try to open the same reconciliation key simultaneously, a new or a second reconciliation key is opened with the next higher sequential number. Reconciliation keys generated this way are only permitted for posting SD bills. The reconciliation key is not closed automatically. Automatic Determination of Reconciliation Account The reconciliation account is determined automatically when SD bills are created for Contract Accounts Receivable and Payable. (See IMG structure: Sales and Distribution → Basic Functions → Account Assignment/Costing → Reconciliation Account Determination). Default Value for Payment Conditions In the SD order the default value for payment conditions is derived from event 4010 in Contract Accounts Receivable and Payable, provided that a corresponding function module has been defined at this event. If no function module has been defined or if no default value can be found, then the payment conditions are determined in the standard SD manner. For IS-U and IS-T a function module has been defined at event 4010 in Contract Accounts Receivable and Payable. This determines the default value for payment conditions from the contract account named in the order header. Depending on the order type, either the payment conditions for incoming payments or for outgoing payments are determined in accordance with the relevant payment conditions defined in the contract account. Contract Account in the Order In the SD order, the contract account field has been included as a new entry field for Contract Accounts Receivable and Payable. This field is in both the header and in the item section of the order. The SD business partner whose contract account is specified is the payer of the order. If there is exactly one contract account for the payer, this is transferred automatically to the order. If there is more than one contract account, a selection list appears when an order is created. You can define your own payer/contract account combination for each order item. The bills are then split for different contract accounts. The contract account from the accounting viewpoint is specified in the order header. From the accounting viewpoint, the following entry fields are not considered during transfer to Contract Accounts Receivable and Payable: Dunning Key Dunning Lock Payment Method Allocation
2006/Q2
© 2006 SAP AG. All rights reserved.
553
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
In event 4040, you can restrict the selection of contract accounts when you create/change an SD order. Business Area Determination In the SD order the default value for the business area is derived from event 4020 in Contract Accounts Receivable and Payable, provided that a corresponding function module has been defined at this event. If no function module has been defined or if no default value can be found there, then the business area is determined in the standard SD manner. For IS-U and IS-T a separate function module has been defined that determines the default value of the business area from the contract account specified in the order header. Restriction on Payment Conditions That Can Be Used In view of the payment control in Contract Accounts Receivable and Payable (due date for cash discount + discount% / due date for net payment), not all standard FI payment conditions can be used. The following restrictions apply: Only one cash discount date can be defined The second cash discount date is interpreted as being the net due date and must have 0.00 as the discount percent The payment conditions must be defined for the entire month and valid throughout this period No installment payment conditions are supported No support is given to the IS-U feature of including a factory calendar in conversion of payment conditions to the corresponding due dates A check is made to ensure that a payment condition is suitable for use with FI-CA. This check is made during assignment of the payment condition in the sales and distribution area data (customer billing) and also when the SD order is created. Reconciliation CO-PA and FI-GL Reconciliation between the individual components can only be made for closed posting periods and for points in time at which all Contract Accounts Receivable and Payable reconciliation keys have been transferred completely to the general ledger. Completing a Document The customer line items in the SD billing document transferred to the financial accounting interface are enriched with the following information: general information (for example, reference details) information from the contract account (for example, account determination ID) Information on main and sub-transactions for each company code and division (for example, dunning, interest, payment)
554
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Contract Accounts Receivable and Payable and SD Integration
The business partner item in Contract Accounts Receivable and Payable is created from the customer line item. Information is derived via event 4000, which is called to supplement customer items and G/L account items. The main and subtransactions of an SD document are determined in event 4030. In this event you have access to all of the information in an SD billing document, which means that a more detailed transaction determination is possible here in contrast to Customizing. Down Payment Requests/Down Payment Clearing You can use the functionality implemented in SD for creating down payment requests from billing plans as well as the subsequent down payment clearing for down payments made. Invoicing External Transactions You can use the function for invoicing external transactions. For this, the contract account must also be included in the communication structures. Reversing SD Bill Documents When reversed bills are transferred to accounting, the accounting documents arising out of this are flagged as reversed and the open items are cleared immediately. If this cannot be done, an accounting document is created that has a reversed +/- sign. This may happen, for example, if the bill has already been cleared or if the payment order has already been created. No Reversal of SD Bill in the Case of Subrogation If the customer changes and the receivables (open items) are transferred, the SD bill can no longer be reversed. The bill cannot be reversed as the open item(s) were cleared in Contract Accounts Receivable and Payable with reason 21 (subrogation). Display FI-CA Documents In the document flow for Sales and Distribution (SD), you can display FI-CA documents and archived FI-CA documents.
2006/Q2
© 2006 SAP AG. All rights reserved.
555
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
556
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Contract Accounts Receivable and Payable and SD Integration
Lesson Summary You should now be able to: • Explain the connection of SD orders in Contract Accounts Receivable and Payable
2006/Q2
© 2006 SAP AG. All rights reserved.
557
Unit 14: Further Integration of FI-CA in SAP Modules
Lesson: 516
IUT240
Integration of New G/L (Segment Reporting) Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the derivation of segments for the new G/L accounting in Contract Accounts Receivables and Payables.
Business Example
Figure 369: SAP Solutions in Financial Accounting
558
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration of New G/L (Segment Reporting)
As of ERP 2005, Contract Accounts Receivable and Payable (FI-CA) supports the following functions of the new general ledger accounting: •
Reporting by segment If a balance per segment is required, this takes place in the accounting interface.
•
Extensibility of new general ledger accounting The same restrictions and requirements apply as for the special purpose ledger.
the following functions are not supported: • •
Mapping of different accounting principles in parallel ledgers Balanced ledgers in all dimensions
Figure 370: Follow-On Posting to Previous Documents
For document line items that arise as follow-on postings to other document line items (for example, clearing, reversal, returns, interest calculation, write-off), the segment of the triggering item is handed down to the follow-on items if possible. This means that the segment of an open item is not only transferred to the clearing posting on clearing, it is also transferred to cash discount, payment surcharges, exchange rate differences, and interest on arrears that arise from the clearing of this item. If no unique inheritance is possible, for dunning or returns charges, if possible, the segment that has the highest proportion of relevant items (for example, dunned items, paid items for returns) is used.
2006/Q2
© 2006 SAP AG. All rights reserved.
559
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 371: No Follow-On Posting to Previous Documents
For documents that are not a follow-on posting to previous documents (typical example: New receivable), the account assignment Segment can be specified on manual entry and for transfer using one of the available interfaces. This specification has priority over the derivation options described below. Often, only the business partner items are entered or forwarded by means of posting interfaces. In this case, the document is completed in the system (for example, revenue and tax items are added). If a segment is already specified in the business partner items entered/transferred, this is transferred to the allocated revenue items. If no segment is assigned, one is derived as follows: •
•
•
•
560
The system derives the segment from other details of the business partner item(s). The determined segment is then handed down to the offsetting items (revenue items). The system derives the segment from the revenue items and inherits it to the business partner items. In this case, the derivation is made using the profit center. You must therefore assign a profit center in the revenue line item and assign a segment to this profit center in the master record. Derivation via Customizing without a profit center is only possible if the segment can be determined from the combination company code/general ledger account. The derivation of the segment is installation-specific using the new event 0081. Here you can use individual logic to determine a segment for each item for which the creator of the document has not assigned a segment. However, segments are ignored in bank items and tax items and are subsequently replaced by the value defined in Customizing.
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Integration of New G/L (Segment Reporting)
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
561
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Lesson Summary You should now be able to: • Explain the derivation of segments for the new G/L accounting in Contract Accounts Receivables and Payables.
562
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 520
Lesson: Credit Management
Credit Management Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the main features of risk-based customer segmentation and credit monitoring with SAP Credit Management and its integration with Contract Accounts Receivable and Payable.
Business Example
Figure 372: SAP Credit Management
2006/Q2
© 2006 SAP AG. All rights reserved.
563
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
With SAP Credit Management you can manage commitments and scores for a business partner. The central Credit Management server manages information from different systems, such as CRM, Contract Accounts Receivable and Payable (FI-CA), and Accounts Receivable Accounting (FI-AR), and carries out operational credit checks. The use of the interface technology of the Exchange Infrastructure means that you can also connect external systems to SAP Credit Management. FI-CA has interfaces for transferring credit information from and to SAP Credit Management.
Figure 373: Customer Segmentation
Figure 374: Determination of Scores and Risk Classes
564
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Credit Management
How to derive individual credit and collection strategies? 1. 2. 3. 4.
Segment your customer‘s (different internal and external information can be taken into account) A formula editor enables calculation of the current score value The risk class is derived from the score value You can tailor your credit and collection strategies based on the risk class
Figure 375: Use of Internal Knowledge of Payment Behavior
Replication of Creditworthiness Usage The creditworthiness managed in Contract Accounts Receivable and Payable is forwarded to SAP Credit Management and contributes to the score managed there. For internal processes such as dunning and returns processing in Contract Accounts Receivable and Payable to be able to react to the score from SAP Credit Management, the score must also be transferred to Contract Accounts Receivable and Payable. Features Transfer of FI-CA Creditworthiness to SAP Credit Management You transfer the FI-CA creditworthiness to SAP Credit Management using the Replicate Creditworthiness mass activity. Transfer of Score to Contract Accounts Receivable and Payable
2006/Q2
© 2006 SAP AG. All rights reserved.
565
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
When you transfer the FI-CA creditworthiness to SAP Credit Management using the Replicate Creditworthiness transaction, the updated score in SAP Credit Management is automatically returned to Contract Accounts Receivable and Payable. This means that you can only replicate the score in Contract Accounts Receivable and Payable by performing the Replicate Creditworthiness mass activity.
Figure 376: Collection According to Risk Class
Appropriate collection measures can be assigned based on the risk assessment of a customer. There is no approach for treating all customers the same.
Figure 377: Credit Segments and Commitments
566
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Credit Management
Credit Segment Definition An organizational unit of SAP Credit Management that you can define as required, for example, by product type or business area. It is possible to subdivide the relevant business transactions in a telecommunications company by the following credit segments: • • •
Fixed network Internet Cellular network
Use The credit segment groups the business of a company from the view of credit assignment and control. On credit segment level, the credit limit and the commitment of a product type or business area are updated and used for credit limit checks and for evaluation of the credit limit used. Transfer of Commitment The connected business systems (Contract Accounts Receivables and Payables, CRM or SD) pass the commitment of a business partner via XML messages to SAP Credit Management. SAP Credit Management consolidates the messages into a commitment.
Figure 378: Credit Risk Monitoring
Function for building customer-specific process chains within Credit Management:
2006/Q2
© 2006 SAP AG. All rights reserved.
567
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
You may define the dependencies between various occurrences that may happen while processing SAP Credit Management and the SAP Credit Management processes that are triggered by these occurrences. For example, if the creditworthiness score of a business partners changes, the risk class also changes.
568
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Credit Management
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
569
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Lesson Summary You should now be able to: • Explain the main features of risk-based customer segmentation and credit monitoring with SAP Credit Management and its integration with Contract Accounts Receivable and Payable.
570
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 527
Lesson: Financial Customer Care
Financial Customer Care Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
To explain the main features of financial customer services in the IC WebClient based Financial Customer Care.
Business Example
Figure 379: Integrating Customer Interaction and Processes
2006/Q2
© 2006 SAP AG. All rights reserved.
571
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
An interaction center • • •
... Is essential in service, marketing, and sales processes Has high transparency with direct impact on customer satisfaction and quality of service Is mediator between customers and business processes
More than 80% of all business processes either start or end in an interaction center (AMR Research, 2001) This means that there is no front-office and back-office. There is just one interaction center focused around the needs of your customers. Financial Customer Care uses the Interaction Center WebClient (IC WebClient) in Customer Relationship Management (CRM) as framework for all financial aspects of interaction with customers.
Figure 380: CRM Interaction Center WebClient: Layout
572
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Financial Customer Care
The CRM Interaction Center WebClient provides call center agents with a multifunctional framework including all of the tools they need to do their jobs: •
• •
•
• • • • • •
Interaction Management & Customer History: Every interaction with a customer is logged and becomes part of the customer history. The latest records of the interaction history are displayed when the customer calls. Agent’s inbox Multi-channel support: The call center not only supports telephony but many other channels, synchronous or asynchronous. For example, incoming mails can be submitted for processing either immediately or routed into agents‘ inboxes. This also takes place for other inquiries such as faxes or letters. As a result, the agent inbox becomes the point of access when an agent is not working on calls. Follow-up activities and actions: Any interaction with a customer may require follow-up. In order to make this happen, an agent can create such activities as part of a call. Actions can also be triggered by an agent or carried out automatically. For example, an automatic correspondence can be sent out when an interaction has a certain status. Scripting (instructions for the agent to aid in interaction with customers) Call lists Knowledge tools Real-time statistics Multifunctional support (Marketing, Sales, Service, Accounts Receivable) Transaction Launcher
Figure 381: 360 degree view of customer
2006/Q2
© 2006 SAP AG. All rights reserved.
573
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Figure 382: FCC for Financial Inquiries
Financial Customer Care - Activities: • • • • • • • • • •
Information and status about all financial aspects of a customer Change master data (address, bank details, payment method …) Set / remove locks (for example, dunning lock, payment lock,...) Create/change installment plan Defer open items Dunning reversal Take payment (for example, by credit card) Search for payments Create dispute cases Create credit memo request
Figure 383: FCC for Dispute Management
Functionality of a Dispute Case
574
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Financial Customer Care
The Dispute Case is a virtual folder that contains all relevant documents and objects. It contains information such as: • • • •
Customer master data Disputed items and amounts Related documents, orders, and contract data Notes, history, and change log
Provides routing capabilities Allows actions to be triggered - for example, ad-hoc or automated correspondence Provides the option to create credit memo request with relation to the dispute case.
Figure 384: FCC for Collections in the Interaction Center
Integrated Collections Management Functions: Alerts during customer call: Giving instruction(s) to agent Customer Fact Sheet: Showing overall customer status Detailed customer overviews: For additional background information • • • • •
2006/Q2
Up-to-date customer payment data Change payment methods Capture payment commitment (promise-to-pay) Capture payment authorization Offer installment plans
© 2006 SAP AG. All rights reserved.
575
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
576
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Financial Customer Care
Lesson Summary You should now be able to: • To explain the main features of financial customer services in the IC WebClient based Financial Customer Care.
2006/Q2
© 2006 SAP AG. All rights reserved.
577
Unit 14: Further Integration of FI-CA in SAP Modules
Lesson: 533
IUT240
Business Intelligence Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the FI-CA Content for Business Intelligence.
Business Example
Figure 385: Business Information Warehouse (BW)
578
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Business Intelligence
For evaluations in Business Intelligence (BI), Contract accounts Receivable and Payable provides extractors for open and cleared items as well as for collection items and installment plan items. The extraction programs fill the extraction structure of the relevant DataSources with data from Contract Accounts Receivable and Payable.
Figure 386: BW: Data Extraction, Transformation, and Presentation
Figure 387: BW: Business Content FI-CA
2006/Q2
© 2006 SAP AG. All rights reserved.
579
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
For evaluations in Business Intelligence (BI), Contract accounts receivable and Payable provides extractors for open and cleared items as well as for collection items and installment plan items. The extraction programs fill the extraction structure of the relevant DataSources with data from Contract Accounts Receivable and Payable.
580
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Business Intelligence
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
581
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Lesson Summary You should now be able to: • Explain the FI-CA Content for Business Intelligence.
582
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: 536
Lesson: Outbound Interface
Outbound Interface Lesson Duration: 10 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Explain the outbound interface for postings in Contract Accounts Receivable and Payable
Business Example
Figure 388: Outbound Interface for Postings
With the outbound interface of Contract Accounts Receivable and Payable (FI-CA), you can forward information about business partner postings to external systems. This can be particularly important if, for a large number of your
2006/Q2
© 2006 SAP AG. All rights reserved.
583
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
documents, instead of entering them in the SAP system, you transfer them to one or more external systems via an interface and these systems are dependent on information, such as incoming payment or reversal, in order to be able to react in follow-on processes. Features: The outbound interface for postings to the business partner is based on the creation of trigger entries at the time of the postings. Whenever you require data in an external system, you can start a mass run for the transfer. This transfers the data to the external system using trigger records (see SAP menu Periodic Processing → Data for Externals → Outbound Interface for Business Partner Postings transaction FPOITR). The mass activity sends the data to a central integration server using messages of SAP Exchange Infrastructure. From there the data can be forwarded to the respective receiving system. To ensure that the recipient of the message is determined correctly, each message only receives data for one receiving system and the ID of the receiving system. You can transfer the following information to external systems using this interface: • • • • •
Open items of business partner Cleared items of business partner since last transfer Incoming payments since last transfer Information about reopened documents Detailed information about installment plans
You can influence which information is to be transferred to the respective external system by means of Customizing settings at company code level or for each receiver system. You make the settings in the Implementation Guide for Contract Accounts Receivable and Payable under Data Transfer → Outbound Interface. Read the documentation for the individual activities. Note for the industry component Public Sector Contract Accounts Receivable and Payable Using the settings in the Customizing activity Making Settings for Public Sector-Specific Trigger Filtering, you can filter the data by contract account category and contract account object type.
584
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Outbound Interface
Figure 389: Outbound Interface: Settings
Maintain Settings for Company Code In this activity, for each company code for the outbound interface of business partner postings, you define whether and how postings are transferred to external systems. You can determine whether open items, cleared items, or payment information and payment information for reopened line items is to be transferred. A change to Customizing does not have a direct effect on the data of the outbound interface since the data is preselected using trigger tables. Changes to Customizing only have an effect on new postings. Therefore, you should not make changes to Customizing during productive operation. Maintain Settings for Recipient System In this activity, for each external receiver system, you define whether open items, cleared items, payment information, and information about reopened line items and installment plans is to be transferred. If, for example, you have not selected the transfer of open and cleared items in the IMG activity Maintain Settings for Company Code for a company code, these postings in this company code are not transferred to an external system, irrespective of what you define for the external systems in this IMG activity. Depending on the setting, for each posting, the system saves corresponding trigger entries that you transfer to the receiver system in the subsequent transfer with the mass activity Outbound Interface Business Partner Postings (transaction FPOITR). For each receiver system, you also define the level at which documents are to be transferred. Here you can select between business partner, contract account, and contract. The function of the transfer level is described below using an example
2006/Q2
© 2006 SAP AG. All rights reserved.
585
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
with open items. The prerequisite is that the transfer of open items has been activated for the receiver system. The function for transferring cleared and other items works the same way. In the transfer at business partner level, when you post an open item to a business partner, the system creates a trigger entry with exactly this business partner (without contract account or contract). In the next transfer, all existing open items for this business partner are transferred to the external system. The business partner postings are not filtered. You should select this option if all data for a business partner is always required in the receiver system. In the transfer at contract account level, when you post an open item to a business partner, the system creates a trigger entry with this business partner and the contract account posted to. In the next transfer, all existing open items for this business partner with exactly this contract account are transferred to the external system. You should select this option if you only require the data for specific contract accounts in the receiver system or you may only transfer the data for certain contract accounts, for data protection reasons, for example. To specify which contract accounts are to be transferred to the external system, for event 3800 Outbound Interface: Filter Triggers and Determine Receiver, you have to define an own implementation and delete the triggers dependent on the contract account category, for example. In Public Sector Contract Accounts Receivable and Payable, without implementing event 3800, in the IMG activity 9,652.00 Make Settings for the Public Sector-Specific Trigger Filtering, you can define a filtering dependent on the contract account category and the contract account object type. In the transfer at contract level, when you post an open item to a business partner specifying a contract, the system saves a trigger entry with this business partner, the contract account posted to, and the contract. In the next transfer, all existing open items for this business partner with exactly this contract account and contract are transferred to the external system. You should select this option if you only require the data for specific contracts in the receiver system or you may only transfer the data of certain contracts, for data protection reasons, for example. You define which contracts are to be transferred to the external system at event 3800 Outbound Interface: Filter Triggers and Determine Receiver by defining a customer-specific implementation and deleting the trigger dependent on the contract. You can also define whether, when the documents are transferred, the external numbers of the business partner, contract account, or contract are to be read and transferred in the XI message. For performance reasons, you should only set the indicator if you need the external numbers in the receiver system as identification characteristics. Define Settings for Public Sector-Specific Trigger Filtering
586
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Outbound Interface
If you selected the transfer at contract level or at contract account object level in the IMG activity Maintain Settings for Target System, you should define which contract account categories and contract object types should be transferred to the external system. Define exactly which contract account categories and contract object should be allowed to be transferred. If a contract account category or contract account object is not entered, no triggers are created for them and no documents are transferred to the system. If you want to allow all contract account categories, for example, you can use the generic value “*”. If the transfer is carried out at contract account level, you cannot maintain any settings for the contract object type. In this case, enter the value “*” in the Contract Object Type field. If this table is completely empty, the system assumes that no filtering should be carried out. Then all documents of all contract account categories or contract object types are transferred to the external system. Once you make entries for one of the systems, you have to define which contract account categories and contract object should be transferred for all other target systems. If no entries are made for a system, it does not create any trigger entries and therefore does not transfer any documents. To make the filtering more specific, for example to, to include other fields, create your own implementation for event 3800 Outbound Interface: Filter Triggers and Receiver Determination.
2006/Q2
© 2006 SAP AG. All rights reserved.
587
Unit 14: Further Integration of FI-CA in SAP Modules
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
588
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Outbound Interface
Lesson Summary You should now be able to: • Explain the outbound interface for postings in Contract Accounts Receivable and Payable
2006/Q2
© 2006 SAP AG. All rights reserved.
589
Unit Summary
IUT240
Unit Summary You should now be able to: • Explain the integration of Contract Accounts Receivable and Payable with other SAP components and applications. • Explain the Funds Management update logic in FI-CA • Explain the accounting derivation in Funds Management • Allocate business partners to debtors and vendors • Explain the connection between Funds Management and FI-CA • Describe the update of the financial status from Contract Accounts Receivable and Payable • Explain the connection of SD orders in Contract Accounts Receivable and Payable • Explain the derivation of segments for the new G/L accounting in Contract Accounts Receivables and Payables. • Explain the main features of risk-based customer segmentation and credit monitoring with SAP Credit Management and its integration with Contract Accounts Receivable and Payable. • To explain the main features of financial customer services in the IC WebClient based Financial Customer Care. • Explain the FI-CA Content for Business Intelligence. • Explain the outbound interface for postings in Contract Accounts Receivable and Payable
590
© 2006 SAP AG. All rights reserved.
2006/Q2
Unit 15 Appendix: Industry-Specific Functions
543
Unit Overview Unit Objectives After completing this unit, you will be able to: • • •
Unit Contents Lesson: Appendix Utilities .....................................................592 Lesson: Appendix Telecommunications .....................................612 Lesson: Appendix Media.......................................................622
2006/Q2
© 2006 SAP AG. All rights reserved.
591
Unit 15: Appendix: Industry-Specific Functions
Lesson: 544
IUT240
Appendix Utilities Lesson Duration: 1 Minutes
Lesson Overview
Lesson Objectives After completing this lesson, you will be able to: •
Business Example Budget Billing Procedure - Postings
Figure 390: Implemented Budget Billing Procedures
In the statistical procedure, the budget billing amounts are managed in IS-U statistically. They are not posted to the general ledger until payment has been received. In the partial bill procedure, the individual amounts are posted directly as debits.
592
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
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 next 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.
Figure 391: Budget Billing Requests: Statistical Procedure Procedure:
You can choose from various procedures for budget billing collection, which differ in terms of financial accounting. If you select the “statistical procedure”, the budget billing requests are managed as statistical items in FI-CA and do not initially affect the general ledger. The payable is not posted to the general ledger and tax is not cleared until payment for the statistical budget billing plan item has been received. The budget billing payments are cleared with the next annual consumption billing.
2006/Q2
© 2006 SAP AG. All rights reserved.
593
Unit 15: Appendix: Industry-Specific Functions
IUT240
In this procedure, tax is not posted in FI and paid to the tax authorities until the budget billing is paid.
Figure 392: Budget Billing Requests: Debit Entry Procedure
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.
Figure 393: Statistical Procedure: Example
594
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
To simplify the example, only one budget billing is requested and paid.
Figure 394: Budget Billing Payments: Postings 1
1. (Statistical) posting of the budget billing request in IS-U.
Figure 395: Budget Billing Payments: Postings 2
2. Posting of incoming payment in general ledger accounting.
2006/Q2
© 2006 SAP AG. All rights reserved.
595
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 396: Budget Billing Payments: Postings 3
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.
596
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Figure 397: Budget Billing Payments: Postings 4
4. Posting consumption billing in IS-U using IS-U invoicing. The debit entry of the receivable is made available for general ledger accounting.
Figure 398: Budget Billing Payments: Postings 5
5. Budget billing transfer posting in IS-U.
2006/Q2
© 2006 SAP AG. All rights reserved.
597
Unit 15: Appendix: Industry-Specific Functions
IUT240
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.
Figure 399: Budget Billing Payments: Overpayment - 1
To simplify the example, only one budget billing is requested and paid.
Figure 400: Budget Billing Payments: Overpayment - 2
1. (Statistical) posting of the budget billing request in IS-U.
598
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Figure 401: Budget Billing Payments: Overpayment - 3
2. Posting of the incoming payment to the general ledger.
Figure 402: Budget Billing Payments: Overpayment - 4
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
599
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 403: Budget Billing Payments: Overpayment - 5
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) Due to the consumption billing and budget billing amounts, there is a credit amount (C) of 13.60 for electricity and a remaining receivable amount (R) of 3.50 for water. Therefore, the customer has a remaining credit amount of 10.10.
600
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Figure 404: Budget Billing Payments: Overpayment/Underpayment
The way in which remaining credit from consumption billing is cleared against other receivables or future due budget billings is specified in clearing control.
Figure 405: Partial Billing Procedure: Example
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
2006/Q2
© 2006 SAP AG. All rights reserved.
601
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 406: Partial Billing Procedure: Postings 1
1. Posting of the budget billing request 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.
602
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Figure 407: Partial Billing Procedure: Postings 2
1. Posting of the budget billing receivable in IS-U. 1a. Posting of an additional budget billing receivable in IS-U 1. Debit entry of a budget billing due date in conjunction with tax posting to the general ledger 1a. New debit entry of an additional budget billing due date in conjunction with tax posting 2. Posting of the incoming payment to the general ledger. Only one partial bill was paid. 3. Allocation of the budget billing payment in IS-U using IS-U incoming payments.
2006/Q2
© 2006 SAP AG. All rights reserved.
603
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 408: Partial Billing Procedure: Postings 3
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. 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.
604
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Figure 409: Payment Plan: Example
To simplify the example, only two budget billings are requested and posted as debits. Only one partial bill is paid.
Figure 410: Budget Billing Procedures: Payment Plan
2006/Q2
© 2006 SAP AG. All rights reserved.
605
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 411: Payment Plan: Postings
Figure 412: Budget Billing Advance Payment
If you want to activate the advance payment function for a budget billing plan, call this function in the change transaction (EA62) using the path Edit -> Activate Advance Payment. Enter the date from which the budget billing plan is to be identified as an advance payment plan. The first due date on which the print date /debit entry date is larger than or equal to the start date is doubled and all others are assigned the indicator X
606
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
= advance payment. The last due date of an advance payment is flagged with L. The print/debit entry date of the first due date is entered as the start date of the advance payment in the header data of the budget billing plan. 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.
Figure 413: Yearly Advance Payment: Acceptance
2006/Q2
© 2006 SAP AG. All rights reserved.
607
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 414: Yearly Advance Payment
Figure 415: Budget Billing: Customizing
General Customizing: • • • •
608
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
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
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. Budget Billing Procedure: Summary • • •
2006/Q2
There are different options for charging budget billing amounts in IS-U. There is a distinction between actual debit entry and the statistical budget billing request. When statistical budget billing requests are used, tax clearing is posted when incoming payment is received. In invoicing, the budget billing payments received are balanced against the bill amount.
© 2006 SAP AG. All rights reserved.
609
Unit 15: Appendix: Industry-Specific Functions
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
610
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Utilities
Lesson Summary You should now be able to: •
2006/Q2
© 2006 SAP AG. All rights reserved.
611
Unit 15: Appendix: Industry-Specific Functions
Lesson: 563
IUT240
Appendix Telecommunications Lesson Duration: 1 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Business Example
Figure 416: Database Table IST_TDATA
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.
612
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Telecommunications
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.
Figure 417: IDoc Interface
2006/Q2
© 2006 SAP AG. All rights reserved.
613
Unit 15: Appendix: Industry-Specific Functions
IUT240
IDoc Interface •
An IDoc interface is used to transfer business data to and from an external system. Scenarios include: – – –
• •
Electronic data interchange (EDI) Application Link Enabling (ALE) Connect of any number of other business application systems (for example, pc applications, external workflow tools) using IDoc. The IDoc interface is made up of the definition of a data structure and a processing logic for this data structure. information (SAP Library - Basis → Basis Services → Communication Interface → IDoc Interface) Tools → Business Communication → IDoc → IDoc Basis
Services are billed in an external billing system. However, the resulting receivables are managed in contract accounts receivable and payable. As a result, invoice items must transferred to contract accounts receivable and payable. The data is transferred via the interface for billing documents. In contract accounts receivable and payable, the invoice lines are automatically posted as open items to the corresponding contract accounts and business partners. If necessary, you can also enter additional account assignments for profitability analysis (CO-PA) in the interface or add them via Customizing, and transfer the accounting information to profitability segments. For further information on the invoice interface for IS-T, see the online documentation for the Telecommunications industry component.
614
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Telecommunications
Figure 418: IS-T/IS-U IDOC Interfaces
Figure 419: Invoice Document Transfer (Business Scenario)
2006/Q2
© 2006 SAP AG. All rights reserved.
615
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 420: Mass Reversal Interface
Figure 421: Possible Processing Runs
616
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Telecommunications
Figure 422: Disconnection File for Telephone Numbers
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. The disconnection of services includes the following steps: 1. 2.
The dunning activity Disconnection of Services is triggered in the dunning run. 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 file has the following naming conventions: • •
Disconnection file from dunning activity run: BTnnnnnnn Disconnection file from simulation run: BTnnnnnnn
The file is transferred to an external system (for example, an external billing system).
2006/Q2
© 2006 SAP AG. All rights reserved.
617
Unit 15: Appendix: Industry-Specific Functions
IUT240
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.
Figure 423: Reconnection File for Telephone Numbers
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 file has the following naming conventions: Reconnection file from actual run: UTnnnnnnn Reconnection file from simulation run: UTnnnnnnn
618
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Telecommunications
IS-T Special Features: Summary • •
•
2006/Q2
In IS-T, telecommunication data can be stored in documents. Billing documents from telecommunication services are transferred from the external billing system via a specific interface for invoicing documents to contract accounts receivable and payable. You can use the dunning procedure to initiate the disconnection of telecommunication services if items are not paid. Once the items have been paid or cleared, you can reconnect the services.
© 2006 SAP AG. All rights reserved.
619
Unit 15: Appendix: Industry-Specific Functions
IUT240
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
620
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Telecommunications
Lesson Summary You should now be able to: •
2006/Q2
© 2006 SAP AG. All rights reserved.
621
Unit 15: Appendix: Industry-Specific Functions
Lesson: 572
IUT240
Appendix Media Lesson Duration: 1 Minutes
Lesson Overview Lesson Objectives After completing this lesson, you will be able to: •
Business Example
Figure 424: IS-M/SD Connection to IS-M/CA: Overview
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.
622
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
Figure 425: Contract Account Determination in Order I
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
623
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 426: Contract Account Determination in Order II
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.
Figure 427: Contract Account Determination in Order III
624
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
If no contract account exists for the payer, you can create a contract account in the dialog.
Figure 428: Payment Methods in Contract Account
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.
Figure 429: Different Payment Methods in Order
2006/Q2
© 2006 SAP AG. All rights reserved.
625
Unit 15: Appendix: Industry-Specific Functions
IUT240
In media sales and distribution, you can use the function Payment Different from Contract Acct. to change the payment method and additional data. You have the following options: • • •
You select a payment method different to the contract account. You select bank details or payment card data for the payment method that differ from contract accounts receivable and payable. The differing data is transferred to the invoice and the FI-CA document.
Due to the payment controls in contract accounts receivable and payable (cash discount deadline + cash discount % / due date for net payment), you cannot use all standard FI terms of payment. The following restrictions apply: •
• • • •
You can only define one cash discount period. The second cash discount period is interpreted as the net payment due date, and must have the cash discount percentage 0.00. The the terms of payment must be defined and valid for the whole month. Installment payment conditions are not supported. The system does not support the inclusion of a factory calendar during the conversion of terms of payment into corresponding due dates, which is possible in IS-U.
The check to see whether a term of payment is suitable for use with FI-CA takes place when allocating the term of payment in the sales area data - customer invoicing - and during entry in the SD order. You can use the function Pyt According to Contract Acct to cancel the changed data.
Figure 430: Payment Method: Cash Payer
626
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
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.
Figure 431: Deriving Transactions from IS-M/SD Information
Figure 432: Deriving the Receivables Account
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
627
Unit 15: Appendix: Industry-Specific Functions
IUT240
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.
Figure 433: IS-M/SD Connection to IS-M/CA: Revenue Deferral
For the revenue deferral, the system determines the revenues that have not yet been realized. 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.
628
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
Figure 434: Renewal Subscription - Incoming Payments Triggered by the Customer
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 make 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.
Billing Document 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 billing document 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.
2006/Q2
© 2006 SAP AG. All rights reserved.
629
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 435: Incoming Payments Reversal
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 reason must be reversed in the down payment document. If the outgoing payment is at the cash desk, this is not necessary.
630
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
Figure 436: Renewal Subscription - Incoming Payments Triggered by the Publisher
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. In the document, corresponding references to the IS-M/SD fields are set.
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.
2006/Q2
© 2006 SAP AG. All rights reserved.
631
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 437: Returns - Change Invoice Payer
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, clearing is not reversed in IS-M/SD when the returns document is posted, and the subscription renewal remains accepted.
•
b) Returns without payment method
When the returns document is posted, the acceptance of the subscription renewal is reversed in IS-M/SD. The billing document is reversed and a cancellation billing document is created (3). The billing data transfer of the cancellation billing document, automatic clearing (4) and account maintenance for returns all correspond to the procedures described in the “Other Business Transactions” unit. As result of this procedure, the customer is converted to an invoice payer. He or she receives a renewal offer that contains information from the returns document. The corresponding print program and form have to be created for each individual customer.
632
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
Figure 438: Complaint with Monetary Credit
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).
2006/Q2
© 2006 SAP AG. All rights reserved.
633
Unit 15: Appendix: Industry-Specific Functions
IUT240
Figure 439: IS-M/SD Connection to IS-M/CA: Service Settlement
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 allocate in the employment relationship, in the case of service company settlement it is allocated in the settlement data for the service company. When a 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: • •
634
Type of the IS-M/CA document Main transaction and subtransaction
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Lesson: Appendix Media
Facilitated Discussion
Discussion Questions Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.
2006/Q2
© 2006 SAP AG. All rights reserved.
635
Unit 15: Appendix: Industry-Specific Functions
IUT240
Lesson Summary You should now be able to: •
636
© 2006 SAP AG. All rights reserved.
2006/Q2
IUT240
Unit Summary
Unit Summary You should now be able to: • • •
2006/Q2
© 2006 SAP AG. All rights reserved.
637
Course Summary
IUT240
Course Summary You should now be able to: • • •
638
Modify FI-CA business processes to meet your individual needs Execute and check these business processes Describe the integration with other components and applications
© 2006 SAP AG. All rights reserved.
2006/Q2
Feedback SAP AG has made every effort in the preparation of this course to ensure the accuracy and completeness of the materials. If you have any corrections or suggestions for improvement, please record them in the appropriate place in the course evaluation.
2006/Q2
© 2006 SAP AG. All rights reserved.
639