IHE203
Student Lifecycle Management:
Student Accounting
SAP for Industries
© SAP 2008
„
SAP for Industries
„
Version 98
„
Material Number 50125233
Copyright
Copyright 2014 SAP AG. All rights reserved.
Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
© SAP
Trademarks:
„ Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,
Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ®
are registered trademarks of Microsoft Corporation.
„ Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.
„ Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
„ ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken
„ Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
„ TouchSend Index ® is a registered trademark of TouchSend Corporation.
„ Visio ® is a registered trademark of Visio Corporation.
„ IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.
„ Indeo ® is a registered trademark of Intel Corporation.
„ Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape
Communications, Inc.
„ OSF/Motif ® is a registered trademark of Open Software Foundation.
„ ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.
„ INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
„ UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.
„ ADABAS ® is a registered trademark of Software AG
„ The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2,
R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript,
SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and
ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included
herein are also trademarks or registered trademarks of SAP AG.
„ Other products, services, logos, or brand names included herein are trademarks or registered
trademarks of their respective owners.
Target Audience
Participants
„
Project team leaders responsible for Student Accounting
„
Project team members
„
Consultants
Duration: 5 days
© SAP AG 2010
Course Goals
This course will prepare you to:
„
Understand the scope of financial processes specific to institutions of
Higher Education in the context of Student Lifecycle Management
„
Understand key business processes within Public Sector Collection and
Disbursement and Financial Contract Accounting
„
Identify integration points between Student Lifecycle Management and
other SAP ERP accounting modules
© SAP AG 2010
SAP Software Component Information
„
The information in this course pertains to the following SAP Software Components and releases:
„
ECC6.0 EhP4
„
This course does not go into the technical details of the interfaces
Course Objectives
At the conclusion of this course, you will be able to:
© SAP AG 2010
„
Create, display, and maintain business partners, contract accounts, and
contract objects
„
Describe the relationship between Student Administration (e.g., register in a
program, booking modules/classes) and Student Accounting (e.g., calculating
fees and disbursing financial aid) in Contract Accounting
„
Execute a fee calculation and grant evaluation
„
Post fees, aid and refunds and clear open items
„
Produce correspondence
„
Process incoming and outgoing payments
„
Display and adjust the account balance layout
„
Execute periodic activities
„
Update the General Ledger, Controlling and Funds Management
„
Explain the integration with other SAP components and trace the flow of
financial documents through the SAP system
Course Content
Unit 1 Student Accounting - Basics
Unit 2 Master Data
Unit 3 Fee Calculation Process
Unit 4 Fee Calculation
Configuration
Unit 5 Fee Calculation
Configuration Financial
Unit 6 Fee Calculation Other Fees
Unit 7 Sponsoring
© SAP 2008
Unit 8
Document Posting and
Processing
Unit 9
Correspondence
Unit 10 Payments
Unit 11 Clearing and Account
Maintenance
Unit 12 Dunning and Collections
Unit 13 Additional Functions
IHE203 Student Accounting - Agenda
Monday
Welcome and
Introduction
1 – Basics &
Integration
2 – Master Data
3 – Fee
Calculation
Process
3 – Fee
Calculation
Process
Continued
© SAP AG 2010
Tuesday
4 – Fee
Calculation
Configuration
4 – Fee
Calculation
Configuration
Continued
5 – Fee
Calculation
Configuration
Financial
5 – Fee
Calculation
Configuration
Financial
Continued
Wednesday
6 – Fee
Calculation
Other Fees
7 – Sponsoring
8–
Document
Posting and
Processing
Thursday
8–
Document
Posting and
Processing
Continued
9–
Correspondence
10 Payments
Friday
11 –
Clearing and
Account
Maintenance
12- Dunning and
Collections
13 – Additional
Functions
Level of the course
This is a level 3 course in which you will learn about
„
Concepts, data models, process models and solution architecture
„
Links between application and business processes
Recommended Prerequisites:
„
IHE102 – Managing a Student Lifecycle
„
AC010 – Business Processes in Financial Accounting
„
IPS510 – Public Sector Collection and Disbursement
„
IPS 910 – Funds Management
„
Relevant experience in higher education and sub ledger accounting in the public sector
© SAP AG 2010
„
The course does not cover
• Programming of BAdIs, BAPI, or FI-CA Events
• Generic SAP tools (such as authorization, workflow, exchange infrastructure, reporting/query,
Smartforms, Print Workbench, Adobe Forms)
• In-depth technical tools within SLCM (such as Internet Service Request, Validation/Substitution
and Rules, Selection Methods)
• Other applications used in Student Accounting (such as Financial Supply Chain Management
(EBPP), Portal, Financial Aid Software, Customer Relationship Management (CRM))
SAP for Higher Education and Research
AC010
5 Days
Business Processes
in Financial
Accounting
WNAPSF
5 Days
Financial Accounting for
Public Service
IHE203
5 Days
SLCM: Student Accounting
(Prereq.: IHE102)
HR050
1 Day
Business Processes
in Human Capital
Management
HR515
3 Days
Training and Event
Management
IHE102
5 Days
Managing a Student
Lifecycle
© SAP AG 2010
AC720
3 Days
Integrating Funds
Management with HR
Funds and Position
Management
Further Information on Student Lifecycle
Management
Look at the following Resources:
www.service.sap.com/RKT
(Ramp Up Knowledge Transfer => SAP for Higher Education & Research)
www.service.sap.com/PAM
(Product Availability Matrix => Student Lifecyle Management)
https://help.sap.com/ => SAP ERP ->ERP Central Component
ERP Central Component – for Release Student Lifecycle Management 6.00
ERP Central Component - SAP Enhancement Package 4 for SAP ERP 6.0
https://www.sdn.sap.com/irj/sdn/bpx-highered
(Higher Education & Research Business Process Expert (BPX) Community)
© SAP AG 2010
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
1-1
1. Basics: Overview
Content:
„
Development of Public Sector Collection and Disbursement
„
Integration with other SAP components
„
Tools:
„ Concept
„ Parallel
of Event Technology
Mass Processing
„ Outbound
Interfaces of Postings
„ Archiving
© SAP AG 2010
© SAP AG
IHE203
1-2
1. Basics: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Explain how Student Accounting uses the Public Sector Collection
and Disbursement (PSCD) component
„
Identify Public Sector Collection and Disbursement integration
points with other components
„
List the benefits of using Contract Accounting to manage Student
and Sponsor Accounts
„
Describe available tools to extend PSCD functions
© SAP AG 2010
© SAP AG
IHE203
1-3
1. Basics: SAP Student Lifecycle Management
3
1
Admission
Equivalency
Determination
5
Registration
Course
Registration
13
12
Application
Reporting
Academic
Calendar
Academic
History
of the
Study
Academic
Structure
Rules &
Regulation
Events
Resources
Event
Planning
6
Examination
& Grading
Alumni
StudentMasterdata
Teaching &
Study
4
Recruitment
Student
Accounting
Studentadministration
2
8
7
11
De-registration
Graduation
10
Degree
Auditing
9
Change of
Program
Re-registration
Progression
© SAP AG 2010
„
This course concentrates on Student Accounting topics. It covers business processes in student
accounting (IS-PS-CA), fee calculation and sponsoring. This includes functions in master data
processing and collection activities.
„
IS-PS-CA stands for: Industry Solution Public Sector Contract Accounting. SAP’s solution for
Public Revenue and Disbursements Accounting is SAP Public Sector Collection and Disbursement.
„
This course does not describe how to set up Student Administration processes.
© SAP AG
IHE203
1-4
1. Basics: Main Business Scenario
Your University plans to implement SAP Student Lifecycle Management to
support student and sponsor-related financial accounting processes.
The institution requires a software solution that facilitates these tasks:
„
Determine admission-related fee
„
Calculate study-related fees
„
Disburse financial aid
„
Post financial documents
„
Display accounts for students and sponsors
„
Process payments (incoming and outgoing)
„
Produce correspondence (such as invoices, account statements, checks or payment
notifications)
„
Collect overdue charges
© SAP AG 2010
„
The University charges students study-related fees. A student may be entitled to financial aid from
the government, the institution, or private sponsors, for example, the student’s employer. The fees,
refunds or financial aid are cleared against each other and a balance may remain. The debit balance
is collected from the student; a credit balance is disbursed to the student. The industry solution
Public Sector Collection and Disbursement or PSCD is ideally suited to administer the financial
aspect of the contractual obligations.
© SAP AG
IHE203
1-5
1. Basics: Why Contract Accounting?
Progress from being a Student, Sponsor, Parent....
Contract
Account
... to being a Business Partner
The educational institution and the student enter into a contract. The university
provides educational services and the student pays for these services.
These financial obligations are treated as contractual relationships in SAP Contract
Accounting.
© SAP AG 2010
„
The concept of SAP‘s Business Partner functionality allows a comprehensive view of the financial
activities of the student, his/her sponsors and any relationship to other people (e.g. parents,
guardians, etc).
© SAP AG
IHE203
1-6
1. Basics: SAP Business Partner Integration
SAP Business Partner
PS-CD
PSCD - Student Accounting
FI-CA
SLCM
FI
HR
The SAP Business Partner and master data structures integrate SLCM with the
accounting functions of Public Sector Collection and Disbursement.
Contract Accounting is a component of Financial Accounting
© SAP AG 2010
Terminology:
„
Contract Accounting is a component within Financials. Hence the references to FI-CA:
• FI-CA is developed for several industries that deal with mass data and standardized processes.
They benefit from the common developments. FI-CA is the Primary Component when searching
for SAP Notes.
• Search Term for FI-CA (Primary Component usually): XX-PROJ-FI-CA
• Search Term for PSCD (Secondary Component usually): IS-PS-CA
• FI-CA is the basis for various industry specific applications such as:
- IS-PS-CA: Public Sector
- IS-T-CA: Telecom Sector
- IS-V-CA:
„
Insurance (German: Versicherung)
PSCD: Public Sector Collection and Disbursement is the product component supporting various
solutions within the public sector, e.g.:
• Student Accounting
• Grants Management (GM used to account for Research funding)
• Tax & Revenue
• Social Services
• etc.
© SAP AG
IHE203
1-7
1. Basics: Integration with PSCD
Fee Calculation
FI-CA
Documents
Grant Evaluation
Application Fees
FI-CA
Documents
FI-CA
Documents
PSCD
FI-CA Documents
Biller Direct
CRM
© SAP AG 2010
„
Customers decide individually which processes are relevant for their environment:
• Most institutions use the SCLM Fee Calculation. However, it is also possible to have the fees
calculated in another system and utilize a BAPI to create FI-CA Documents.
• Some institutions use ISR (Internet Service Requests) to process Admission Applications and
payment via credit card.
• Some institutions accept incoming payments through Biller Direct while other institutions have
outsourced this activity to a banking service.
© SAP AG
IHE203
1-8
1. Basics: Integration of with other SAP
Components (IMG)
Contract Accounting is integrated with the following SAP components:
© SAP AG 2010
„
Public Sector Collection and Disbursement (PSCD) supports transfer routines to the following
components:
„
General Ledger including Management Accounting, Special Ledger, Funds Management, Grant
(Research) Management
„
Profitability Analysis (Management Accounting) needs the relevant information from the respective
billing application.
„
Cash Management (Treasury Management)
„
Postings in the sub-ledger are not time-critical for the General Ledger or Profitability Analysis and
are asynchronously updated. There is a cyclical transfer to the G/L, for example, once a day.
„
Postings in the sub-ledger are posted to Cash Management (TR-CM) in real time. Web-based
components, such as Biller Direct, are updated in real time.
„
SD bills can be posted to PSCD.
„
For customizing in IMG, choose the path: Financial Accounting → Contracts Contract Accounts
Receivable and Payable → Integration.
Note: The core FI project team is normally responsible for the configuration of the General Ledger,
Special Ledger, Controlling, Public Sector Management and Grants Management.
© SAP AG
IHE203
1-9
1. Basics: Integration of with other SAP
Components - Overview
© SAP AG 2010
„
You can use a standardized IDoc interface to import invoice documents from external billing
systems into PSCD where they can then be processed.
„
Invoicing in PSCD enables billing documents to be transferred from external systems, e.g. Housing
System or Library System and posted to PSCD.
„
The postings in PSCD contract accounts can 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 and Public Sector Management (PSM/Funds Management/Grants Management).
„
Additional account assignments from cost accounting are included and forwarded to the specified
account assignment object, e.g. Cost Center, Profit Center, etc. This information is transferred
regularly using transfer reports that are triggered in PSCD.
„
The integration in Financial Supply Chain Management improves customer-oriented processes.
Business partners can use the Biller Direct component to check invoices and initiate payments (as
well as other functions) on the Internet. Companies can use this information channel to interact with
their customers.
„
Extractors for open and cleared PSCD items and other debit-relevant information exist for SAP
Business Information Warehouse (BI).
„
The integration of PSCD in Customer Relationship Management (CRM) makes it possible to
process receivables in Financial Customer Care efficiently.
© SAP AG
IHE203
1-10
1. Basics: Integration with SAP Components Public Sector Funds Management (PSM)
Actual Revenues
Example: $100,000
grants for students
Actual Expenses
Example: $40,000 paid to
students as aid
Payments
Example: $10,000
Scholarship Fund
Balance Sheet
Cash
Accounts Receivable
$ 10,000
$ 90,000
$100,000
$ 40,000
$ 60,000
Accounts Payable
Total Fund Balance
Income Statement
Revenue
Expense
Fund Balance
$100,000
40,000
$ 60,000
© SAP AG 2010
„
Contract Accounts Receivable and Payable splits the FM account assignments into expenses and
revenues as soon as Public Sector Management/Funds Management is activated.
„
The financial accounting ledger is used primarily to support external reporting requirements.
Financial statements and much of the required disclosure information for reporting to third parties
are prepared using information from this ledger.
„
Postings to the financial accounting ledger are made using dual entry bookkeeping, requiring
balanced postings (debits = credits) by organization, agencies and/or funds. Because this ledger is
the source of external financial information similar to corporate accounting, all “real” financial
transactions must be recorded in this ledger.
„
A fund in this context is a separate and distinct fiscal/accounting object containing a complete selfbalancing set of accounts used to segregate cash and other financial resources, together with
associated liabilities, residual equities and related changes.
„
Using the SAP Fund Accounting solution enables customers to create balance sheets and income
statements based on the fund (or other criteria).
© SAP AG
IHE203
1-11
1. Basics: Integration with SAP Components Funds Management Structure
Funds Center
Structure in SAP
FM Area
al
n
tio
za
i
n
ga
r
o
Fund B
Fund A
Budget Structure
Budget Plan
2000
1996
TDM
TDM
50.490
50.490
362
362
1.470
1.470
23
23
547
547
45.145
45.145
12
12
78
78
.. .. ..
.. .. ..
.. .. ..
.. .. ..
.. .. ..
......
......
......
.. .. ..
2001
1995
TDM
TDM
48.320
...
370
...
1.470
. ..
. 25
..
538
. ..
42.873
. ..
. . 9.
.70
..
.. .. ..
.. .. ..
.. .. ..
.. .. ..
.. .. ..
.. ....
.. ....
.. ....
.. .. ..
l
na
tio
nc
fu
Commitment Item
© SAP AG 2010
„
For Public Sector Management; use the IMG paths:
• Public Sector Management>General Settings for Public Sector Management>Basic Settings:
Account Assignment Elements:
• Activate Account Assignment Elements
• Allow BLANK as Value for Account Assignment Elements
• Public Sector Management>Funds Management Government>Basic Settings> Activate Global
Functions for Budgeting
• Public Sector Management>Funds Management Government>Budget Control System
(BCS)>Budgeting>Basic Settings>Use of Master Data>Activate Account Assignment Elements
in Budgeting
„
For FMDERIVE rules to help with derivations; use the IMG paths::
• Public Sector Management>Funds Management Government>Master Data> Allocations to
Account Assignments from Other Components>Select Derivation Steps
• Public Sector Management>Funds Management Government>Master Data> Allocations to
Account Assignments from Other Components> Define Account Assignment Derivation
• Public Sector Management>Funds Management Government>Master Data> Allocations to
Account Assignments from Other Components>Copy Commitment Items Defined in the G/L
Account
„
For Grants Management; use the IMG path:
• Public Sector Management>Grants Management>Grantee Management>Global Settings>Set
Grant as Not Relevant for Grants Management
© SAP AG
IHE203
1-12
1. Basics: Integration of with SAP Components
- Sales & Distribution (SD)
© SAP AG 2010
© SAP AG
IHE203
1-13
1. Basics: Integration with SAP Components Overview of Financial Customer Care
© SAP AG 2010
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.
© SAP AG
IHE203
1-14
1. Basics: Integration with SAP Components Credit Management
Comprehensive
Credit Management for different systems such as CRM,
Sales and Distribution (SD or others), contract accounts receivable and
payable (FI-CA), accounts receivable accounting (FI-AR) and also for
external (non-SAP) systems
Based
on the interface technology for Exchange Infrastructure (XI)
Risk-based
Liabilities
customer segmentation
and scores for business partners
Operational
credit checks
© SAP AG 2010
„
You can use SAP Credit Management to manage credit exposure and score for a business partner.
The central Credit Management can manage information from different systems, for example, CRM,
Contract Accounts Receivable and Payable (FI-CA) or Accounts Receivable Accounting (FI-AR)
and to carry out operational credit checks.
„
If you use the interface technology of the Exchange Infrastructure, you can also link an external
system to SAP Credit Management. FI-CA has interfaces that you can use to transfer credit
information from and to SAP Credit Management.
© SAP AG
IHE203
1-15
1. Basics: Integration with SAP Components Business Intelligence (BI)
© SAP AG 2010
„
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 Data Sources with data from
Contract Accounts Receivable and Payable.
© SAP AG
IHE203
1-16
1. Basics: Integration with SAP Components Treasury-Cash Management
In the contract account master record you can define the following data for
updating the liquidity forecast:
Planning group: The way, contract accounts with collection authorization can
be considered separately from contract accounts to be paid on demand.
Addition 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.
FI-CA
Document
Planning group
Addition days
TR-CM
© SAP AG 2010
„
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Integration>Cash
Management>Define Alternative Planning Levels for Locks.
„
The update occurs directly when you post a document in FI-CA. As a result, the liquidity forecast
and the daily financial status of Cash Management are always current.
„
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. They are proposed when you enter the 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.
„
There may be wait times for mass postings that run in parallel processes due to competing accesses
when the data for Cash Management is being updated. For these postings, FI-CA provides a parallel
update mode that you can activate for specific types of mass runs. IMG path: Financial
Accounting>Contract Accounts Receivable and Payable>Technical Settings> Activate Parallel
Update of Cash Management. The update of Cash Management then occurs at the end of a process.
If the process is terminated before Cash Management is updated, the update occurs when you close
the respective reconciliation key.
© SAP AG
IHE203
1-17
1. Basics: FI-CA Tools
FI-CA delivers optimum flexibility and performance through the
following technical features:
„
Event Technology
„
Parallel Mass Processes
„
Transfer of Postings
„
Archiving of Master Data and Transactions
© SAP AG 2010
© SAP AG
IHE203
1-18
1. Basics: Event Technology in FI-CA
Events are User Exits to meet customer-specific requirements:
© SAP AG 2010
„
The Event concept allows specific course code to be included at defined points in a program. These
are capsulated in Function Modules, and are therefore exchangeable. You use defined interfaces to
include these statements in the Events.
„
You maintain Events and their Function Modules in the IMG path: Financial Accounting>Contract
Accounts Receivable and Payable>Program Enhancements>Define Customer-Specific Function
Modules.
„
The Function Module FKK_FUNC_MODULE_DETERMINE runs for each Event. It determines
the Event Modules stored in the IMG from the following tables:
• . TFKFBM (sample Function Module from FI-CA)
• . 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 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.
© SAP AG
IHE203
1-19
1. Basics: Event Technology - Technical
Information
„
Events can be managed with transaction FQEVENTS
„
Requires ABAP Coding Experience
„
Overview of event nomenclature:
From Event
To Event
Application
0
9999
Application-Independent
P000
P999
Public Sector
R000
R999
Utilities Industry
S000
S999
SAP Contract Accounting
T000
T999
Telecommunication
V000
V999
Insurance
X000
X999
Partner Development
Z000
Z999
Customer Development
© SAP AG 2010
„
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, it is recommended to proceed as
follows:
• 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.
© SAP AG
IHE203
1-20
1. Basics: Parallel Mass Processes in FI-CA
You can use most FI-CA functions in 2 ways:
„
Manually: For individual activities in the front office
„
Automated: In the back office for mass runs
However, FI-CA’s design is most advantageous in mass runs
where large volumes of data have to be processed, e.g.:
„
Fee Calculation
„
Payment Runs
„
Interest Runs
„
Dunning Runs
„
Correspondence Printing
„
Open Item Reporting (Aging report)
© SAP AG 2010
„
Automated activities are mostly periodic processes.
„
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. For more information,
see the SAP Note 607797 (Job control for mass runs: FAQ).
„
To take advantages of splitting up the mass processes, some principal questions should be taken into
consideration such as your system environment.
„
Refer also to the documentation in OSS under the keyword FO-JOB.
© SAP AG
IHE203
1-21
1. Basics: Parallel Mass Processes in FI-CA
© SAP AG 2010
„
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.
© SAP AG
IHE203
1-22
1. Basics: Technical Settings for Parallel
Processing
Technical settings for parallel processing
Parallel processing object
VKONT
Object
Variant
Automatic load distribution
Total number of jobs
15
15
Explicit load distribution
Target computer Number of jobs
Parallel Processing!
….
….
Database access
Block size
© SAP AG 2010
„
To enhance system performance, it is possible to run jobs with large volumes of data using the
parallel features. For example, printing a large volume of correspondence, the job is broken down
into user defined-pieces; these “intervals” are run on application servers defined as target computers.
Intervals are based (segmented) on contract accounts or business partners. Example: Interval 1,
contract accounts 0001 to 1000; interval 2, contract accounts 1001 to 2999; and so on.
„
If more than one application server is available, it is possible to partition the correspondence job
across these additional servers.
„
With automatic load distribution, the system will determine the partitions automatically.
„
Some programs can be run in parallel if required. To execute several jobs at the same time, enter the
number of jobs required and the interval allocation. Several jobs are then simultaneously started in
one program run, each processing one of the intervals in parallel.
„
You can split the data into intervals according to various criteria, e.g. Business Partner or Contract
Account. The split is controlled by variants in which you specify the number of intervals into which
you wish to divide the data area, and the key area covered by each interval.
„
The block size controls how many selected items are held in the main memory.
© SAP AG
IHE203
1-23
1. Basics: Outbound Interface for Postings
© SAP 2008
„
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 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 the SAP
Easy Access Menu Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>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, and continue with the list
above.
„
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. Make these settings
using the IMG Path: Financial Accounting>Contract Accounts Receivable and Payable>Data
Transfer>Outbound Interface. Please read the documentation for the individual activities.
„
…
© SAP AG
IHE203
1-24
…
„
Note for the industry component Public Sector Contract Accounts Receivable and Payable: You can
filter the data by Contract Account Category and Contract Account Object Type by using the
following activity under Outbound Interface: Define Settings for Public Sector-Specific Trigger
Filtering.
© SAP AG
IHE203
1-25
1. Basics: Archiving
Data Archiving:
Moves mass data from a database allowing “immediate” access to a storage medium where it will
be retrieved when needed.
Database
Archiving Session
1
Documents
Archiving Object
Archive Files
2
3
© SAP AG 2010
„
The technical and legal reasons for archiving application data are as follows:
• Resolve memory space and performance problems caused by large volumes of transaction data
• Make master data easier to handle and to keep up-to-date
• Ensure statutory data retention rules are observed
• Ensure that data can be reused at a later date, for example, in new product development
„
Archiving is carried out in these steps:
• Step 1: Create archive files. – Depending on the data volume you have to create one or more
archive files.
• Step 2: Store archive files.
• Step 3: Execute Delete program.
- After closing the first archive file, the archive management system creates a new archive file
and continues with the archiving process. While this happens, another program reads the
archived data from the completed archive file and deletes it from the database. This procedure
guarantees that only data that has been correctly saved in the archive file is deleted from the
database.
• The Archiving documentation describes in detail the customizing prerequisites for each archiving
object: http://www.sdn.sap.com/irj/bpx/highered -> Student Lifecycle Management Best
Practices and Implementation Guidelines -> Archiving and Deletion in Student Lifecycle
Management.
© SAP AG
IHE203
1-26
1. Basics: Summary of PSCD Advantages
„
One view on Student for collecting and disbursing money
‰ Fees
‰ Financial
Aid
‰ Payments
„
Integration with other SAP components such as General Ledger, Controlling and
Funds Management
„
Flexibility to meet customer-specific requirements through Event technology
„
Ability to administer large data volumes through parallel mass processing
„
Export transactions to external systems
„
Supports archiving of old data
© SAP AG 2010
„
PSCD allows to administer mass records and processes:
• Thousands of business partners
• Processing many open items, e.g., performance test based on 5 million business partners:
- Posting run with 3,600,000 items per hour
- Correspondence with 8,900,000 items per hour
• Integration with front-office activities
© SAP AG
IHE203
1-27
1. Basics: Unit Summary
You should now be able to:
„
Explain how Student Accounting uses the Public Sector Collection and
Disbursement (PSCD) Component
„
Identify PSCD integration points with other components
„
Describe available tools to extend PSDC functions
„
List the advantages of using Contract Accounting to manage Student
and Sponsor accounts
© SAP AG 2010
© SAP AG
IHE203
1-28
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
2-1
2. Master Data: Overview
Contents
„
Student Lifecycle Management and PSCD Master Data
„
Business Partners, Contract Accounts, Contract Objects, Contract Object
Relationships
„
Control Parameters Within Master Data
„
Business Partner specific Payment Transaction
© SAP AG 2010
© SAP AG
IHE203
2-2
2. Master Data: Unit Objectives
At the conclusion of this unit you will be able to:
„
Create business partners, contract accounts, and contract objects in the
system
„
List possible master data relationship scenarios
„
Apply master data control parameters at desired levels
© SAP AG 2010
© SAP AG
IHE203
2-3
2. Master Data: Business Case Examples
„ Student
Accounting
A university charges students based on their registration, the use of housing and meals. The
student is entitled to a grant (aid) for the study program.
„ Sponsor
Accounting
The government offers student aid or a lending institution provides student loans. The university
is responsible for the administration of aid.
„ Other
Revenue Accounting
The student requests additional transcripts for which there is a fee. An external organization is
allowed to use the university’s library and is charged a library usage fee.
How will these scenarios fit into one single master data structure?
© SAP AG 2010
© SAP AG
IHE203
2-4
2. Master Data: Overview of Student Lifecycle
Management Objects
Business
Partner
ST
BP
Organizational Unit
(University)
O
Organizational Unit
(Faculty, etc.)
O
Academic
Calendar
CQ
Degree
Applicant/
Student
External Educational
Institution
SC
Program of Study
Module Groups
CG
Modules
SM
Bus. Event Type
D
Events
E
Individual Work
CI
Bus. Event Package
SE
EO
External Subject
SU
External
Qualification
EQ
CA
RC
Rules
© SAP AG 2010
„
Student Lifecycle Management is based on Personnel Development within HR (HR-PD) using an
object-oriented approach. The main elements are:
„
Object types
„
Infotypes which describe the object types
„
Relationships between object types
„
Validity dates
„
Etc.
„
Some of the object types listed in the slide originate from other applications:
„
Organizational unit (O, origin: HR core functions – Organizational Management)
„
Event types (D, origin: HR strategy – Training & Event Management (TEM))
„
Events (E, origin: HR strategy – Training & Event Management (TEM))
„
Internal qualification (CQ, not the same as the qualification in HR!)
„
Business partner (BP, origin: Financial Contract Accounting (FI-CA))
© SAP AG
IHE203
2-5
2. Master Data: Academic Program Catalog
Academic Structure = All Degree Programs Offered by the University
The organizational structure of an institution is reflected by its organizational units,
which can be arranged in a hierarchy. Degree programs, which are referred to as
programs of study in Student Lifecycle Management, are offered by departments,
faculties, colleges.
Organizational Unit (O)
University of Campus Management
School of Business Administration
Physical Sciences
Program of
Study
Physics, BS Honors
(SC)
Mathematics, MS Honors
Physics, MS Honors
Computer Science, BS Honors
College of Liberal Arts
Faculty of Arts
© SAP AG 2010
„
In Student Lifecycle Management, each Program of Study can be attached to at least one
Organizational Unit. This Organizational Unit is responsible for the Program. You can define more
than one Organizational Unit as responsible for a Program.
„
Every Program has its own academic regulation.
„
Definitions:
„
A Program of Study consists of structural elements
• Specializations, such as majors, minors, etc. They are called “Module Group” (CG) in SLCM
• Courses, which are called “Modules” (SM) in SLCM
• Academic events, such as classes, tutorials, labs, etc., which are events in SLCM
„
Module groups allow to subsume related modules and build up a hierarchy of module groups.
Furthermore, module groups enable you to depict program specializations such as majors, minors,
etc.
„
Modules are academic courses and define the content of a program of study. They can be booked by
a student and a student can get grades and credits for a module.
„
Events / Event types refer to teaching events like classes, tutorials and lectures. They are always part
of a module and need to be attended by students who booked for the module.
„
You can bundle events together into event packages. Event packages can be booked by students,
enabling to book all events contained in the package in one step.
„
For Programs of study, modules and events / event types, there are data catalogs in which the
associated objects are stored and maintained.
© SAP AG
IHE203
2-6
2. Master Data: Relevant to Student
Accounting
Student Lifecycle Management
Org. Unit
Academic Calendar
Program of Study
Student Accounting
uses master data from:
Module
Event Package
Student
SAP Business Partner
Business Partner
Contract Partner
Contract Account
Contract Object
Contract Accounting
© SAP AG 2010
„
In addition to the HR-PD development framework, Student Lifecycle Management is also using
Public Sector Collection and Disbursement (PSCD) or Public Sector Contract Accounting.
„
While administrative and academic processes for students mainly use the functions of the HR-PD
framework (object types, relationships, infotypes, validity dates, and so on), student accounting
processes use PSCD.
© SAP AG
IHE203
2-7
2. Master Data: PSCD Structure Elements
Business
Partner
Natural person(s) or
organizations
Contract
Account
Holds accounting information
Contract
Object
Person or thing referred to by
the business process
© SAP AG 2010
„
SAP Business Partner exists in the real world and is a natural person or an organization.
„
Contract Account does NOT exist in the real world and holds accounting information.
„
Contract Objects may or may not exist (tangible/intangible) in the real world:
• Tangible Contract Objects may include person (children) or property (car, house).
• Intangible Contract Objects may represent specific fee types, for example, tuition, housing, etc.
© SAP AG
IHE203
2-8
2. Master Data: Student Business Partner
Student Lifecycle Management
Student
Accounting
Student
Administration
Student
(ST)
SAP Business Partner
(BP)
Student Business Partner
© SAP AG 2010
„
When creating the master data for a new student, the system creates the following:
„
A Student Object (ST), which is based on the HR-PD framework, using object types, infotypes, and
relationships. The ST object contains personal and academic data.
„
A Business Partner with the roles “Contract Partner” (MKK) and “Student” (PSCM10).
„
An entry in table CMACBPST (linking ST with the business partner object BP).
„
Student administration processes use the student object (ST); student accounting processes use the
business partner object (BP).
„
Students can be created manually or automatically through the Application process or during
conversion. For the automatic creation of student master records from data stored in a legacy
system, use function module BAPI_STUDENT_CREATEFROMDATA3.
Notes:
„
In the SLCM system you cannot create a student object without creating the respective Business
Partner. You can not create a Business Partner in the role of “student” without a student object.
„
You first have to perform the required basic customizing steps before you can create students.
„
You can create a Student from an existing Business Partner but you must have set up your number
ranges accordingly.
© SAP AG
IHE203
2-9
2. Master Data: Contract Account Structure
Business Partner
Business Partner
Contract
Account
Contract
Account
Contract Object X
Contract Object Y
Contract Object Z
© SAP AG 2010
The Contract Account is mandatory for financial activities. Contract objects are optional. That means,
in principle, business transactions in contract accounts receivable and payable can also be mapped out
without contract objects by means contract accounts.
„
You must assign at least one Business Partner to each contract account. Depending on the industry
or related business process, it may make sense to assign several Business Partners to a contract
account (NOT for students!)
„
The master data in a contract account can be divided into one part that is the same for all Business
Partners in the contract account (in other words, cross-business partner) and into another part that is
business partner-specific. You can set the Business Partner-specific data differently for different
Business Partners.
„
Contract Objects are optional and can be assigned to more than one Business Partner.
„
Contract Objects inherit control parameters from the contract account. However, some of these
parameters can be overwritten at the contract object level, e.g.: Invoice recipient correspondence,
incoming and outgoing payment methods, generating correspondence requests.
© SAP AG
IHE203
2-10
2. Master Data: Student & Contract Partner
Contract Accounting
Student Lifecycle Management
Student
Business Partner
Student
Account
Contract Object X
Contract Object Y
Contract Object Z
When a Student Business
Partner is created, ...
... accounting master data is
generated automatically
© SAP AG 2010
„
When you create a student business partner, the system assigns the roles Student and Contract
Partner automatically.
„
A student can have only one student (contract) account. The student is related to the account as
student account holder. You can define a sample student account by maintaining automatic
derivations in customizing. Use the IMG path: Student Lifecycle Management>Master Data in
SLCM>Students>Student Contract Accounts
„
Contract Objects can be generated automatically when creating the student (optional). You flag the
objects as Automatically created in Student Lifecycle Management Customizing.
„
Student and Business Partner data must be mapped so that it can be updated with each other
regularly. You do this in the IMG path: Student Lifecycle Management>Master Data in SLCM>
Student>Students as Business Partners.
„
For students and sponsors contract objects represent different university fee types.
© SAP AG
IHE203
2-11
2. Master Data: Automatic Student Account
Update (1 of 2)
„
„
„
„
Student account data can be automatically created and updated
„
When the student is created
„
When student infotypes are changed
Precondition: Basic customizing settings have been defined for student contract
account.
Attributes are populated according to customizing settings and student attributes
(nationality, student group)
You can implement further default settings using a BAdI.
© SAP AG 2010
„
Contract Accounts can use the following as default attributes:
• Contract account category and name,
• Relationship of business partner to contract account
• Company code and company code group
• Interest key
• Tolerance group
• Correspondence variant, correspondence dunning procedure
• Clearing category for clearing postings,
• Dunning procedure
• Lock reason for outgoing payments, incoming payment method, outgoing payment methods, and
due date schedule.
„
Contract Objects have their own name and can be used to have their own specific parameters, e.g.
due date schedule.
„
BADI HRPIQ00_ST_ACCOUNT is provided to implement customer-defined default logic.
© SAP AG
IHE203
2-12
2. Master Data: Automatic Student Account
Update (2 of 2)
„
„
General customizing setting for automatic account update:
„
SPACE: Create and Update deactivated
„
X: Creation and Update active
„
C: Creation active, Update deactivated
You can deactivate automatic account update for
„
Entire student account
„
For selected fields of the student account
© SAP AG 2010
„
Settings for the automatic account update are maintained in IMG path: SLCM>Master Data in
SLCM>Student Contract Accounts>(De)Activate Automatic Student Account Creation and
Update.
„
Whenever any of the student master data infotypes – Student Personal Data (infotype 1702), Student
Study Data (infotype 1705), Student Fee Calculation Data (infotype 1706) – and assigned
organizational unit (relationship 502) is changed either in dialog mode or in background mode, the
automatic account data update is triggered (see Table CMACBPSTCHG).
„
Synchronizing report RHIQ_ST_PERS_SYNC_CURR contains the following SAP standard
variants:
„
SAP&DEFAULT: Daily synchronization of student personal data and account data. It updates the
scheduled changes and failed updates.
„
SAP&UPDATE: Update of student account data after customizing has been changed. For example,
executing the synchronization report with this variant can create student account data if Deactivate
Automatic Update indicator is changed from SPACE to X or C.
„
System status “Account Data Not Updated” is generated if the update fails. Application log is stored
for further analysis. Report RHIQLOGDISPLAY_SYS displays the application log for automatic
account data update.
„
Report RHIQ_CHECK_CUSTOMIZING with application area SAP&ACCMASTER or
Transaction PIQCHKACCMASTER (Check Student Account Master Data) checks the correctness
of the customization.
© SAP AG
IHE203
2-13
2. Master Data: Financial Aid Sponsor
Student Lifecycle Management
FA Sponsor
Contract Accounting
Business Partner
Sponsor
Account
Grant 1
A FA sponsor...
Sponsor
Account
Grant 2
Sponsor
Account
Grant 3
... can use one account per grant or use
one account for multiple grants
© SAP AG 2010
„
Business Partners can have several contract accounts. In the account display, you can select either
one or all of them.
„
You can assign several contract objects to a grant account as sub-categories (for example, per year
or per specific conditions that apply).
„
Note: You should not set up each grant as a contract object on the sponsor side because it could
impair system performance.
© SAP AG
IHE203
2-14
2. Master Data: Business Partner
Requirements
„
One view on business partner
„
Central master data
„
One person, many processes
„
Business partner role concept
„
Connection to other persons
and entities
„
Business partner
relationships
„
Additional information for
specific tasks
„
Extensibility
„
Configurable
„
Well-defined interfaces
„
Adaptable screens
„
Cooperation with all existing
applications
Business Requirements
SAP Solution
© SAP AG 2010
„
A Business Partner in PSCD usually represents the person or legal entity that your institution
processes incoming and outgoing payments against. It is primarily the student but could also be
other entities such as parents (related persons), government agencies or the student’s employer
providing financial assistance.
„
Business Partners are the focus of business relationships. All relevant information must therefore be
available quickly.
„
The required information on the business partner depends on the situation. The system differentiates
the output from the database according to the role of the business partner.
„
Standard software is unable to provide highly specific information. Downstream developments (ERP
Core, development partners and customers) can add new attributes to SAP business partners. Such
extensions are release-independent.
„
Using the Visual Configuration Tool (VCT), users can configure Business Partner screens by
dragging and dropping elements. No modifications are required in the event of a release update.
„
To avoid problems with applications in existing system landscapes, interfaces must guarantee the
integration of business partners. SAP offers corresponding Business Application Programming
Interfaces or BAPIs for communication with existing applications.
© SAP AG
IHE203
2-15
2. Master Data: Business Partner Role
Definition
Role
Student
(PSCM10)
Contract Partner
(MKK)
Related Person
(PSCI10)
© SAP AG 2010
„
SAP Business Partner (SAP-BP) is the central business partner management tool of SAP.
Application neutral data such as name, address or bank information is stored in the BP master data.
„
A specific BP role is assigned to a business partner dependent on the business process; applicationspecific attributes are realized by way of role concept. Business partners must exist in role MKK in
Contract Accounts Receivable and Payable. You can define any number of BP roles in the SAP
business partner. A BP can have several BP roles. Every BP role can be assigned to a BP only once.
If you use business partner roles on a time-dependent basis, the MKK role 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.
„
In the standard delivery of SAP SLCM a new student is generated in 2 roles: as Student (PSCM10)
and as Contract Partner (MKK).
„
Whenever a business partner has a ‘is related to’ relationship with a student, the business partner
role Related Person (PSCI10) is automatically assigned to this business partner.
„
Note: If you need to make payments to the related person (for example, parent loans), you must add
the role Contract Partner (MKK) to the business partner to permit financial activity.
„
Financial aid sponsor have the standard role: Contract Partner (MKK).
„
Note: The role Sponsor (PSSP01) applies to a Grant Management sponsor (Research) and not to a
financial aid sponsor.
„
Business partner roles consist of building blocks (attributes) known as datasets, which appear as
little black boxes in the graphic and are maintained using BDT.
„
The SAP Business Partner offers an open infrastructure. This means that other components (ERP
Core, Industry components, components of development partners, and a customer own components)
can include their own application-specific business partner data.
© SAP AG
IHE203
2-16
2. Master Data: Summary of Control
Parameters in Master Data
Business Partner
Open Item Management
Payment
Address(es)
Bank data
Payment card
Contract Account
Contract Object
Which address?
(Bank details ID)
Bank details ID
(Payment card ID)
Payment card ID
(Payment method)
Payment method
Alternative payer/payee
(Alternative payer/payee)
Payment Lock
(Payment Lock)
Correspondence Control
(Correspondence Control)
Correspondence Variant
(Correspondence Variant)
Alternate/add. Recipients
(Alt./add. Recipients)
Posting rules/Lock
Inbound Correspondence
Dunning/Lock
Dunning control/Lock
Invoice Type
Interest Calculation/lock
Dunning Lock
Separate bill creation Lock
Clearing Control
Control Parameters
© SAP AG 2010
„
This graphic shows the control parameters set at business partner level, contract account level and
contract object level.
„
All terms written horizontally are control parameters.
„
The terms: Business Partner, Contract Account, and Contract Objects are objects.
„
The terms: Payment and Open Item Management represent processes.
„
The control parameters to the right of “Payment” (vertically) are used in the Payment process. All
others are used in the various “Open Item Management” processes such as dunning, correspondence
generation, clearing etc
„
Most processing control data can be contained in the contract object relationship.
„
Many of the control parameters in the figure can be overridden or extended by data contained in
posting documents. For example, the payment/dunning methods can be determined in the line item.
„
Note: By setting the appropriate field indicator in the contract object, you control whether the
payment parameters defined in the contract object or in the contract account are used. Payment
parameters in a document still have priority.
© SAP AG
IHE203
2-17
2. Master Data: Business Partner: Category
and Type
Person
Group
Organization
BP Type
Business
Partner
BP Category
Student
Sponsor
Business
© SAP AG 2010
„
BP Category is used to classify a business partner as a natural person (for example, student) or as
an organization (for example, government agency). The category determines which fields are
available for data entry. For example, when you create a Business Partner as a person, you maintain
a first and last name and other personal information such as gender. These attributes are not
appropriate for a Business Partner representing an organization.
„
Students and Related Persons can only be created with the category Person.
„
When a BP is created, the BP Category must be selected (required entry) and controls the number
assignment. The assignment of the business partner category is static and cannot be changed after
the Business Partner has been created.
„
BP Type allows an institution to group business partners, e.g. students, related persons, sponsors,
etc. When maintaining BP master data, the BP Type controls which fields on the business partner
master record are mandatory, hidden, displayed, or optional based on the settings of the Field Status
definitions.
„
When you create a Business Partner, the BP Type data field is on the initial screen and in the control
data screen. When you change or display a Business Partner, this field is in the control data.
„
You can define a BP Type as default in Customizing, e.g., BP Type = “ST” is always set when
creating a student as business partner.
© SAP AG
IHE203
2-18
2. Business Partner: Grouping
Person
Group
BP Type
Business
Partner
BP Category
Organization
Resident
Business
Grouping for
1. Reports
2. Field modifications
3. Screen variants
Non-Profit
© SAP AG 2010
„
A business partner group classifies business partners according to criteria that the user can freely
define. The procedure in customizing includes these steps:
„
Definition of number ranges for the business partners
„
Definition of groupings for the business partner and assignment of number ranges
„
In customizing you can also make settings for standard grouping. These settings cause a group to be
automatically selected if you do not assign a business partner number or a group when you create a
business partner (in the event of internal number assignment) or if you assign a business partner
number to a business partner, but not a group (in the event of external number assignment).
„
Number range intervals and the type of number assignment are defined for each number range:
„
Number assignment is either external or internal.
„
Number range intervals determine which numbers are permitted.
„
Note: Remember to consider financial aid sponsors, grant management sponsors and related persons
when designing the number ranges.
„
Business partner number ranges apply to all clients. The standard SAP ERP system contains number
ranges for the groups provided. These number ranges can be changed to suit your organization.
„
A student can be created from an existing business partner who represents a person.
© SAP AG
IHE203
2-19
2. Master Data: Contract Account - Structure
and Function
Contr. Acc. Category
Contract
Account
= Grouping for:
1.
General Data
CA
name
Management Data (Interest, Clearing)
Account
2.
Payments
Payer
Incoming/Outgoing:
3.
Bank, Card, Payer, Lock
Dunning/Correspondence
Invoicing
Dunning
Correspondence control/dunning/lock
Additional/alternate
recipients
© SAP AG 2010
„
A Contract Account is a container to store financial postings. Different types of contract accounts
can be freely designed. The number of different contract account types within a company is
sometimes determined by the number of different dunning procedures or tolerance groups.
„
The Contract Account Category determines the following contract account attributes:
„
Whether you are allowed to assign the contract account to only one business partner
„
Whether you are allowed to assign only one contract or more than one to a business partner
„
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.
„
Cross-partner data: The contract account is managed under this key in the SAP ERP system and in
an operational system.
„
You can use method BAPI_CTRACCOUNT_EASYCREATE to create a contract account with
sample values for external creation of contract account.
© SAP AG
IHE203
2-20
2. Master Data: Contract Account: Company
Codes (1 of 2)
Contract Account
General data Payment / Taxes Dunning/Correspondence
Payment data / General
Company Code Group :
BS01
Standard Company Code : BS02
Payer :
Paid by :
Owner bank details :
N:1
BS01: Group Company Code
N:1
Mandatory
BS04: Paying Company Code
BS01: Company Code
BS02: Company Code
BS03: Company Code
© SAP AG 2010
„
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 BS01,
BS02, and BS03, and group G2 that consists of BS01 and BS03.
„
Using 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.
© SAP AG
IHE203
2-21
2. Master Data: Contract Account - Company
Codes (2 of 2)
Company Code Group:
Includes all company codes that are permitted for posting to a contract account.
„
Paying Company Code:
Is responsible for payment transactions. House banks and payment methods have to
be defined per paying company code.
„
Standard Company Code:
Used for all postings for which no company code can be determined by other means.
„
© SAP AG 2010
„
The Paying Company Code is always assigned to each company code group. 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 than
the paying company code determined via the contract account, you must also specify a payment
method in the line item. In this case, you cannot use the payment methods from the contract
accounts because they refer to a different country.
„
One Standard Company Code is assigned to every 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).
Note:
You must define the company code in the info type “Account Assignment” in the Top Org Unit defined
in SLCM.
© SAP AG
IHE203
2-22
2. Master Data: Contract Object - Master Data
Structure
Business Partner/Contract Account
A/P and A/R Data
1.
2.
3.
4.
Contract Object
1. Administration Data
Object number
Object type
Short text
2. Basic Data
Relationship data
Payment data
Correspondence
Inbound
correspondence
Contract Object
Category
BDT
Business Partner independent
© SAP AG 2010
„
In the Business Data Toolset, you define the data structure of a contract object type, which is
referred to as the Contract Object Category. In the context of the Business Data Toolset, category
is a synonym for business partner role (BP role).
„
SAP delivers the following contract object categories:
„
PAAC – with access to business partner and contract account
„
PSOB – without access to business partner and contract account
„
PSDD – with access to BP, contract account and due date schedule > used only by SLCM
„
In contract accounting, contract objects types are not required. Caution: Data cannot be changed
after postings are made.
„
Additional note regarding the following slide: You can flag individual records on contract account
data assigned to a contract object as obsolete, thereby excluding them from further contract object
processing (e.g., TA PSOBWORK).
Before you set this indicator, make sure there are no open items or open inbound correspondence on
the specified record for contract account data (in other words, for the specified BP, contract account
category and contract account). On the on the Basic Data tab, select Obsolete in the Administration
Data screen area. The data records on contract accounts flagged as obsolete are hidden from all F4
help and overview lists for contract objects. Administrators are responsible for processing such
entries in Transaction PSOBWORK (Edit Contract Object), they must have special authorization
with F_KK_SOND for Activity 24. You can process obsolete contract account data under: Extras
→ Administ. → Show Obsolete Data or Hide Obsolete Data.
© SAP AG
IHE203
2-23
2. Master Data: Contract Object - Configuration
Contract Object Type
Basic Data
Contract Object
Business Partner 1
Business Partner 2
Contract
Account
Contract
10
Account
20
© SAP AG 2010
„
You specify the name of the contract object and contract object type to which it is assigned in the
basic data. A contract object type determines a contract object’s grouping characteristics. You
determine the attributes of a contract object category in the Contract Accounts Receivable and
Payable Customizing.
„
Contract objects can be differentiated using contract object types.
„
You can create a contract object directly or use an existing template or a sample which is defined in
customizing. This takes you to the Contract Object screen:
„
Enter the name of the contract object in the basic data and choose A/R and A/P Data with or without
sample. This takes you to the accounts receivable and payable processing screen for the contract
object. For using A/R and A/P data, use a contract object type with category PSDD (customizing).
„
On the Basic Data tab, specify a partner relationship by assigning a BP and a contract account
category. There you can create a new business partner and contract account if necessary.
„
If you want to have a different control logic for the contract object from the one assigned in the
contract account, proceed as follows:
• To define an alternative correspondence control, select Activate Correspondence Parameters for
Contract Object on the Correspondence tab and specify the correspondence data you require.
• To define alternative invoicing, select Activate Correspondence Parameters for Contract Object
and Separate Invoicing on the Correspondence tab and specify an invoice type.
• To define an alternative payer or payment recipient, select Activate Correspondence Parameters
for Contract Object on the Payment Data tab and enter the relevant BP.
© SAP AG
IHE203
2-24
2. Master Data: Check Digits
Check digits allow for the validation of
„
Business Partner numbers
„
Contract Account numbers
„
Contract Object numbers
Prerequisite: Internal numbering must be used.
© SAP AG 2010
„
Check Digits are used to validate contract account and business partner numbers. They may be used
in conjunction with incoming payments, for example. In order to use check digits, numbering of
contract accounts and business partners, respectively, must be internal
For example, if a customer sends in a payment for his account and s/he has entered his contract
account number in the note to payee field incorrectly, the check digit algorithm has the ability to
automatically correct the error (assuming the error does not involve several numbers). SAP does not
provide the algorithm but does provide the necessary events.
„
Business Partner: You add the check digit procedure using Event 1051. Sample Function Module
FKK_SAMPLE_1051_2_CHECKDIGITS for two check digits is supplied by SAP.
„
Contract Account: Leading check digits can be used when creating contract accounts and may be
one or two digits long. Event 1019 and function module
FKK_SAMPLE_1019_2_CHECKDIGITS (delivered sample function module that uses two check
digits) is used for contract account check digit processing.
„
Contract Objects: With a customer enhancement, you can implement a check digit procedure for the
contract object numbers. For more information, see the example Function Module
FMCA_SAMPLE_P500.
„
SAP offers an interpretation rule for contract objects based on the Modulo 11 method
(FMCA_MODULO11_DIGIT_P500). This method can be used to interpret the note to payee on
the electronic bank statement.
© SAP AG
IHE203
2-25
2. Master Data: Locks
Business Locks can be entered on the level of a
„
Contract Account
„
Contract Object
„
Line Item
Business Locks can be set for an unlimited or a limited period.
Mass Locks can be
„
Set (transaction FKLOCK2)
„
Deleted (transaction FPLKDEL)
© SAP AG 2010
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 (optional > see arrow). Once this limit has expired, the locks are
deactivated.
„ You can generate a list of Business Locks In the Easy Access Menu using the path:
Accounting>Financial Accounting>Contract Accounts Receivable and Payable>Periodic
Processing>For Contract Accounts>Evaluation of Processing Locks or Transaction: FPLKA. The
results 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 (Set Processing Locks) or via the
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing >For Contract Accounts>Set Processing Locks.. 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.(Delete Mass Locks Set).
Note:
„ If you have set multiple or time-limited locks, only a ~ will be shown in the Lock field. In this case,
choose the arrow key to display the locks.
„
© SAP AG
IHE203
2-26
© SAP AG
IHE203
2-27
2. Master Data: Payment Transactions
Use Transactions BP or FPP4 to maintain a Business Partner’s bank
account and/or payment card
© SAP AG 2010
„
Transaction FPP4 (Maintain Payment Data) makes changing Business Partner-related bank data
easier. In the Maintain Payment Data transaction, you can, for example, change the bank details of a
customer who changes from being a cash payer to a direct debit payer simultaneously in the business
partner master record and in dependent objects, such as the contract account.
„
The Bank Institution (Bank Key) has to exist or must be added to the bank directory before a bank
account at that institution can be added to the business partner.
„
You can also control follow-up actions, such as reversing dunning notices, by using flexible rules.
„
If you select Create Bank ID in the client-specific settings in Customizing, in event 1053 you can
determine new bank details ID for the business partner concerned.
„
If you select Create Credit Card ID in the client-specific settings in Customizing, in event 1054 you
can determine a new payment card ID for the business partner concerned.
„
With a Function Module processed in Event 1083, you can make additional changes to the contract
account when you save the data. In this event, you can, for example, change the Planning Group
field in the contract account if a customer changes from being a cash payer to a direct debit payer.
© SAP AG
IHE203
2-28
2. Master Data: Payment Transactions
Payment Transactions are configured under Cross-Application Components
„
„
Bank Directory
Payment Cards
SAP offers tools to encrypt the payment card number, log access of unmasked numbers
and mask some of the numbers to comply with the Payment Card Interface Guidelines
(PCI) which outlining security and privacy concerns regards storing and using payment
cards.
Refer to SAP Note 1032588 - Secure handling of credit card data in ERP
card number.
Example:
© SAP AG 2010
„
For security reasons, North American universities refrain from storing payment card information
with the business partner’s master data. Instead, the payer has to enter the card information at time
of payment. The card number can be stored with the document in encrypted form.
„
The functionality for secure handling of credit card data (see note 1032588) includes:
• General customizing settings for secure handling of credit card data
• All ERP applications support masked display on the UI
• All ERP applications support encrypted storage on the database
• All ERP applications support logging of access to unmasked data
• Various migration programs for existing encrypted data
• Migration program for credit cards stored on SAP Business Partner level
„
See also note 1151936 for additional information on the subject (Periodic key exchange).
© SAP AG
IHE203
2-29
2. Master Data: Unit Summary
You should now be able to:
„
Create business partners, contract accounts, and contract objects in the
system
„
Use central address management
„
List possible master data relationship scenarios
„
Apply master data control parameters at desired levels
© SAP AG 2010
© SAP AG
IHE203
2-30
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
3-1
3. Fee Calculation Process: Overview
Content
Fee Calculation Process Overview
Audit of Fee Calculation
Fee Calculation relevant Master Data
Fee Calculation relevant Periods and Dates
© SAP 2008
© SAP AG
IHE203
3-2
3. Fee Calculation: Unit Objectives
At the conclusion of this unit, you will be able to:
Describe the fee calculation process and the audit of fee calculation
Explain the parameters and data that influence the calculation of fees
Describe where this data is maintained
Identify which dataset is relevant when data changes during an academic
session
Explain the derivation of due dates and the use of time limits
© SAP AG 2010
© SAP AG
IHE203
3-3
3. Fee Calculation Process: Business Scenario
Your institution charges tuition. The tuition fee could be a flat fee depending
on the program the student is registered in. Alternatively, the tuition fee
could depend on the total of attempted credit hours. Additionally, students
enrolled in a specific course or section may have to pay for course material.
Employees get a 10 percent discount on tuition fees but not on the
additional fee charged for course material.
Your institution may offer various meal plans for which the student is
charged.
© SAP AG 2010
© SAP AG
IHE203
3-4
3. Fee Calculation Process: Example
Tuition Fee: 2000
= 20 crh * 100
+
Course Mat:
= if SM = HIST 101 G00
+
Employee:
+
Meal Plan:
300
= 5 meals per week
___________________________________
=
Total:
50
-200
= 10 % discount of tuition
2150
© SAP AG 2010
© SAP AG
IHE203
3-5
3. Fee Calculation Process: Data Retrieval and
Calculation Rules
Student Master and Registration/Enrollment Data
SC
TUIT:
EMPL:
ST
SM
SM
SM
yes
TUIT:
20 CRH
CMAT:
HIST = yes
EMPL:
yes
MEAL:
5 per week
IMG
+/- $$
- 10 %
4000
-400
*100
+2000
50
+50
- 10 %
-205
300
+300
© SAP AG 2010
© SAP AG
IHE203
3-6
3. Fee Calculation Process: Overview
Start FC run
1
DB
Retrieve data
2
calc
Display result
Enter changes
Calculate fees
1000 UNI
3
post
Post fees
1000 UNI
© SAP 2008
When the system calculates fees for a student, it goes through the following main steps:
• It accesses the student's Master Data, Program of Study, Module, etc; according to your
specifications.
• It calculates the student’s fees using the fee calculation program in Student Accounting. It
displays the results; you can enter adjustments if necessary.
• It posts a financial document in FI-CA and a fee calculation document in Student Lifecycle
Management.
Note: Before starting the fee calculation run, you can also choose to post the fees directly by
selecting the radio button “Post Directly”.
If you do a mass run over a range of students, the result is not displayed and you cannot enter
adjustments. However, the fee calculation document numbers are shown after the run. You can go to
the application log and perform a fee analysis for a single student. You will also see the result in the
account display of the student‘s account.
© SAP AG
IHE203
3-7
3. Fee Calculation Process: Step 1 - Calculate
Fees
Start FC run
Retrieve Parameters
Check Requirements
Do Calculation
...
1000 UNI
Display Result
© SAP AG 2010
To ensure high performance, the fee calculation does not access the student‘s account to compare
the calculated fee with previous fee postings. A delta amount is not calculated; the total fee amount
is always calculated.
© SAP AG
IHE203
3-8
3. Fee Calculation Process: Step 2 - Post Fees
1000 UNI
Display result
Check Student Account
Calculate delta amount (if
necessary)
Derive due date(s)
Find Account Determination
...
post
1000 UNI
if 200 UNI posted previously:
800 UNI
© SAP AG 2010
The account is checked only in the second phase. If necessary, a delta amount is posted.
Note: If the delta amount equals 0, no financial document will be posted. However, a fee calculation
document will still be posted for audit purposes.
SAP delivers a BAdI to modify the default delta posting created in fee calculation according to your
institution’s requirements.
To find the BAdi, use the IMG path: Student Lifecycle Management>Student Accounting >
>Fees>Posting.
© SAP AG
IHE203
3-9
3. Fee Calculation Process: Step 3 - Audit
(1 of 2)
Fee Calculation produces:
Financial Documents -> Contract Accounting
Fee Calculation Documents -> Analysis & Invoicing
Fee Calculation History
Header:
Student data, fee calculation parameters and final result including manual adjustments
Positions:
Snapshot of the current schedule (modules and programs) -> all fields of field catalogue
FI-CA documents:
New and old documents, documents for manual corrections
Price per item (optional)
The condition records are not stored
© SAP AG 2010
In addition to the financial documents for Contract Accounting, the fee calculation also creates fee
calculation documents. These documents form the basis of the Fee Calculation History, which
provides an audit trail of successful fee calculation runs. The collection of stored information allows
a detailed analysis of mass runs.
The information is also useful when an invoice needs to include academic information such as
program of study or modules for which the student is billed. SAP delivers correspondence type
Public Sector Invoicing (P004) which is based on FI-CA form class (FMCA_INVOICE). SAP also
supplies Function Modules to read the audit information in user exits. Both together could be used to
develop invoices including registration/booking data.
Note: Before you use the audit feature, you need to set up the necessary configuration. Use the IMG
path: Student Lifecycle Management>Student Accounting>Fees>Posting.
Storing the price per item may be irrelevant for institutions with fee caps. In the standard delivery,
this feature is turned off.
The condition records are not stored in the Fee Calculation History. The information is already
stored by date in the condition records.
Recommendation: Always include the validity period (start and end dates) when defining condition
records.
© SAP AG
IHE203
3-10
3. Fee Calculation Process: Step 3 - Audit
(2 of 2)
Fee calculation documents are created for successful runs.
Exclusions:
Runs with errors and simulation runs
Only the data used in the fee calculation are stored; the results are not stored.
When the user initiates the fee analysis for a particular student, the result is recalculated
based on the stored pricing information.
Therefore…
Avoid changing the Pricing and Fee Calculation procedures after use in production.
Use the validity dates in the Condition Records
© SAP AG 2010
The fee calculation document header contains the overall result including manual adjustments.
A fee calculation run may not always result in fee calculation documents and financial documents
(FI-CA).
• Example: When the delta amount of a real fee equals 0, a fee calculation document is created but
no financial document is created.
The fee calculation history can be accessed from the Easy Access Menu under: >Student Lifecycle
Management >Student Accounting>Fee Calculation> Fee Calculation History.
© SAP AG
IHE203
3-11
3. Fee Calculation Process: Details
Application log and fee calculation history are filled by executing Fee Calculation.
The Fee Calculation results vary
based on your choices
© SAP AG 2010
Before you see any information in the application log or the fee calculation history, you have to
execute the fee calculation.
You can also initiate fee calculation for an individual student directly from the student file (use the
Calculator icon).
© SAP AG
IHE203
3-12
3. Fee Calculation Process: Transaction
Student
File
Relevant Period/
Session
post as
real open item ?
study related
Master Data
Stdt Group
Stdt Fee Cat
Stdt ID
Selection
Method
Crocessi
alc Triggen
rg
Fee Group
Calcu
lation Fee P
Base calculate/post
Mode !
calculate/post !
Date
Calculation
Date
Stdt Org ID
Fee Calc Proc
© SAP AG 2010
Calculation Base: Admission Application Data or Study Data (hard-coded)
Admission Application Data: You can use application data as a fee calculation base only if an
application for admission exists in the system for the given student and this application has the
status created.
Study Data: You can use study data as a fee calculation base only if a sessional program registration
exists in the system for the given student. The system also considers cancelled sessional registrations
and prior period registrations for expected re-registration.
Processing Mode: You can select one of the following modes in Customizing. Use the IMG path:
Student Lifecycle Management>Student Accounting>Fees>Basic Settings>Set Up Processing
Modes for Fee Calculation.
• Admission (calculation base: Admission Application Data)
• Registration/Module booking (calculation base: Study Data)
• Anticipated (Re-)Registration (calculation base: Study Data)
Posting Mode: actual or statistical posting. The admission fee must be actual.
Fee Calculation Date: Derives all time-dependent data. When executing a fee run, the system
automatically chooses the period that is valid on the calculation date. The fee calculation period
might differ from the duration of the academic session.
© SAP AG
IHE203
3-13
3. Fee Calculation Process: Wait Listing
Note regarding the inclusion of wait-listed bookings in the fee calculation or grant
evaluation:
Some institutions allow students to book on a waiting list when a course or section is
full. As students cancel out of the class, students on the wait list move up and may
get a seat.
SAP standard delivery excludes wait-listed bookings!
>>> This can be changed in the IMG.
Consider carefully the implications when wait-listed bookings are switched to
confirmed bookings.
© SAP AG 2010
To adjust the standard setting, use the IMG path: Student Lifecycle Management>Student
Accounting>Basic Settings>Include Waiting List Bookings in Student Accounting. Create the
required entry for the Group/Setting; MODREG/WLFEEC:
Value X: Waiting list bookings are included in fee calculation and grant evaluation
Value " " (blank): Waiting list bookings are filtered, and not included in fee calculation and grant
evaluation
The fee calculation and grant evaluation programs recognize bookings with an X in the field
CMSMWAITLIST as waiting list bookings.
If your institution uses the wait listing feature then carefully consider the impact on fee calculation
rules and due date since the booking date remains the initial date the booking was wait listed.
© SAP AG
IHE203
3-14
3. Fee Calculation Process: Study-Based Fees
- Relevant Master Data
Student
Fee Calc. Rel. Data
Student Master Data
ST
SC
Student File
CS (Study)
CG
SM
SE
IMG
IMG
Fee Calc. Rel. Data
Fee Calc. Rel. Data
IMG
Fee Calc. Rel. Data
IMG
© SAP AG 2010
You can use most of the student master data and the academic structure to calculate fees (see the
“Fee Calculation Configuration” unit).
Before you assign any fee calculation-relevant data to ST, SC, CG, SM and SE, you have to define
the possible values using the IMG path: Student Lifecycle Management → Master Data in SLCM →
ST, SC, CG, SM, SE → Fee Calculation Data.
The Event Package is an extension of the module and does not stand on its own.
the relevant data is within the booking record (Relationship 506/Additional Data).
This means that
Note: Business Event (E) is not considered in the Student Lifecycle Management fee calculation.
The event-related data in the SD pricing catalog refers to HR Training and Event Management.
© SAP AG
IHE203
3-15
3. Fee Calculation Process: Student Master
Data (ST)
Differentiator without
any underlying
functionality; can be
used as characteristics
in pricing
IMG: Student Lifecycle Management
Master Data in SLCM
Students
Fee Calculation Data
© SAP AG 2010
Student Fee Category: Most student fees are influenced by the student's residency status or
nationality. There are different rates for resident/national students and non-resident/international
students. You can customize your fee categories accordingly using the KOMK-CMSTCAT field in
the condition table. This field can be used for checking before accessing that condition type; refer to
“Requirements“ slide.
You can also use the student group, KOMK-CMSTGRP, as differentiator.
Benefit category: According to the benefit category, a lower tuition fee is charged or part of the fee
is waived, for example, for an employee use the KOMP-CMBENCAT field in condition table.
Personal Discounts/Surcharges: For meal plans, housing tariffs, tutor fees, use KOMPCMPDISCT1 to KOMP-CMPDISCT6.
Note: There is no Due Date Schedule on the student master file. You define it on the student account
and, if required, also on the Contract Objects (see the “Due Date Schedule” unit).
Note: As of EHP 5, it is possible to maintain fee calculation data via mass assignment of the student
group/fee category report. The mass processing report now allows to set all the fields in the fee
category infotype. With this, Benefit category and 6 discount/surcharge fields can be set.
© SAP AG
IHE203
3-16
3. Fee Calculation Process: Program of Study
Data (SC)
Differentiator without
any underlying
functionality; can be
used as characteristics
in pricing
Derives due dates (see
the Posting unit)
IMG: Student Lifecycle Management Master Data in SLCM Academic Structure
Programs of Study Fee Calculation Data
© SAP AG 2010
Program Fee Category can be used as characteristic in pricing. Example: graduate and
undergraduate programs of study.
Credit Threshold determines the fee calculation mode if the pricing is configured accordingly (with
customer programmed requirement). Example: Below the credit hours, the tuition fee is calculated
per module. Above the credit point/module fee threshold, the tuition fee is calculated per program of
study. Use the KOMP-CPTHD field in the condition table.
Module Fee Calculation Threshold determines the fee calculation mode if the pricing is
configured accordingly (with customer-defined requirement). Example: Below the credit hours, the
tuition fee is calculated per module. Above the credit point/module fee threshold, the tuition fee is
calculated per program of study. Use the KOMP-CMFVALTHD field in the condition table.
© SAP AG
IHE203
3-17
3. Fee Calculation Process: Module Group
Data (CG)
Differentiator without
any underlying
functionality; can be
used as characteristics
in pricing
IMG: Student Lifecycle Management
Master Data in SLCM Academic Structure
Fee Calculation Data
Module Groups
© SAP AG 2010
Module Groups Fee Category can be used as characteristic in pricing. Example: student enrolled
in a specific Master must pay an additional fee.
During fee calculation, the system determines all the module group bookings of a student. It first
selects all module group bookings that belong to the module group category which is flagged in
Customizing. If a student has booked more than one module group in this module group category,
the system uses the module group with the highest priority in the Priority field.
The fee calculation program can only process one module group booking. If the defined module
group booking does not satisfy your requirements, then you can define the module group booking
using the BAdI for Pricing in Student Accounting (CMAC_BADI_PRICING). This is supported in
the method Set_All. For more information, see the BAdI documentation.
Example:
• In a Program of Study that has two Minors and one Major, you would like to charge fees only for
the Major.
• You first define a Fee Category for the Major. Then you create an entry in this Customizing table
for the program-specific Module Group Variant and the associated Module Group Category.
• Module Group Variant
• 1 Major + 2 Minors
© SAP AG
Module Group Category
Major
IHE203
3-18
3. Fee Calculation Process: Module Data (SM)
Differentiators without
any underlying
functionality; can be
used as characteristics
in pricing
Measure Unit
customizing
Derives due dates (see
Posting unit)
IMG: Student Lifecycle Management
Master Data in SLCM
Fee Calculation Data
Academic Structure
Modules
© SAP AG 2010
Module Fee Category can be defined as half, full, or double of the credit value. Use KOMPCMSMCAT field in condition table.
Levy Fee Category example: 001 = special fees for supplementary course materials; 002 = nonrefundable fees. Use KOMP-CMLEVCAT field in condition table.
Module Refund Type is used to define refund rules according to the duration of a module or the
credit hours/value. Use KOMP-CMREFTYPE field in condition table.
Module Value can be calculated in the following different ways:
• The tuition fee can be calculated on the basis of the number of credits assigned to the module.
This can be the minimum, optimum, maximum or attempted number of credits.
• The tuition fee can be calculated on the basis of the module value. This can be the number of
class hours, for example.
If you want to calculate fees on the basis of the module value instead of on the number of credits,
you must specify a unit of measure for the module value. First, you have to set up (or choose) a nondimensional unit of measure using the IMG path: SAP NetWeaver> General Settings>Check Units
of Measurement. Do not use the same name for the module value and the unit of measure for
credits. Use KOMP-CMSMVALUE field in condition table.
© SAP AG
IHE203
3-19
3. Fee Calculation Process: Event Package
Data (SE)
Differentiators without
any underlying
functionality; can be
used as characteristics
in pricing
Derives due dates (see
Posting unit)
IMG: Student Lifecycle Management
Master Data in SLCM
Academic Structure
Event Packages
© SAP AG 2010
Event Category 1:
• Example: HONO = a surcharge on SE packages considered for Honors work
• KOMP-CMSMSECAT1 field in condition table
Event Category 2 (Special Fee Category): Currently not available but planned for future releases
© SAP AG
IHE203
3-20
3. Fee Calculation Process: Overview of Dates
in Student Accounting
Fee Calculation Date (Entered in Fee Calculation User Interface)
=> Fee Calculation Period
Key Date (Setting in Customizing) and Academic Year & Session
=> Relevant date to read data for the fee calculation
Booking/ Cancellation respectively Registration/ Deregistration Date
=> Registration/ Refund Periods
Academic Year and Session
=> Installments/ Due Date for the fee
System Date (today)
=> Posting Date = Document Date
© SAP AG 2010
© SAP AG
IHE203
3-21
3. Fee Calculation Process: Periods - Business
Purpose
The Fee Calculation Period in Student Accounting is used for various purposes:
Fee Calculation:
The fee calculation periods are derived from the fee calculation date. The academic
years and sessions are derived from the fee calculation period.
Pricing:
Used for pricing based on different currencies. The fee calculation period determines
the translation of different currencies.
Posting:
Links to the period key (PERSL) of FI-CA.
Due Dates:
Due date schedules are maintained per fee calculation period, that is, for each fee
calculation period, you can set up the time limit sequence, the exception amount, the
due date schedule details and the exception rules.
© SAP AG 2010
Use the IMG path: Student Lifecycle Management → Student Accounting → Basic Settings → Fee
Calculation Periods.
You define the fee calculation periods and assign them to the academic year and session.
Note: You can assign one or more academic sessions to a fee calculation period.
You also enter the exact start and end dates for each fee calculation period.
Note: Do not look for it in the academic calendar.
When executing the fee calculation run, the system automatically chooses the valid period(s) based
on the fee calculation date you entered.
If the system finds more than one period, it will execute and display the calculation result for each
period separately. It will also create separate documents.
Note: The fee calculation period is not identical to the posting/fiscal period in FI.
© SAP AG
IHE203
3-22
3. Fee Calculation Process: Periods (1 of 2)
Time reference for fee calculation, posting and processing
IMG
You calculate a fee with reference to a certain period in the academic calendar. Therefore, you
define a Fee Calculation Period using any four-character key and assign to it one or more:
Academic Year
2009/2010
Academic Session
Fall Semester, Summer Session
The fee calculation period key is also used to assign payments.
© SAP AG 2010
You can assign one or more years and sessions to a period. Normally, you will assign one year and
one session to a period.
In the last step you define exact start and end dates for each period (do this in the IMG, and not in
the Academic Calendar). Chose the IMG path: Student Lifecycle Management>Student
Accounting>Basic Settings>Fee Calculation Periods>Maintain Fee Calculation Periods.
When calculating a fee, the system automatically chooses the period that is valid on the calculation
date. The calculation period might differ from the duration of the session.
If the system finds more than one active period, it will execute and display all calculations.
© SAP AG
IHE203
3-23
3. Fee Calculation Process: Periods (2 of 2)
1. Reference to an academic session (PERSL)
2. Trigger for choosing the valid fee calculation method
Key Date
IMG
Key Date
Spring Fee Calculation Period
Fall Fee Calculation Period
Fall Semester
Spring Semester
Academic Year
Calculate fees for
Fall and Spring
Calculate fees
Spring only
© SAP AG 2010
A fee calculation period identifies a combination of academic years and academic sessions. For each
fee calculation period, you must maintain the begin and end dates and, if appropriate, the currency
exchange rate type and the translation date for each fee calculation period, and the sequence of the
fee calculation periods. During pricing, if different currencies appear, the SAP system uses different
exchange rates and dates for different fee calculation periods.
Note: You can specify the start and end dates for each fee calculation period according to your own
requirements. You can have time gaps between time intervals and overlaps. If the SAP system
derives more than one fee calculation period, it calculates the student's fee for each calculation
period. The fee calculation results are displayed and posted separately.
The SAP system can estimate the fees for a student based on the student’s fee calculation
information in the previous fee calculation period. To achieve this, you must specify which fee
calculation period is the previous period for the current period. The SAP system can find the
corresponding academic years and sessions that should be taken into account for the data selection.
© SAP AG
IHE203
3-24
3. Fee Calculation Process: Periods Technical View
A Fee Calculation Period is identified by a four-character key, which is also the
period key included in the financial posting.
You can enter a description for each fee calculation period.
Per.
Description
AY08
Academic Fee Year 2008
AY09
Academic Fee Year 2009
A Fee Calculation Period has a begin date and an end date. Enter exchange types
and appropriate translation dates if your institution works with multiple currencies.
To calculate estimated fees, enter the previous period to establish a sequence.
Period key
Begin date
End date
Exchange Rate
Transl. Date
Prev.
Per.
AY09
1.1.2009
31.12.2009
Average exchange
rate
31.1.2009
AY08
AY08
...
...
...
...
...
© SAP AG 2010
A sequence number is available in the table for maintaining fee calculation periods. This sequence
number is currently set to 1. In the future, this sequence number might be used to assign multiple
begin/end dates to the same period. This functionality is currently not supported.
© SAP AG
IHE203
3-25
3. Fee Calculation Process: Periods Technical View
Assign a fee calculation period to each academic year/session combination.
A fee calculation period can consist of several academic year/ session
combinations, but only one period is assigned for each academic year/session
combination.
Academic Year/Session Combination
Period Key
Academic Year 2009/ First Semester
AY09
Academic Year 2009/ Second Semester
AY09
Academic Year 2009/ Summer Session
AY09
© SAP AG 2010
Academic years, academic sessions and the valid combinations are maintained using the IMG path:
Student Lifecycle Management → Master Data in SLCM → Academic Calendars → Academic
Years and Sessions
Academic year/session combinations are assigned to fee calculation periods in IMG path:
Student Lifecycle Management → Student Accounting → Basic Settings → Fee Calculation Periods
→ Assign Academic Years and Sessions to Fee Calculation Periods
The system automatically shows all defined valid academic year and session combinations.
© SAP AG
IHE203
3-26
3. Fee Calculation Process: Periods - Begin
and End Dates
When you start a fee calculation in Student Lifecycle Management, you enter a fee
calculation date and a period key which is optional. If you only enter the fee
calculation date then the system checks it against the begin and end dates of each
fee calculation period and calculates for all open periods. It is better to enter a
period key to improve performance and reduce messages.
Call Fee Calculation
Later or equal
Begin Date and
Earlier or equal
End Date
Fee Calculation Period 2
Fee Calculation Period 3
Fee Calculation Date
Fee Calculation Period 4
Fee Calculation Period 5
Period Key
Fee Calculation Period 6
© SAP AG 2010
For each fee calculation period, the pricing is accessed separately and the fee is posted in a separate
document.
The fee calculation date is still required and is defaulted with the system date.
When you press F4 for the period key you get all period keys valid at the fee calculation date and
can choose one. The fee calculation runs then only for that single period key. If no period is selected
it will run for all open periods and produce messages for the periods without registrations.
When the calculation date is empty and you press F4 for the period key you get all period keys
which are available. When you choose one automatically the calculation date is set to the begin date
of the period key.
© SAP AG
IHE203
3-27
3. Fee Calculation Process: Periods Academic Year & Session Combinations
From a fee calculation period, the system derives the academic year/session
combinations as defined in Customizing. In Fee Calculation, the fees for the derived
academic years and sessions are calculated.
Several academic year/session combinations can be assigned for one fee calculation
period. For one academic year/session combination, there is only one fee calculation
period.
Summary: Fee Calculation Period => Academic Year/Session Combination(s)
Acad. Yr 2009, First Semester
Call Fee Calculation
1.2.2009 – 30.6.2009
Acad. Yr 2009, Summer Session
Fee Calculation Date 10.10.2009
1.7.2009 – 31.8.2009
Fee Calculation Period AY09
Acad. Yr 2009, Second Semester
1.1.2009 – 31.12.2009
1.9.2009 – 31.1.2009
© SAP AG 2010
Fee calculation period begin and end dates are independent of the dates in the academic calendar. Of
course, your business requirements may dictate a relationship.
Note: Fee calculation can be based on the full academic year. A student can register for a full year
instead of a specific session. Module booking allows full year bookings if the student is registered
for the full year. In this case, all sessions of the academic year should be assigned to one fee
calculation period. If the system recognizes an entry with blank session (= full year), it will
internally add the session using the following method:
Look for the begin date of the registration or booking.
Compare it to the 0100 time limits in the top Academic Calendar.
If the system finds a matching 0100 begin date, it derives the session from this time limit.
Recommendation: To avoid problems when using full year registration, do not define overlapping
sessions within one year and do not use multiple academic calendars with 0100 time limits for the
programs, module groups or modules.
© SAP AG
IHE203
3-28
3. Fee Calculation Process: Periods - Previous
Period
The previous period is used for the fee calculation mode: Expected Re-registration.
If you calculate a fee for a period and enter the Expected Re-registration mode, the
system actually uses the previous period assigned to the fee calculation period
determined by your period key that was entered in the Fee Calculation transaction.
© SAP AG 2010
The fee calculation process modes are maintained using the IMG path:
Student Lifecycle Management → Student Accounting → Fees → Basic Settings → Set Up
Processing Modes for Fee Calculation
© SAP AG
IHE203
3-29
3. Fee Calculation Process: Overview of Dates
in Student Accounting
Fee Calculation Date (entered in Fee Calculation User Interface)
=> Fee Calculation Period
Key Date (Setting in Customizing) and Academic Year & Session
=> Relevant date to read data for the fee calculation
Booking/Cancellation respectively Registration/ Deregistration Date
=> Registration/Refund Periods
Academic Year and Session
=> Installments/Due Date for the fee
System Date (today)
=> Posting Date = Document Date
© SAP AG 2010
© SAP AG
IHE203
3-30
3. Fee Calculation Process: Key Dates
Student Lifecycle Management is flexible such that you can calculate fees based on
parameters stored in the master data:
Student (ST)
Program of Study (SC)
Module Groups (CG)
Module (SM) including Event Package (SE)
The various fee categories available for these objects are examples of master data.
Because the master data can change over time, Student Lifecycle Management
needs a key date to read the data.
© SAP AG 2010
The HR objects shown in the figure follow the HR time dependency concept. Basically, the
attributes for the objects are stored in infotypes. An infotype has a begin and an end date describing
its validity.
© SAP AG
IHE203
3-31
3. Fee Calculation Process: Key Date Situation relevant to a Specific Date
Date of fee calculation
Find fee calc period (IMG)
15.08.2009 - 15.09.2009
Loop on assigned sessions (IMG)
Fall 2009/10
Find duration of session (Cal)
01.09.2009 - 30.09.2009
Check key date category assigned
to ST, SC, CG or SM (IMG)
Find key date of this session (Cal)
Start Date = 01.09.2009
Read data valid on key date
© SAP AG 2010
Fee calculation and grant evaluation always take into account a set of programs and modules
registered at a certain point in time, the Key Date. Fee calculation uses this key date to access data.
In other words, if data used in the fee calculation has changed since the key date, the changes are
ignored.
The SAP system provides four (hard-coded) key date categories, as follows:
• 01 = start date of the session
• 02 = end date of the session
• 03 = start date of standard session
• 04 = end date of standard session
Example: If you have selected Key Date Category 01 and the session is from September 1, 2009, to
January 31, 2010, the SAP system derives the key date for fee calculation as September 1, 2009.
You may need to back-date some of your changes.
© SAP AG
IHE203
3-32
3. Fee Calculation Process: Key Dates
for SC, CG, SM and ST
Student’s SC, CG
or SM
SC,
CG,SM
SC,
CG,
SM, ST
Time limit 0100 of Academic
Calendar assigned to top
organization unit
© SAP AG 2010
The key date categories defined in the SAP system are 01, 02, 03, and 04.
For key date category 01 and 02:
• The start and end dates of a student's study interval for a program of study, module groups or a
module is maintained in the student file.
• Key date categories 01 and 02 are used only for (object types) the academic structure. Do not
assign these key date categories to (object type) student.
For key date category 03 and 04:
• The start and end dates of the standard academic session are maintained in the academic
calendar.
• Category 03 and 04 can be assigned to any of object types above (Program Of Study, Module
Groups, Module, Student).
• The standard session is defined in the delivered time limit 0100. You can change the standard
session time limit key using the IMG path: Student Lifecycle Management> Master Data in
SLCM>Academic Calendars>Define Mandatory Time Limits for Academic Calendar. Enter a
new value (that is, a new Time Limit Key) next to: Setting 0100.
© SAP AG
IHE203
3-33
3. Fee Calculation Process: Key Date
Categories 01 and 02
The key date categories 01 and 02 refer to the individual registration to the program of
study, module groups or modules. Thus these categories can be used only for master
data of the academic structure.
The begin and end dates for the registration to a program of study are set/changed
during the registration activities in Student Lifecycle Management. The default begin
and end dates are derived from the begin and end dates of the time limit 0100 for the
academic year and session in the academic calendar inherited by the program of study.
The user can change these dates in the Student File.
© SAP AG 2010
Technically, the begin and end date of the registration to a program of study is the begin date or the
end date of the infotype 1771 for the academic year and session at the object study (CS) of the
student for the program.
For details, refer to the documentation and training for Student Lifecycle Management Student
Administration.
© SAP AG
IHE203
3-34
3. Fee Calculation Process: Key Date
Categories 01 & 02 for Module Bookings
The begin and end dates for the registration (booking) to a module are set
during module booking. The system derives the dates from the time limit 0100
for the academic year and session in the academic calendar inherited by the
module. These dates cannot be changed by the user!
© SAP AG 2010
Technically, the begin and end date of the registration to a module is the begin date or the end date
of the Relationship 506 of the Student (ST) to the Module (SM) for the specified academic year and
session.
The Event Package (SE) inherits the date properties of the Module (SM).
© SAP AG
IHE203
3-35
3. Fee Calculation Process: Key Date
Categories 03 and 04
The Key Date categories 03 and 04 refer to the Academic Calendar attached to the
top Organizational Unit (HIORG). These categories are available for all objects.
The Key Date 03, start date of the standard session, is the begin date of the time limit
0100 from the Academic Calendar at the top organizational unit for the academic
year and session.
The Key Date 04, end date of the standard session, is the end date of the time limit
0100 from the Academic Calendar at the top Organizational Unit for the Academic
Year and Session.
© SAP AG 2010
© SAP AG
IHE203
3-36
3. Fee Calculation Process: Overview of Dates
in Student Accounting
Fee Calculation Date (Entered in Fee Calculation User Interface)
=> Fee Calculation Period
Key Date (Setting in Customizing) and Academic Year & Session
=> Relevant date to read data for the fee calculation
Booking/ Cancellation respectively Registration/ Deregistration Date
=> Registration/ Refund Periods
Academic Year and Session
=> Installments/ Due Date for the fee
System Date (today)
=> Posting Date = Document Date
© SAP AG 2010
© SAP AG
IHE203
3-37
3. Fee Calculation Process: Time Limit
Sequences & Academic Calendar
REFD
IMG: Time Limit Sequence REFD = time limits REF1 to REF5
100%
REF1
80%
REF2
50%
REF3
20%
no refund
REF4
REF5
Academic Calendar, Session 001: REFD =
2007
01.10.2007
to 31.10.2007
01.11.2007
to 30.11.2007
01.12.2007
to 31.12.2007
01.01.2008
to 31.01.2008
> 31.01.2007
2008
01.10.2008
to 31.10.2008
01.11.2008
to 30.11.2008
01.12.2008
to 31.12.2008
01.01.2009
to 31.01.2009
> 31.01.2008
2009
01.10.2009
to 31.10.2009
01.11.2009
to 30.11.2009
01.12.2009
to 31.12.2009
01.01.2010
to 31.01.2010
> 31.01.2009
© SAP AG 2010
A Time Limit Sequence groups several time limits into one logical unit so these limits can be
evaluated in a sequence.
You can set up time limit sequences according to your individual requirements. A time limit may be
assigned to one time limit sequence only. Possible time limit sequences for fee calculation are:
• Add/drop modules
• Add/drop programs
• Registration period
© SAP AG
IHE203
3-38
3. Fee Calculation Process: Time Limit
Sequences in Pricing (1 of 6)
Student Lifecycle Management allows you to map certain dates with time limits of
a time limit sequence in an academic calendar and use this time limit in your
pricing.
Example: Depending on the booking date, your price per credit for a module in the
Academic Year 2009/First Semester varies from 100 UNI to 150 UNI according to
the following table.
Booking Date
Price
1.1.2009 – 15.1.2009
100 UNI
16.1.2009 – 31.1.2009
120 UNI
1.2.2009 – 10.2.2009
130 UNI
after 11.2.2009 150 UNI
Similar scenarios are possible for Program Registration and various refund rules
(for example, refund based on date of withdrawal).
© SAP AG 2010
© SAP AG
IHE203
3-39
3. Fee Calculation Process: Time Limit
Sequences in Pricing (2 of 6)
To define staged pricing rules, follow these steps:
Define time limits and a time limit sequence to describe your different periods.
Determine the actual dates in the appropriate academic calendar.
Define the date field in the structure of the fee calculation.
Assign the date field to the time limit sequence.
Consider the time limit in your pricing rules.
© SAP AG 2010
© SAP AG
IHE203
3-40
3. Fee Calculation Process: Time Limit
Sequences in Pricing (3 of 6)
Example:
Booking Date
Price
1.1.2009 – 15.1.2009
100 UNI
16.1.2009 – 31.1.2009
120 UNI
1.2.2009 – 10.2.2009
130 UNI
after 11.2.2009
150 UNI
First you set up time limits: bp01 (booking price 1), bp02 (booking price 2), bp03
(booking price 3), bp04 (booking price 4).
Then you set up a time limit sequence bpst (booking price stages) and assign the
four time limits to this sequence.
In the Academic Calendar, you define the actual dates for the Academic Year 2009,
First Semester.
© SAP AG 2010
© SAP AG
IHE203
3-41
3. Fee Calculation Process: Time Limit
Sequences in Pricing (4 of 6)
Time Limit Sequence
Time
Limit
Ac. Year/
Session
Begin
Date
End Date
bpst - booking pricing
stages
bp01 booking
price 1
2009/ First
Semester
1.1.2009
15.1. 2009
bpst - booking pricing
stages
bp02 booking
price 2
2009/ First
16.1. 2009
31.1. 2009
bpst - booking pricing
stages
bp03 booking
price 3
2009/ First
1.2. 2009
10.2. 2009
bpst - booking pricing
stages
bp04 booking
price 4
2009/ First
11.2. 2009
30.6. 2009
Semester
Semester
Semester
© SAP AG 2010
© SAP AG
IHE203
3-42
3. Fee Calculation Process: Time Limit
Sequences in Pricing (5 of 6)
Now it is necessary to define:
Which date field is used to derive the appropriate time limit field
Which time limit sequence is assigned to this time limit field
Student Lifecycle Management offers as standard four fields for time limits for
dates related to program of study (registration) and four fields for time limits for
dates related to module (booking).
You can assign to each of the fields a date field in the structure from which the
appropriate time limit is derived.
Time Limit Sequence (Look
for the time limit in this
sequence)
Date Field (Input Date which
is matched with the Time
Limit)
Reg./ Dereg. Period Field
(Returns Time Limit)
© SAP AG 2010
The system processes the date in the following way:
• The system uses the date from the student’s module booking or registration record and compares
it with the time limits of the time limit sequence that is assigned to the field.
• The system returns the time limit that includes the date in the Reg./Dereg. Period field.
• The system converts the date into a time limit.
Customizing is carried out using the following IMG paths:
-> Student Lifecycle Management → Student Accounting → Fees → Pricing → System
Enhancements → Time Limits and Time Limit Sequences → Check Assigned Date Fields.
-> Student Lifecycle Management → Student Accounting → Fees → Pricing → System
Enhancements → Time Limits and Time Limit Sequences → Assign Time Limit Sequence to Time
Limit Fields
In standard structures for fee calculation, several dates, such as the module booking and cancellation
date, are provided. If these fields are not sufficient, you can extend the structure and include the date
field you need.
Finally you must define your pricing rules using this time limit field.
© SAP AG
IHE203
3-43
3. Fee Calculation Process: Time Limit
Sequences in Pricing (6 of 6)
Example:
The booking date of a module is available in the structure, CMAC_SM:
CMSMREGDAT. You assign booking date to the time limit field, CMSMREGP1.
Then you assign the time limit sequence bpst (booking price stages) to
CMSMREGP1.
In pricing you define that your price per credit is dependent on CMSMREGP1:
CMSMREGP1
Price
bp01
100 UNI
bp02
120 UNI
bp03
130 UNI
bp04
150 UNI
© SAP AG 2010
© SAP AG
IHE203
3-44
3. Fee Calculation Process: Overview of Dates
in Student Accounting
Fee Calculation Date (entered in Fee Calculation User Interface)
=> Fee Calculation Period
Key Date (Setting in Customizing) and Academic Year & Session
=> Relevant date to read data for the fee calculation
Booking/Cancellation respectively Registration/ Deregistration Date
=> Registration/Refund Periods
Academic Year and Session
=> Payment Plans/Due Date for the fee
System Date (today)
=> Posting Date = Document Date
© SAP AG 2010
© SAP AG
IHE203
3-45
3. Fee Calculation Process: Due Date
Schedule - Business Scenario
At your institution, students have to pay their fees in three partial
payments: 50% at the beginning of the semester, 25% one month
later and the remaining 25% two months after the second payment.
You must reflect this payment rule in the system.
© SAP AG 2010
© SAP AG
IHE203
3-46
3. Fee Calculation Process: Due Date
Schedule Functionality
Before defining the payment conditions in a Due Date Schedule, you must consider
the following:
For which cases is a due date schedule applicable? For all students, for certain fees only
Are there different rules dependent on the program of study (SC) or the study module (SM)?
Are the rules the same for all periods in the academic calendar?
Are partial payments split in different ways?
Are there minimum amounts that should not be split?
Are there fees that should not be included?
© SAP AG 2010
© SAP AG
IHE203
3-47
3. Fee Calculation Process: Due Date
Schedules in Student Lifecycle Management
Due Date Schedules describe
How to split liabilities into a payment plan and
When payment is due (for each of the partial payments)
Partial Payments can consist of
A percentage (of the total amount)
A fixed amount
The remainder
Note: Each partial payment is an original open item, which in turn can be split into an
FI-CA installment plan.
© SAP AG 2010
A Due Date Schedule leads to a single due date or a sequence of due dates according to a time limit
or time limit sequence. The due date schedule is used to apportion liabilities and determine when
payment is due.
A Due Date Schedule is a required entry even if you do not want to apportion the liability. In that
case, you must create a due date schedule with only one payment date.
The Due Date Schedule is set up in a generic way using time limit sequence and time limit, which
are assigned to actual dates via the academic calendar. The due date schedule can be reused for
different periods as long as business rules do not change.
Concept compatible with handling of dates in Student Lifecycle Management: Time limit and Time
Limit Sequence can be used in several processes (for example, last booking date in booking rules
and due date schedule).
© SAP AG
IHE203
3-48
3. Fee Calculation Process: Defining a Due
Date Schedule
Follow these steps to define a due date schedule:
1. Define the due dates
a) Time Limit and Time Limit Sequence: use general periods
b) Assign dates to Academic Calendar: use actual dates
2. Define Due Date Schedule and priority (settings for overruling)
3. Perform detailed maintenance of Due Date Schedule (examples)
4. Assign Due Date Schedule to Program of Study, Module, Student
Account or Contract Object
© SAP AG 2010
A Due Date Schedule is set up in a generic way using time limit sequence and time limit, which are
assigned to actual dates via the academic calendar. The Due Data Schedule can be reused for
different periods as long as business rules do not change.
Use the IMG path: Student Lifecycle Management → Student Accounting → Fees → Posting →
Due Date Schedule.
© SAP AG
IHE203
3-49
3. Fee Calculation Process: Time Limit
Sequence for Due Date Schedule
Time limit sequence is a series of time limits.
Time limit is normally a period with start and end dates. In a Due Date Schedule,
however, only the start date is relevant. It is the due date for the partial payment.
The No overlap indicator is irrelevant.
© SAP AG 2010
You define Time Limits and Time Limit Sequences using the IMG path: Student Lifecycle
Management → Master Data in SLCM → Academic Calendars.
The “No Overlap” indicator specifies that the time limit must not overlap other time limits of the
same type in the Academic Calendar. This indicator is not relevant for the Due Date Schedule
because the Due Date Schedule always uses the start date of a time limit because there is no
payment period. If you want to enable a payment period, you must prevent the open item from being
dunned (see “Customizing of Dunning Procedure”).
Note: For due dates and payment plans, only the begin date of a time limit is used.
© SAP AG
IHE203
3-50
3. Fee Calculation Process: Defining the Time
Limit Sequence
IMG
PRT3
2
Due Date = Start Date of Time
Limit. The No overlap field is
not relevant.
Set up TLS and Assign TL
PAY1
PAY2
1
PAY3
3
Assign exact dates
Set up TL
Academic Year 2009
Oct 09
Nov 09
Jan 10
© SAP AG 2010
The valid due date is always the begin date of a time limit.
Define dates for a certain academic year using the Transaction PIQCAM in Student Lifecycle
Management.
Time limits can be absolute or relative dates, however, in the current solution all dates in payment
plans are dates of the Academic Calendar. Only the exception triggered date can derive due dates
that are relative to an event date (for example, registration, booking). A payment plan such as first
installment 10 days after registration to a Program, second installment 20 days after registration, and
so forth is not yet possible.
© SAP AG
IHE203
3-51
3. Fee Calculation Process: Maintain Due Date
Schedule
DDS
IMG
Period TLS
Exception Amount TL
FS01
50 USD
PRT3
Number Unit
PAY3 1 (0, -10) Days
DDS Details
TL
Instll Meth
Percentage
PAY1
Percentage 50,00
PAY2
Fixed Amt.
Amount
Due Date = Start
Date of PAY3
plus 1 Day
200 USD
DDS Exceptions
FC Basis DDS Except
SM
Booking after
TL
DDS Instll Meth
PAY1 Due w next inst
Number Unit
0
Days
© SAP AG 2010
Exception amount: If the amount is lower than Exception Amount/Currency, it must be paid by the
(begin date of the) time limit + number of days/ weeks or x percentage* of the duration of events
related to the module (only for due date schedule on modules).
• *include / exclude
• Describes how fractions of a day must be handled. Example: calc. 3.2 days are set to 4 (include)
respectively 3 (exclude)
Example: Usually course fees can be paid in two installments of 25 percent and one installment of
50 percent of the total amount. But if the amount (total amount of all contract objects flagged as
cumulative having the same due date schedule) is less than 20$, it must be paid all at once at a
certain date (for example, the last date in the regular payment plan).
Due date schedule exception happens only if
• The student registers or books after the registration or booking deadline you specified.
• The student de-registers or cancels after the de-registration/booking deadline.
The SAP system provides the following Due Date Schedule installment methods:
• Due with the booking or canceling date plus offset
• Due with the next installment
• Due with the last installment
• Distribute evenly across remaining installments
• Distribute in proportion across remaining installments
© SAP AG
IHE203
3-52
3. Fee Calculation Process: Due Date
Schedule - Late (De)Registrations
The exception rule applies if after the deadline a student
Registers (books) a program of study or module
De-registers (cancels) a program of study or module
rig
ption T
e
c
x
E
=
gers
SAP provides the following exception payment plan options:
1 = Due with the booking or canceling date plus offset
2 = Due with the next installment
3 = Due with the last installment
4 = Distribute evenly across remaining installments
5 = Distribute in proportion across remaining installments
© SAP AG 2010
Example: The deadline for booking a Module is Jan 15, 2009. Total tuition for the module is 1,000
UNI. The student booked on Feb 15, 2009. The due date schedule is as follows: Feb 01 = 40%,
March 01= 30%, April 01 = 20%, May 01 = 10% .
If installment method 1 is used for booking, the student should pay 1,000 UNI on Feb 15, 2009 plus
offset.
If installment method 2 is used for booking, the student should pay 1,000 UNI on March 01, 2009.
If installment method 3 is used for booking, the student should pay 1,000 UNI on May 01, 2009.
If installment method 4 is used for booking, the student should pay
• 333.33 UNI on March 01, 2009; (1000UNI / 3 installments)
• 333.33 UNI on April 01, 2009; (1000UNI / 3 installments)
• 333.34 UNI on May 01, 2009.(1000UNI / 3 installments)
If installment method 5 is used for booking, the student should pay
• 500 UNI on March 01, 2009; (1000UNI * 50%)
• 333 UNI on April 01, 2009; (1000UNI * 33.33%)
• 167 UNI on May 01, 2009; (1000UNI * 16.67%)
© SAP AG
IHE203
3-53
3. Fee Calculation Process: Due Date
Schedule Assignment
The due date schedule can be assigned to
Contract accounts
You can set defaults!
Contract Objects (more specific)
IMG
Program of Study (SC) or Module (SM) (even more
specific)
This means:
Payment rules for SC/SM have first priority (if fee type allows it).
Payment rules for fee types have second priority.
Payment rules for student accounts have third priority.
IMG
© SAP AG 2010
A Due Date Schedule (DDS) is mandatory for the contract account. You must assign a due date
schedule to the contract account during customization. The due date schedule is optional for
Contract Objects, the Program Of Study and for Modules.
A Due Date Schedule can be assigned automatically to contract account and contract objects based
on specified students attributes (See IMG.)
A Due Date Schedule at the module or program level overwrites the due date schedule at the
contract object but only for certain fee types (tuition fees, for example, not insurance).
Flag whether the due date schedule of the contract object type is overwritten by the SM DDS or the
SC DDS.
© SAP AG
IHE203
3-54
3. Fee Calculation Process: Derive Due Dates
and Apportion Fees
Tuition Fee
2000 $
DUE01
PRT3
Academic Year
PAY1
PAY2
PAY3
50%
25%
Rest
10/01/2009
11/01/2009
01/01/2010
1000
500
500
© SAP AG 2010
Note: The system uses the Academic Calendar of the relevant Academic Structure object (Example:
SC or SM).
If part of the amount is expected to be granted by a sponsor, this part could be delayed
(implementation of a BADI necessary). The Due Date Schedule would apply to the remainder only.
The Due Date Schedule always applies to total amounts (not delta amounts after recalculations).
© SAP AG
IHE203
3-55
3. Fee Calculation Process: Unit Summary
You should now be able to:
Describe the fee calculation process and the audit of fee calculation
Explain the parameters and data that influence the fee calculation
Describe where this data is maintained
Identify which data set is relevant when data changes during an academic
session
Explain the derivation of due dates and the use of different periods for fee
calculation and posting
© SAP AG 2010
© SAP AG
IHE203
3-56
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
4-1
4. Fee Calculation Configuration: Overview
Contents
„
Pricing Configuration: Mathematical Calculation
„
Condition Techniques
© SAP AG 2010
© SAP AG
IHE203
4-2
4. Fee Calculation Configuration: Unit
Objectives
At the conclusion of this unit, you will be able to:
„
Explain the configuration of fee calculation
„
Describe how mathematical parameters are represented in pricing
„
Describe the components used in the fee calculation
© SAP AG 2010
© SAP AG
IHE203
4-3
4. Fee Calculation Configuration: Business
Scenario
„
Your institution charges tuition. The tuition fee could be a flat fee depending
on the program the student registered in. On the other hand, the tuition fee
could depend on the total of attempted credit hours. Additionally, students
enrolled in a specific course or section may have to pay for course material.
„
Employees get a 10 percent discount on tuition fees but not on the
additional fee charged for course material.
„
Your institution may offer various meal plans for which the student is
charged.
© SAP AG 2010
© SAP AG
IHE203
4-4
4. Fee Calculation Configuration: Parameters
How much will it cost me to
study at your institution?
Well... it depends on
ƒ ___
Enter some
parameters
here!
ƒ ___
ƒ ___
ƒ ___
© SAP AG 2010
„
Before you set up fee calculation rules, you should consider your institution‘s business rules and ask
some questions such as the following:
• Are fees based on a student‘s attributes?
- Full-time versus part-time, international, undergraduate versus graduate students, seniors,
military personnel?
• For which period do we assess fees?
- Each semester, the whole academic year, summer school
• What processes triggers fees?
- Admission, registration, booking/adding/dropping classes, expected re-registration
• What do we charge for?
- Program Of Study, certain course, excursion, living on campus
• How do we calculate the fee?
- 100 UNI per credit hour, 1000 UNI per Program/Semester, 50 UNI insurance
• Are there any restrictions, discounts, special conditions that have to be checked?
- reduction for employed students, surcharge for international students
© SAP AG
IHE203
4-5
4. Fee Calculation Configuration:
Fee Calculation Objectives
Objectives of Fee Calculation
„
Calculate tuition fee in a flexible manner
„
Calculate other fee types that are tied to tuition
„
Calculate refunds (that is, re-calculate fees and post negative amounts)
„
Re-calculate fees at any time
„
Overwrite a calculation result
Condition Technique
(as in SD)
+ esp. for Student Lifecycle
Management:
Fee Calculation Procedure
© SAP AG 2010
© SAP AG
IHE203
4-6
4. Fee Calculation Configuration: Example
Tuition Fee: 2000
= 20 crh * 100
+
Course Mat:
= if SM = HIST 101 G00
+
Employee:
+
Meal Plan:
300
= 5 meals per week
___________________________________
=
Total:
50
-200
= 10 % discount of tuition
2150
© SAP AG 2010
© SAP AG
IHE203
4-7
4. Fee Calculation Configuration: Individual
Pricing Procedure
„
„
Pricing
Procedure
„
Fees
Σ
„
Calculation rules: +, -, formula
Calculation basis: fix, %, quantity
Specific checks and requirements
Posting rules
Process amounts
Get amounts
+ 2000
Part. amt.: TUIT
Condition
Types
+ 50
- 200
© SAP AG 2010
„
Part. amt.: CMAT
Part. amt.: EMPL
...
20*100
50
10% (20*100 + 50)
To calculate fees, it is necessary to define::
• Fee Calculation Procedures which are composed of one or more pricing procedures.
• A Pricing Procedure contains one or more Condition Types.
© SAP AG
IHE203
4-8
4. Fee Calculation Configuration: Condition
Types & Condition Record
Student Master and Booking Data
SC & CG
ST
SM/SE
SM
SM
Pricing
Procedure
Σ
Condition Type
531
532
533
534
call up
...
...
Condition
Tables
deliver
20*100
Access
Sequence
1. 531
2. 534
find
find
2005
001
Fee Cat
to 20 CRH
= 100 each
Condition
(Record)
© SAP AG 2010
„
A Condition Type uses:
• Condition Table
• Access Sequence
• Condition Record
© SAP AG
IHE203
4-9
4. Fee Calculation Configuration: Data
Retrieval and Calculation Rules
Student Master and Booking Data
SC &/ CG
ST
TUIT:
SM
SM
SM/SE
20 CRH
CMAT:
HIST = yes
EMPL:
yes
MEAL:
5 per week
IMG
+/- $$
*100 Æ+2000
50 Æ
+50
- 10 % Æ -205
300 Æ +300
© SAP AG 2010
© SAP AG
IHE203
4-10
Fee Group
Stdt Org ID
Stdt Fee Cat
Stdt Group
4. Fee Calculation Configuration: Compare/Add
Results
get
Fee Calc Proc
Fee
Calculation
Procedure
Pricing
Procedure
ADD
MIN
MAX
Σ
ADD
MIN
MAX
Pricing
Procedure
Σ
Pricing
Procedure
Σ
© SAP AG 2010
„
Student Group = Four-character alphanumeric key that defines a student group. For example:
• 0001 = Regular students
• 0002 = Exchange students
„
You enter the Student Group Key in Student Master Data on the tab “Ind. Study Data”.
„
Student Fee Category = up to four-character alphanumeric key that uniquely identifies different fee
types for the students, for example:
• RES = resident student
• NRES = nonresident student
„
You assign student fee categories to the students in Student Master Data Maintenance on the Fee
Calculation Data tab page. You maintain the condition records for each student fee category in all
pricing procedures. Then the SAP system can derive the different tuitions or fees for each student
according to the student's fee calculation procedure.
„
Student Org ID = Each student must be assigned directly or indirectly to an organizational unit.
„
Calculation base = admission application data or study data (see figure)
© SAP AG
IHE203
4-11
4. Fee Calculation Configuration: Fee
Calculation Procedure: Configuration 1
Example:
1. The institution charges different fees types: fees for tuition, material, facility
usage, administrative fees.
2. Tuition fee can be based on the booked program of study or on all
modules, whatever is less.
3. Administration fees are insurance, meals, and housing.
Fee Calc Proc
Define Steps
Step
Consists of:
Rule:
1
Substeps
ADD
2
Pric. Proc
MAX
3
Pric. Proc
ADD
© SAP AG 2010
„
Pricing procedures can operate program of study or module data.
„
Multiple procedures can be combined by adding them or by comparing them and choosing either the
minimum or the maximum.
© SAP AG
IHE203
4-12
4. Fee Calculation Configuration: Fee
Calculation Procedure: Configuration 2
Fee Calc Proc
Define Steps
Assign Elements
Step
Consists of:
Rule:
1
Substeps
ADD
2
3
© SAP AG 2010
Go to tree structure maintainance
Pric. Proc
Pric. Proc
No.
Substep
11
2
12
3
No.
Pric Proc
Basis
21
TUI1
Program
22
TUI2
Module
No.
Pric Proc
Basis
21
ADMN
Program
MAX
ADD
„
Complicated fee calculation procedures are easier to customize if you choose: Go to Tree Structure
Maintenance.
„
The minimum required customizing would be as shown in substep 3: One single pricing procedure
needs to get the rule ADD.
© SAP AG
IHE203
4-13
4. Fee Calculation Configuration: Elements of
Pricing Procedures
„ Pricing
„
procedure
Adds different fees; combines mathematical steps, conditions and accounting information
„ Condition
„
Defines how to calculate each part of the fee in a single mathematical step
„ Access
„
sequence
Defines for each step how to find relevant rates
„ Condition
„
Credit Type for Pricing
Define reference value
„ Map
„
record
Assigns amounts/percentages to specific values
„ Maintain
„
table
Defines the data elements (student, course, module, and so on) use to determine the rates
or percentages
„ Condition
„
type
Module Booking Status for Fee Calculation
Define the booking status to be included in the fee calculation
© SAP AG 2010
Note: Customizing should be performed bottom up.
„
When you customize your own fee calculation procedure, proceed as follows:
• Define Condition Tables.
• Define Access Sequences.
• Create Condition Types.
• Maintain Pricing Procedure(s).
• Define Fee Calculation Procedure(s).
• Define Condition Records (can also be done after creating Condition Types).
© SAP AG
IHE203
4-14
4. Fee Calculation Configuration: Condition
Tables
Restrict the
applicability
of the table
Display different
field descriptions
Navigate in the list
with these buttons
or scroll keys
Choose the table fields
by double-clicking
© SAP AG 2010
„
KOMK = pricing communication header (acronym based on German words, including Kopf);
KOMP = pricing communication item (acronym based on German words, including Position)
„
Note: Use Transaction SE11 (ABAP Dictionary Maintenance) to see all the fields of database Tables
KOMK (from line 299 on) and KOMP (from line 953 on).
„
You can add customer-defined fields to be used in pricing to the field catalog. After defining the
fields, add them to the field catalog and fill them in BADI CMAC_BADI_PRICING. For details use
the IMG path: Student Lifecycle Management t>Student Accounting>Fees>Pricing>System
Enhancements>New Fields for Conditions.
© SAP AG
IHE203
4-15
4. Fee Calculation Configuration: Condition
Table Fields
Look at where these
fields are maintained!
Student Master Data, Student File,
Academic Calendar, Academic
Structure, and so on
© SAP AG 2010
© SAP AG
IHE203
4-16
4. Fee Calculation Configuration: Condition
Tables - Field Structure
condition record
list entry
pre-selection
This field defines
the list entry for
the condition
record
Sess.
Year
9
9
St. Group
Year
St. Group
Session
© SAP AG 2010
„
You can define which fields should be selection fields for the condition record. If you flag the field,
it will appear in the list entry screen for the condition record. If you do not flag the field, it will be
used for the initial selection before the list entry appears.
„
Text field: You can decide whether you want to see the textual description of the field in the list
entry of the condition record.
„
The pricing document consists of the parts (structures):
• KOMK
• KOMP
„
In the access sequence you activate the fields. You can see which fields belong to the header
(KOMK) and which to the items (KOMP).
• Note: Use Transaction SE11 (ABAP Data Dictionary Maintenance) to see all the fields of
database table KOMK (from line 299 on) and KOMP (from line 953 on).
© SAP AG
IHE203
4-17
4. Fee Calculation Configuration: Access
Sequence 1: Find Condition Records
Acc. Seq.
Accesses
Access
10
20
Table
545
531
Description
Year/Session/Student Group
Year/Session
Requirement Exclusive
924
9
< F4: Routines
9 = System stops
search after
finding 1 condition
record; otherwise,
it compares all
found records
© SAP AG 2010
„
The SAP system uses access sequence as a search strategy to search for condition records valid for a
condition type. The access sequence determines the sequence in which the system searches for data.
The access sequence consists of one or more accesses. It tells the SAP system where to search first,
second, and so on, until it finds a valid condition record. You specify an access sequence for each
condition type for which you create condition records.
„
Each access performed during the access sequence is made using a condition table.
„
Recommendation:
• If you define your own access sequences, the key must start with the letter Z because SAP
reserves this letter for customer definitions.
• Make sure you set up the access sequence to access from specific conditions to generic
conditions.
• Do not change the access sequences in the standard SAP system.
„
A Condition Table is a combination of fields, which form the key for a condition record.
© SAP AG
IHE203
4-18
4. Fee Calculation Configuration: Access
Sequence 2 - Define Fields
Acc. Seq.
Accesses
Fields
Cond.
Field on
condition
type
I/O Doc. struc. Doc. field Long field label
Acad. Year
Acad. Session
Stud. Fee.Cat.
Module Obj. ID
Module Fee Cat.
Release Status
Processing Status
Condition
table
structure
Reference
Field
Input of field
value
Source of constant
Init
ATyp Prio
F4
_ Field in fixed key part
A Field in free key part
B Field to be
determined in access
C Data field from
condition table
© SAP AG 2010
„
You can see the condition table fields and the table structure, KOMK = header or KOMP = item, to
which they are assigned. Also, you see from the symbols (arrow, green light, red light) how the data
is derived.
„
You can define a constant value, which the system automatically assigns to a field when it accesses
the condition record.
„
The Initial indicator performs these functions within Customizing for access sequences.
• First, it controls that the system does not access the condition if the field in the document
header/item is blank or 0.
• Second, during automatic return transfer of data that were determined in the access, it allows an
initial value to be returned.
„
ATyp: The processing type determines how the corresponding field is used for the access. The field
can be marked as belonging to the fixed or free key part or else as not relevant for the access. Fields
that are defined as data fields for the definition of condition tables are automatically marked with an
access type.
„
Prio: This valuation describes a priority for the characteristics, which can be used as fields when you
create condition tables or document fields for pricing. You can enter values from 01 (very high) to
99 (very low). The valuation controls how the system selects from the condition records determined
from an access with a free key part. The more fields are filled with a high priority in the key of a
condition record, the more likely the key is to be used for the document.
© SAP AG
IHE203
4-19
4. Fee Calculation Configuration: Condition
Types: Classes (1 of 2)
Condition
classes
Discounts/
surcharges
Prices
Prices
Quantity
Always start your pricing
procedure with a
condition type of class B
(= prices)
Discounts/
surcharges
© SAP AG 2010
„
Data about conditions is stored in condition records.
„
You can determine conditions at any level you require.
„
The levels on which pricing is most commonly carried out have been predefined in the standard
version.
„
You can easily add additional levels if required. A standard field catalog containing fields
commonly used in pricing is supplied with the SAP system. You can make conditions dependent on
any document field(s), but you may have to add these fields to the field catalog.
© SAP AG
IHE203
4-20
4. Fee Calculation Configuration: Condition
Types: Classes (2 of 2)
Condition
classes
Prices
fixed
amount
credit hours
program of
study
scalable
per
per
Discounts/
surcharges
Quantity
absolute amount
percentage
pos. only = surcharge
neg. only = discount
scalable
© SAP AG 2010
© SAP AG
IHE203
4-21
4. Fee Calculation Configuration: Condition
Type Details - Examples
In the Condition Type Details you could define the details as follows:
Fee per CRH
IMG
Flat rate
Employee
Cond. Class
B= Prices
A = Disc/Surch B
B
Calcul. Type
B = Fix. Amt.
A = Percentage C = Quantity
G=Formula
Cond. Cat.
H = Basic Price H
Pos/neg. Amt.
-
H
X=
negative
-
Late Fee
H
-
© SAP AG 2010
„
You configure condition types in the Condition Type Details screen.
„
Assign an access sequence and define the following:
• Condition Class (B = Prices)
• Calculation Type (B = Fix. Amount)
• Condition Category (Basic Price, Surcharge, Discount)
„
Define which parameters can be changed by manual entry (for example, item condition, header data,
percentage, amount)
„
Make restrictions if the amount can or must be negative or positive
„
Define group or item conditions (see “Condition Types: Group Conditions” figure)
„
Define settings for scales (see “Condition Types and Records: Scales” figure)
© SAP AG
IHE203
4-22
4. Fee Calculation Configuration: Condition
Types - Group Conditions
IMG
IMG
Condition type
TUIT
Group cond.
X
Booked Study Modules
Module M1 Æ 4 CRH
...
...
Module M2 Æ 7 CRH
...
Condition record TUIT
Debit Entry
Booked Study Modules
from
1 CRH
$ 100/CRH
from
10 CRH
$ 80/CRH
from
20 CRH
$ 60/CRH
TUIT
11 CRH
$ 880
© SAP AG 2010
„
In Customizing you can set a condition type to be a group condition. The condition base value (such
as weight) is then calculated as the sum of the individual items within one group.
© SAP AG
IHE203
4-23
4. Fee Calculation Configuration: Conditions
Types and Records - Scales
1. Settings on the Condition Type
Subscreen: Scales
TUIT
Basic Price Tuition
Calculation type:
Scales Basis:
Scale Type:
Check value:
2. Settings on the Condition Record
Scale base type
up to 10 CRH
up to 20 CRH
up to 30 CRH
Quantity
Quantity
to
ascending
Condition type defines what
you can enter on the
condition record
Calculation type
100 USD each
80 USD each
60 USD each
© SAP AG 2010
„
Configuration of the scale for the condition type determines the settings on the condition record.
„
You can set the following rules:
• Scale basis – The most important are value, quantity, time, and based on formula
• Check value = ascending, descending or none
• Scale type = from, to, not in use, or defined in condition record
• Scale formula – see “Customer Enhancements: Routines” figure)
• Unit of measure – Used by the system to determine scales when you use group conditions
© SAP AG
IHE203
4-24
4. Fee Calculation Configuration: Pricing
Procedure - Combine Condition Types
Always start your pricing
procedure with a condition
type of class B (= prices)
10
20
30
40
50
Prices
Discounts/
surcharges
Discounts/
surcharges
Discounts/
surcharges
Discounts/
surcharges
Example 1
Example 2
Tuition
Course
Material
Foreign Stud
Meal Plan
Undergrad.
Employee
...
© SAP AG 2010
© SAP AG
IHE203
4-25
4. Fee Calculation Configuration: Pricing
Procedure - Process Condition Types
Pricing
Proc.
Cond.
Type
IMG
From
To
Man
Mdt
Stat
Sub
T
Reqmt
AltCT
AltCB
V
Acct
Key
TUI
TUIT
9
CMAT
EMPL
10
MAT
927
TUI
20
If blank, all preceding
cond. types are the basis.
Enter your own formula
for the cond. base value
Subtype controls whether and
in which fields condition
amounts or subtotals are
stored; can be re-used for
further calculation and
requirements
Enter your own preconditions
for access, for example:
if SC = physics
© SAP AG 2010
„
The abbreviations in the figure have the following meanings:
• Man = must be entered manually
• Mdt = condition type is mandatory for this pricing procedure; must find a value
• Stat = is posted statistically
• AltCT = alternative calculation type: This formula determines the value of a condition type
instead of using a condition record; the found extended value replaces all items (that is, the sum
that the condition record would calculate).
• AltBV = alternative condition base value: This formula determines the value of a condition type
instead of using a condition record; the found value replaces the value per each item.
„
Account Key = Grouping for GL Account: This key is mapped to contract object types (IMG path:
Posting → Document Settings → Determine Contract Object Types)
„
Note: The Period Key can be used in combination with the Account Key, for example, if your
institution‘s accounting department requires a unique general ledger per period.
© SAP AG
IHE203
4-26
4. Fee Calculation Configuration: Credit Type
for Pricing
You define values for optimum, minimum and maximum in module master data. However,
you might charge based on module value or attempted credit hours which are set during
booking (SM or SE).
In the configuration table below, enter the credit type to be used in your institution’s fee
calculation. You can enter one of the following values for credit types:
Value
Space or 0
1
2
3
4
Credit type
Credit hour optimum
Credit hour minimum
Credit hour maximum
Credit hours attempted
Module value
Example
If you want to use the credit hour optimum as the reference value for pricing in fee calculation, enter the
value '0' in this field.
© SAP AG 2010
„
Maintain Credit Type for Pricing
„
In this field, enter the Credit Type which should serve as the reference value for pricing in fee
calculation.
You can define these values in Module master data. The attempted credit hours are
defined at the time of Module booking.
You can enter the following values for credit types:
Value
Credit type
Space or O
Credit hour optimum
1
Credit hour minimum
2
Credit hour maximum
3
Credit hours attempted
Module value
„
Example
If you want to use the credit hour optimum as the reference value for pricing in fee
calculation, enter the value '0' in this field.
© SAP AG
IHE203
4-27
4. Fee Calculation Configuration: Module
Booking Status for Fee Calculation
Module Booking Status
Specifies how your institution was to consider the booking status for fee
calculation.
Example: Your institution wants to process successfully completed (2) and
unsuccessfully completed (3) bookings liked booked courses.
© SAP AG 2010
„
Map Module Booking Status for Fee Calculation
„
In this IMG activity, you define the module booking status you want the system to use when it
prices a module.
„
Modules can have the following booking statuses:
• 1 = Booked
• 2 = Successfully completed
• 3 = Unsuccessfully completed
• 4 = Booking cancelled
• 5 = Preselected
• 6 = Prebooked
• 7 = Prebooking cancelled
• 8 = Will be continued
„
Typically, the following booking statuses should result in the same amount:
• Booked
• Successfully completed
• Unsuccessfully completed
„
Setting this definition will reduce work when maintaining condition records.
© SAP AG
IHE203
4-28
4. Fee Calculation Configuration: System
Enhancements - Requirements, Formulas, BAdI
It is possible to add fields to the pricing catalog, code routines in the customer
name space 600-999 or program BAdIs, e.g. Pricing in Student Accounting using
Method SET_ALL
© SAP AG 2010
„
Formulas are represented as FORM routines. They are used in pricing and influence the
determination of prices according to predefined rules.
„
The scale base value (value or quantity the system uses to access a scale in order to determine a
scale level) includes FORM routines, which determine the scale base value according to criteria that
are not defined in the standard system. You enter the scale base value in the Scale formula field. A
formula for the scale base value can define, for example, that partial quantities are taken into
account.
„
Formulas for the condition base value take into account criteria not defined in the standard system.
You enter them in the Alternative formula for condition base value field in the pricing procedure.
The found value replaces the value per each item. A formula for the condition base value can define,
for example, that the condition determination is based on net value or volume.
„
Formulas for determining the condition value include routines, which determine the condition value
according to criteria not defined in the standard system. You enter the formulas for determining the
condition value in the Condition formula for alternative calculation type field in the pricing
procedure. The found value replaces the value for the whole condition. A formula for the condition
value can define, for example, that the system determines the best price for the customer.
„
Customer enhancements are maintained in Transaction VOFM or in the IMG path: Student
Lifecycle Management→ Student Accounting → Fees → Pricing → System Enhancements →
Routines for Requirements and Formulas. In the Transaction, choose Formulas → Scale base or
Condition base value.
© SAP AG
IHE203
4-29
4. Fee Calculation Configuration:
Unit Summary
You should now be able to:
„
Explain the configuration of fee calculation
„
Describe how mathematical parameters are represented in the pricing
„
Describe the various components used in the pricing procedure
„
Identify where customer enhancements are implemented
© SAP AG 2010
© SAP AG
IHE203
4-30
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
5-1
5. Fee Calculation Configuration: Financial
Contents
„
Fee Distribution to several Company Codes
„
Integration with Controlling
„
Posting FI-CA Documents
© SAP AG 2010
© SAP AG
IHE203
5-2
5. Fee Calculation Configuration: Financial
Unit Objectives
At the conclusion of this unit, you will be able to:
„
Explain assignment of accounting objects
© SAP AG 2010
© SAP AG
IHE203
5-3
5. Fee Calculation Configuration: Financial
Business Scenario
„
The tuition revenue for all programs and courses is allocated to the Provost
Office and has to be tracked by term.
„
Revenue for additional study related fees is retained by the unit which offers
the program or course.
„
The meal plan revenue goes to the Residence Office.
© SAP AG 2010
© SAP AG
IHE203
5-4
5. Fee Calculation Configuration: Financial
Multiple Company Codes
An institution maintains centers in several countries
„
Use the company code of the module or the program of study for posting
„
Default values for student master data/contract account
„
Evaluation of the company code will be analog to CO assignment
„
Offering organizational unit for module or program of study
Top organization unit
Fixed organizational unit
Standard company code in student account
Cross-company-code documents can be posted
© SAP AG 2010
© SAP AG
IHE203
5-5
5. Fee Calculation Configuration: Financial
Fee Revenue Distribution
SAP developed IT 1759 specifically for the distribution of fee revenue.
1. Determine which area of responsibility (org unit/cost center/fund center) should
receive the revenue calculated in the SLCM Fee Calculation.
2. Find out if some or all revenue has to be tracked by academic period/term.
3. Work with Comptroller’s Office to assign the appropriate objects like the Business
Area and Controlling and/or Funds Management elements.
4. It is also possible to split revenue by percentage.
© SAP AG 2010
„
The fee distribution during fee calculation can be used to replace the existing HR Cost Distribution,
which was formerly used and can even be used in the future. The so far used HR CO integration
caused integration problems, where cost and revenue distribution had to be applied at an org unit
level. It is now possible to calculate and post module group related fees.
„
The maintenance of Infotype 1759 is offered for the object types event package, module, module
group, program of study, org unit and location. To integrate the new fee distribution infotype into
fee calculation additional rule elements are provided, which evaluate the new infotype. The new
infotype offers also the availability to maintain reporting segments and business area. The fields will
be taken into consideration during fee calculation and posting as well.
„
More detailed information about the rule elements can be obtained from the IMG documentation
under: Student Lifecycle Management -> Student Accounting -> Pricing -> Co Integration
„
For details on this subject see SAP Note 964336. It enables you as well to calculate and post one
module group fee per program of study. A infotype is offered for module groups to maintain the
module group fee category (infotype 1754), which will be evaluated later in fee calculation. In a
further customizing table a modulegroup can be pre-selected for pricing and where necessary
changed in a further BADI. For more information please refer to IMG documentation under: Student
Lifecycle Management -> Master Data -> Academic Structure -> Module Groups -> Fee
Calculation.
© SAP AG
IHE203
5-6
5. Fee Calculation Configuration: Financial
Derive Objects for Fee Distribution
SAP provided a number of rules with different evaluation paths.
For example, if tuition is going to the top Organization Unit then you would use rule J.
If your institution charges all students a fee to support athletic facilities then the revenue might
go to the Athletic Department and you would use rule K.
If some Programs have specific fees in addition to tuition then you might want to give the
revenue to the unit which is responsible for the SC. You might use rule G.
© SAP AG 2010
© SAP AG
IHE203
5-7
5. Fee Calculation Configuration: Financial
Integration with Controlling - Map Sessions
This step is only needed if you have to track revenue by academic term.
1. Create the subtypes of IT 1759:
a) 9010: Fall
b) 9030: Spring
c) 9040: Summer
Note: use time constraint = 2 (with gaps)
2. Map the sessions to the subtypes:
Note: watch out when using sub sessions
© SAP AG 2010
Map Academic Sessions to Subtype of Infotype 1759
„
In this IMG activity, you map academic sessions to the subtypes of the infotype 1759. This may be
useful if you wish to post your revenues in different Controlling Objects (e.g. cost centers) by
academic term. Use Transaction PP01 to enter the Controlling values.
„
For the subtype Determination, a session has to be used in the CO rule function modules. This could
either be a session taken from the program registration (structure CMAC_SC) or module registration
(structure CMAC_SM). You must also take the session hierarchy into account.
„
The sessions are derived from the following rule element function modules as follows:
• CMAC_ACC_1759_CG_O_DERIVE: The module groups are included in the same structure as
the program registration. As a result, the system uses the program registration session.
• CMAC_ACC_1759_SC_O_DERIVE: The system uses the program registration session.
• CMAC_ACC_1759_SE_F_DERIVE: The system uses the module registration session.
• CMAC_ACC_1759_SE_SM_O_DERIVE: As above.
• CMAC_ACC_1759_SM_O_DERIVE: As above.
• CMAC_ACC_1759_FIXED_ORG_DERIVE: First, the system checks if a module booking
exists for the object currently being processed. If a module booking was transferred to the
function module, then the system uses the module registration session. If no module booking was
transferred, then the system uses the program registration session.
• CMAC_ACC_1759_TOP_ORG_DERIVE: As above.
• CMAC_ACC_1759_ST_F_DERIVE: As above.
„
Once a session has been determined, the session-mapping BAdI and session hierarchy are processed.
„
…
© SAP AG
IHE203
5-8
…
„
The session-mapping BAdI (HRPIQ00PERIOD_MAP) is called with the Student Lifecycle
Management processes Create Module Booking and Reregistration for Program.
„
Then, the system processes the session hierarchy. If a program of study or a program type is
available, then the system determines the possible sessions for these objects. Finally, the system
determines for the module booking session a session available in the higher sessions read for
program type or program of study.
„
In case of different sessions in the module booking and program registration, the system firstly
determines the subtype with module booking session and then with the derived session described in
the algorithm above. Once a session is determined, a mapping table is processed, where subtypes of
infotype1759 are mapped to academic sessions.
„
If a subtype is determined, the CO Rule function module reads infotype 1759 with this particular
subtype. Where no subtype is determined, the system reads infotype 1759 with a blank subtype.
© SAP AG
IHE203
5-9
5. Fee Calculation Configuration: Financial
CO assignment using CO Rule
Choices:
IMG
Define CO Account Assignment for Fee Distribution
-> based on Period and Account Key (G/L Account)
IMG: Student Accounting/Fees/Pricing/Integration with Controlling
Period Key
Account Key
CO Rule
*
SCF
0004
SP04
TUI
0002
SF01
TUI
...
Org.Unit
0002
...
...
50000051
50000052
...
© SAP AG 2010
„
SAP delivers rule elements with a function module. You can also set up your own rules and code an
appropriate function module.
„
Assume the following:
„
Rule 0001 means CO object is derived from Top Unit
„
Rule 0002 means CO object is derived from a Fixed Org Unit
„
Rule 0003 means CO object is derived from Program of Study or Org Unit
„
Rule 0004 means CO object is derived from Module or Org Unit
„
Etc.
See Posting Area = PC07
© SAP AG
IHE203
5-10
5. Fee Calculation Configuration: Financial
Assignment to Objects
Use Transaction PP01 to assign the Fee Distribution to various objects.
All CO & FM
fields are
available except
Funded
Programs
Use Pct to split
revenue
© SAP AG 2010
„
In Infotype 1759, it is now possible to assign Business Area.
„
If your institution has activated Controlling and Funds Management (Public Sector Management),
you may also enter the appropriate Controlling and Funds Management fields. There is currently
no field for „Funded Program“
„
Use Transaction PP01 to maintain the Fee Distribution Infotype for the appropriate object, e.g. O or
SC or SM depending on your requirements.
„
Note: If possible assign the accounting objects to the Organization Unit to minimize future
maintenance.
© SAP AG
IHE203
5-11
5. Fee Calculation Configuration: Financial
SLCM Fee Postings
Header
BP Position 1
G/L Position 1
BP Position 2
G/L Position 2
...
...
G/L Position n
BP Position n
Student ID
Revenue
account
Reconciliation
account
Customizing
account
determination
Acc. Det. ID (Student Account Category)
Main transaction
Sub-transaction
IMG: Contract Accounting
Customizing
account
determination
IMG: SLCM
Student Accounting
© SAP AG 2010
„
Since all student accounts have the same contract account category (for example: ST), the contract
account category cannot serve as differentiator for determining accounts.
„
Since all sponsor accounts may share the same contract account category (for example: SP),
additional parameters are needed to determine accounts.
„
Therefore, the G/L account determination of postings originating in Student Lifecycle Management
depends on additional criteria.
© SAP AG
IHE203
5-12
5. Fee Calculation Configuration: Financial
Posting
Define at least one currency
FICA documents also need a Document Type and a Number Range
© SAP AG 2010
„
Requirement:
• Before you decide to use multiple currencies consider the implications with your experts in FI.
• The document type and its associated number range are defined using the IMG path:
- Financial Accounting > Contract Accounts Receivable and Payable > Basic Functions >
Postings and Documents >
- Basic Settings > Maintain Document Number Ranges
and
- Document > Maintain Document Assignments > Document Types > Maintain Document
Types and Assign Number Ranges
„
If your institutions has a large student body, it is recommended that you use parallel processing
which requires additional number ranges and reconciliation keys depending on your system
environment.
„
You may also need to adjust FI-CA Event P901.
© SAP AG
IHE203
5-13
5. Fee Calculation Configuration: Financial
Account Key
Pricing
Proc.
Cond.
Type
IMG
From
To
Man
Mdt
Stat
Sub
T
Reqmt
AltCB
V
Acct
Key
TUI
TUIT
CMAT
EMPL
AltCT
927
10
MAT
TUI
20
© SAP AG 2010
„
Account Key is linked to the Condition Type and mapped to G/L accounts in the subsequent steps
© SAP AG
IHE203
5-14
5. Fee Calculation Configuration: Financial
Determination of SLCM Fee G/L Accounts
Select key fields
Mandatory
xx
Acct Key
Student Group
Fee Category
Period Key
Used
X
X
X
X
IMG
IMG: Student Accounting/Fees/Posting/FI-CA documents/Determine G/L account
Acct Key
ST Group
TUI
NRES
TUI
RES
HOU
Reg
...
...
Fee Category
Period Key
G/L Account
*
800000
UG
*
800001
RES
*
800003
...
...
...
© SAP AG 2010
„
Student Group = Individual study data (student master data)
„
Fee Category = Fee calculation data (student master data)
„
Period Key = Academic Term
• Posting Area = PC05
„
In a subsequent step, you assign one or more account key(s) to a contract object used for posting the
fees in PSCD.
• Posting Area = PC08
„
Requirement:
• The GL Accounts have been defined in the General Ledger.
• For P&L accounts also create the related Cost Element in Controlling
• Create the appropriate Commitment Item when using Funds Management
„
Recommendation: Use same value across all components, e.g.
© SAP AG
IHE203
5-15
5. Fee Calculation Configuration: Financial
Posting
The fee postings can be differentiated by fee type using the Contract Object Type (COT).
In the next step, you assign the account key to the contract object types set up previously.
This example shows a 1:1 mapping.
That is not necessary. You could map
Several account keys to one Contract
Object Type.
Example:
Your institution defines a COT = “RES” meaning
Residence Charges to include Housing and Meals.
However, for accounting purposes those are posted to
different G/L accounts.
You would map:
Acct Key COT
HOU
RES
MEA
RES
© SAP AG 2010
„
Requirement:
• You have defined the Contract Object and corresponding number ranges
Financial Accounting > Contract Accounts Receivable and Payable > Basic Functions > Contract
Object
© SAP AG
IHE203
5-16
5. Fee Calculation Configuration: Financial
Determination SLCM Main & Sub Transactions
Select key fields
Mandatory
Origin
Student Status
Processing Mode
Used
X
X
X
Fee Postings (PC04)
Maintain Main & Sub Transactions
Origin
Student Status
Processing Mode
P1
*
P1
1
*
*
P2
*
*
...
...
...
Main
Sub
9000
0010
9000
0020
9000
0030
...
...
© SAP AG 2010
„
For documents originating in the SLCCM Fee Calculation, the main and sub transactions are
assigned based on document source, student status, and/or processing mode.
„
Document source:
• P1 = IS-PS: Student Fees
• P2 = IS-PS: Manual Adjustments of Student Fees
„
Student status: Active or Inactive
„
Processing mode: Registration (real) or Expected
„
See posting area PC04
Note: You must have already defined the main and sub transactions in Contract Accounting.
„
The Reconciliation Accounts (Receivables) are based on the above main and sub transactions as
well as the company code and account category.
„
See posting area P000
„
Requirement:
• You have defined the Main and Sub Transactions in Contract Accounting:
Financial Accounting > Contract Accounts Receivable and Payable > Basic Functions >
Postings and Documents > Document > Maintain Main Transactions
and
> Maintain Transactions for Public Sector Contract Accounting > Maintain Sub-Transactions
© SAP AG
IHE203
5-17
5. Fee Calculation Configuration: Financial
Receivable Account
All financial activity posted to the student’s account will also post to the AR in
the General Ledger. Since FI-CA is a sub ledger only FI-CA can post to this
AR account. Therefore, it is also referred to as a “Reconciliation Account”.
Ensure that the AR account is set up with a
Reconciliation Type = V for Contract
Accounting
© SAP AG 2010
„
Requirement:
• You have created a Receivable Account for Students in the General Ledger
• You have created a Commitment Item if Funds Management is active
© SAP AG
IHE203
5-18
5. Fee Calculation Configuration: Financial
Unit Summary
You should now be able to:
„
Explain the configuration of revenue distribution
„
Identify connection between SLcM and FICA configuration
© SAP AG 2010
© SAP AG
IHE203
5-19
© SAP AG
IHE203
5-20
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
6-1
6. Fee Calculation Other Fees: Overview
Contents
„
Admission Application Fees
„
Graduation Fee
„
Additional Fees
© SAP AG 2010
© SAP AG
IHE203
6-2
6. Fee Calculation Other Fees: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Process other fees such as Admission Application Fees
„
Graduation Application Fees
© SAP AG 2010
© SAP AG
IHE203
6-3
6. Fee Calculation Other Fees: Business
Scenario
„
Your university charges applicants a small fee based on the type of
application.
„
Your student wants to graduate and applies for the final degree audit and
participation in the graduation ceremony.
© SAP AG 2010
© SAP AG
IHE203
6-4
6. Fee Calculation Other Fees: Other Fee
Types
Goal:
„
Make process easy and convenient for Applicant/Student
„
Reduce manual effort collecting these small amounts
Solution: web-based payment card option
© SAP AG 2010
„
Most applicants are expecting to make their application on the web and complete the payment
process while they are at it. This is especially convenient for international students.
„
Typically, the fees involved in these process are small. However, the staff cost related to collecting
cash payments or processing checks is unrelated to the payment amount.
„
Credit card authorization is done in a matter of seconds and the university is sure to collect the
payment.
© SAP AG
IHE203
6-5
6. Fee Calculation Other Fees: IMG
The primary configuration tasks to the Admission Application is in the IMG under:
Cross-Application Components > Notification
© SAP AG 2010
© SAP AG
IHE203
6-6
6. Fee Calculation Other Fees: Other Fee
Types - ISR based
The Application Fee Process uses SAP’s Internet Service Request (ISR)
Define admission ISR scenarios based on your business needs, e.g.:
Undergraduate Admission
Graduate Admission
„ International Admission
„
„
It is possible to charge different amounts based on the application scenario.
The financial document can be posted to:
A fixed business partner such as the Admissions office
„ The applicant’s account
„
IMG: Student Lifecycle Management Student Accounting
Application Fee Requests
Fees
© SAP AG 2010
„
Your institution may accept applications over the Internet. It may consider applications only if the
application fee has been paid. Prerequisites:
• An admission application (notification) exists.
• A business partner exists.
- The fee can be posted to predetermined business partners, for example, the admissions office
for undergraduate applications and to graduate school for graduate applications.
- The fee could also be posted directly to an application’s account. In this case, the ST/BP/CA
must already exist.
„
The appropriate customization must be in place:
• Payment Method, Main and Sub Transactions, Document Type, Number Assignment and
Accounting Information
• The ISR service passes the appropriate data to function CMAC_ISR_FEES. This function posts
the revenue and related payment request after successful authorization of payment data.
• Add function module CMAC_EVENT_0020 to FICA Event 0020 (installation-specific) to
change the status of the application, for example, from created to paid when executing the
Payment Run clearing web-based payments.
• Portal settings
• Payment Authorization Interface with 3rd party
© SAP AG
IHE203
6-7
6. Fee Calculation Other Fees: Other Fee
Types - Self-Service Based
Web-based
Self-Services such as the Graduation Application or Transcript
Request may include posting of fees to the student’s account.
The
charge could be included in the regular billing cycle. Alternatively, the web
service could link to SAP’s Biller Direct for immediate payment by payment card or
e-check.
Mandatory configuration steps:
1. Define Attributes for Individual
Fees
2. Define Behaviour of Student
Correspondence Requests
© SAP AG 2010
„
Define Attributes for Individual Fees. IMG path: Student Lifecycle Management>Student
Accounting>Fees>Other Fees.
„
Define Behaviour of Student Correspondence Requests. IMG path: Student Lifecycle
Management>Processes in SLCM > General Settings > Correspondence > Correspondence
Applications of Students > Define Behaviour of Student Correspondence Requests.
„
The graduation process allows for additional options.
„
See configuration under the IMG path: Student Lifecycle Management> Student Liftecycle
Management
Processes >Academic Records>Graduation>Application for Graduation.
1. When to charge the fee (Define Fee Mode for Graduation Request)
2. How much to charge by Program Type or specific Programs (Derive Fee Type for Graduation
Request)
© SAP AG
IHE203
6-8
6. Fee Calculation Other Fees: Unit Summary
You should now be able to:
„
Describe the process of web-based fee types
© SAP AG 2010
© SAP AG
IHE203
6-9
© SAP AG
IHE203
6-10
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
7-1
7. Sponsoring in Student Lifecycle Management
Overview
Contents
„
Basic Concepts
„
Financial Aid Calculation: Process Overview
„
Sponsoring-relevant Master Data
„
Sponsoring Configuration
© SAP AG 2010
© SAP AG
IHE203
7-2
7. Sponsoring: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Discuss the different processes for internally and externally managed
financial support.
„
Store sponsor master data, grant master data and conditions, and payment
conditions.
„
Configure the system for processing different forms of financial support.
© SAP AG 2010
© SAP AG
IHE203
7-3
7. Sponsoring: Business Scenario
„
Your university processes financial support for students including public and
private sponsorships.
„
A student expects a sponsorship that covers part of the tuition fees. You
want to reflect the process from expectation until disbursement in your
accounting system.
© SAP AG 2010
© SAP AG
IHE203
7-4
7. Sponsoring: Externally and Internally
Managed Aid
For Sponsoring, a distinction is made between externally and internally managed aid:
Externally managed aid
„
The process from application for aid to disbursement authorization is triggered and controlled
with external software.
„
The relevant information for posting comes through an interface.
„
In Student Lifecycle Management, the incoming information is displayed on the Grant
Assignment tab of the Student Master.
Internally managed aid
„
The process is managed entirely within Student Lifecycle Management.
„
No interface is needed.
„
All relevant information is maintained in the Grant Assignment tab of the Student Master.
© SAP AG 2010
© SAP AG
IHE203
7-5
7. Sponsoring: Externally and Internally
Managed Aid in SLCM
Externally managed aid
Internally managed aid
Paperwork
Feeder System
Interface
Maintain and update
sponsor-relevant data
(amounts, status, due
date)
Manual entry
SAP Student Lifecycle
Management
© SAP AG 2010
„
For Externally Managed Aid, SAP provides several interfaces (RFC or BAPI) used to exchange
information between the third-party software and SAP Student Lifecycle Management. In general,
aid should not be disbursed unless the student meets certain requirements such as booking a certain
number of credit hours and maintaining good academic standing.
„
Student Lifecycle Management contains personal and academic data, which can be pushed to or
pulled by the third-party software, which checks if aid can be given (expected or actual).
„
The third party initiates the financial transactions in background or real-time with SAP Exchange
Infrastructure (SAP XI).
„
Student Lifecycle Management receives transactions and updates the Student Master Data (Sponsor
Data tab) and posts FI-CA documents to the student’s and sponsor accounts.
„
Internally Managed Aid is often funded by private corporations such as employers sponsoring the
ongoing education of their employees. This is also referred to as third-party billing because a third
party is billed instead of the student. Internally managed aid may also be subject to certain rules,
which are kept in the student master (Grant Assignment → Grant Details).
„
More recently, internally managed aid is used to disburse payments from pre-paid tuition plans.
„
Note: If the sponsor does not pay, the liability is transferred back to the student. Ultimately, the
student is responsible for the payment of her or his own debts.
© SAP AG
IHE203
7-6
7. Sponsoring: Grant Evaluation: Process
Overview
Selection
1 = expected
Check:
1. Grant status
2.
3.
Does status
allow
calculation?
Does status
allow
posting?
Process Mode
Student
Master Data
2 = authorized disbursement
Check:
1. Grant status
2.
IMG
3.
Does status
allow
calculation?
Does status
allow
posting?
Result
© SAP AG 2010
„
Internally managed aid are calculated and posted using the Grant Evaluation transaction. From the
SAP Easy Access Menu, choose Student Lifecycle Management → Student Accounting → Grants.
„
With Grant Evaluation, you can calculate a grant that many students or a certain group of students
are entitled to.
„
Note: You can display the calculation result before posting only if you calculate for one single
student.
„
The evaluation modes, expected or authorized disbursement, are hard-coded.
„
The program checks the actual status of the sponsorship against the sponsor information in the
student master.
„
Depending on the customizing of the statuses, the program will post a statistical or real document.
© SAP AG
IHE203
7-7
7. Sponsoring: Grant Evaluation
Use SAP methods or
develop your own
© SAP AG 2010
„
After the configuration is completed and the sponsor data is maintained for internally managed aid,
you can execute Grant Evaluation: From the SAP Easy Access Menu, choose Student Lifecycle
Management → Student Accounting → Grants → Grant Evaluation.
„
Selection methods: Choose one of the selection methods:
• Select an individual student or a group of students.
• You can also execute the calculation for one or more grants. If you calculate many students at
once, you should limit the calculation to certain grants or a small range of grants.
„
The evaluation modes affect processing as follows:
• Expected: The system posts the grant evaluation results to the student’s account as statistical
documents. The amounts are never disbursed to students.
• Authorized disbursement: The system posts the grant evaluation results to the student’s account
as a “real” posting. A payment to the student shows as a credit amount which can be cleared or
disbursed. If a student has repay all or a portion of the grant then another grant evaluation has to
be executed to generate a debit entry.
© SAP AG
IHE203
7-8
7. Sponsoring: Grant Evaluation - Application
Log
The Application Log is available for Grant Evaluations
Select
© SAP AG 2010
„
You access the application log as follows: From rhe SAP Easy Access Menu, choose: Student
Lifecycle Management → Student Accounting → Grants → Application Log.
„
The log provides an overview of the runs during a specified period. Specify a user ID in the
selection parameters to narrow your search.
„
To see the log details for a specific run, double-click on the desired run. Alternatively, you can
highlight the desired run and use the Display Log Details icon (eye glasses) or F9.
© SAP AG
IHE203
7-9
7. Sponsoring: Grant Evaluation – Application
Log Details
The Application Log now lists documents and errors for each student.
© SAP AG 2010
„
The log detail screen provides the following information:
• Quick statistics on the number of students processed in a particular run and the total number of
messages by message status, that is, errors (red), warnings (yellow), and successes (green).
• Detailed information by student (filter by message status: select the desired status and deselect
the others).
• Detailed error message(s) per student (click the question mark icon).
© SAP AG
IHE203
7-10
7. Sponsoring: Disbursements - Preparations
Before you can calculate and post financial support, you must
perform the following steps:
1. Enter sponsor master data: business partner, sponsor account.
2. Enter grant master data: payment conditions, sponsored fees, other rules.
3. Enter GL account and FM determination rules: Main and sub transactions for sponsor and
student, document type and number ranges.
4. Enter student master data on Grant Assignment tab: which grant, which amount, under
which conditions, and when.
© SAP AG 2010
„
Steps 1 to 3 are necessary for externally and internally managed aid.
„
Step 4:
• For internally managed aid, the information required in this step must be entered manually.
• For externally managed aid, the interface updates the Grant Assignment tab of the Student
Master.
© SAP AG
IHE203
7-11
7. Sponsoring: Grant Master Data and Sponsor
Account
Student Lifecycle Management
Sponsor
Define Grants and
Maintain Grant
Master Data
Contract Accounting
Business Partner
Sponsor
Account
Grant 1
IMG
Name Grant
Grant Type
„ SP Pattern
„ Sponsor Name
„ Sponsor Account
„ Internally/externally
administrated
„ Re/Payment
„ FM Area, Fund
„
„
Sponsor
Account
Grant 2
Sponsor
Account
Grant 3
© SAP AG 2010
„
For sponsor accounting, you link a grant to a sponsor account. However, because contract accounts
and contracts must belong to at least one business partner, you must create a business partner for
every sponsor.
„
Most sponsors offer just one grant.
„
Some government agencies may offer multiple aid programs as depicted in the picture above.
„
Some institutions receive many individual external scholarships payment from many sources. It
might be more practical to post them under a „generic“ Business Partner.
© SAP AG
IHE203
7-12
7. Sponsoring: Grant Master Data
Grant Masters are required for all Grants
This links to a third-party system for externally managed aid
New:
Allows institution to
track aid as expense
© SAP AG 2010
„
A typical US university administers more than 1000 aid programs and grants.
„
The Grant ID is the link with the feeder system. It is important that you keep the grant master and
the feeder system synchronized. From the SAP Easy Access Menu, choose Student Lifecycle
Management → Student Accounting → Grants
→ Display Grant Master Data
→ Edit Grant Master Data
„
Grant type allows you to classify aid programs that follow the same process or have the same
reconciliation and reporting requirements. The grant type influences many parameters such as main
and subtransaction, GL account determination.
„
Examples of grant type include scholarship, loan, assistantship, and private sponsorship
„
You can also indicate if a grant is person related, that is, can be given only to a specific student, or if
it can be awarded to another student if the first student rejects it.
„
You can maintain minimum amount thresholds for payment and re-payment of the disbursed
amount.
„
With ERP 2005, SAP provides the Account Assignment section which allows institutions more
flexibility. Some universities use Business Area or post financial suppport (for example, internally
funded aid or institutional aid) as expenses requiring assignments in Management Accounting.
Student Lifecycle Management includes these fields on the Grant Master.
„
The Grant Master data also contains the Funds Management (FM) objects rather than using
FMDERIVE (depends on institution‘s set-up).
© SAP AG
IHE203
7-13
7. Sponsoring: Grant Details for SLCM
Managed Grants
Opportunity:
Set-up internally managed Grant Masters with default values in the Grant Details
Defaults will be copied to Grant Assignment (detail) Tab on Student Master.
Benefit:
Reduces data entry when assigning internally managed grants to students
Improves data quality through standardization
© SAP AG 2010
„
Contract Object Type Grouping (COT Grouping):
• Groups the contract object types which are sponsored by a specific grant.
„
Grant Prerequisite Type:
• You can assign the prerequisite type for a specific grant to an internally managed grant in student
master data. To do so, choose the details of the internally managed grant on the Grant
Assignment tab.
• Each prerequisite type can have a quantitative requirement and a maximum of two qualitative
requirements. These enable you to map sponsor specifications, like registration in a specific
program or module, or completion of certain number of credits in the system. The standard
system contains the following prerequisite types:
- Minimum number of credits (contains a quantitative requirement)
- Specified program booked (contains a qualitative requirement)
- Specified module booked (contains a qualitative requirement)
- Minimum number of credits in a module (contains a quantitative and a maximum of two
qualitative requirements)
„
Default Disbursement Amount for Disbursement Type:
• The system uses the default amount in grant evaluation if the student has not yet registered for
any programs or booked any modules.
© SAP AG
IHE203
7-14
7. Sponsoring: Student Master Data: the Grant
Assignment Tab
Finally -> Grant Assignment
Grant Assignment
Grant
SP Name
Year
Session
Max Amt
Status
Earl. Disb.
Lat. Disb
Remark
Future
IBM
2005
001
1.300 USD
acpt
05/01/2005
10/01/2006
Photo!
Button: Details of Internally Managed Grants
COT Grpg
No
Prereq. Type
ALL
1
program
TUIT
2
SM
Qnt.Rqmt
10
C.Type QualReq‘t1
crh
Table: Student Grant Detail
QualReq‘t2
Disburse.Type
%
Amount
5000523
1.300
5000523
500
© SAP AG 2010
Grant Assignment
„
For externally managed aid, the interface will fill in the sponsor data on the initial pass.
„
For internally managed aid, you must enter the appropriate information before grant evaluation can
calculate aid and post the result.
„
Grant details apply only to internally managed aid. If a sponsor has particular requirements then you
can use the defaults values from the Grant Master or manually enter requirements.
„
Grant prerequisite and disbursement types are predefined.
„
If none of the delivered conditions meet your needs, you can also develop your functions.
© SAP AG
IHE203
7-15
7. Sponsoring: Grant Master Configuration:
Fees & Appropriations
Student
Account
Contract Object Types
Tuition
Meal Plan
Special Class
C.O.T.
Group 1
C.O.T.
Group 2
C.O.T.
Group 3
Appropriation 2
Appropriation 1
© SAP AG 2010
„
A sponsor may indicate that a specific grant can pay only for specific fees/charges. Universities try
to discourage restrictions because of the administrative overhead. To assist the process, you set up
groups of fees (contract object type groupings or C.O.T. group) and groups of funding
arrangements (appropriations) and then match them as appropriate.
„
Example: Grant Aid 1 can fund all fees/expenses.
• Step 1: Assign one or more contract object types to a contract object type group 2 (C.O.T. group)
named ALL.
• Step 2: Assign C.O.T. group ALL to appropriation 2.
- Many grants have similar rules. Therefore, it is useful to establish patterns that can be reused
when setting up grants.
• Step 3: Assign appropriation 2 to Grant Aid 1 and reuse that particular appropriation for all
grants that have the same rules.
© SAP AG
IHE203
7-16
7. Sponsoring: Grant Configuration
For Financial Support consider the following:
1. Is it internally or externally managed aid?
2. Which fees are sponsored, e.g., all costs, tuition, special class, housing?
3. Does a student have to meet certain prerequisites to be eligible for a specific
grant, e.g., minimum of credits, certain program of study, certain courses?
4. What are the grant disbursement conditions, (up to) a certain percentage or
a certain amount?
5. What are the process steps? When is aid disbursed? Should it be displayed
in the student account, e.g., expected, awarded, accepted and disbursed?
6. Where do the postings for a specific aid program flow, e.g., determine
appropriate account assignments for your institution?
© SAP AG 2010
„
Remember, Grant Types can be used to control the posting of financial documents in Contract
Accounting.
© SAP AG
IHE203
7-17
7. Sponsoring: SLCM Managed Aid: Grant
Status Example
A university defines the following process states in connection with
private sponsors:
„ To
„
Aid can be calculated as expected aid and will be posted as statistical document
Confirmed = Student received and accepted the confirmation from the sponsor
„
No aid will be displayed or calculated yet
Expected = Student told that he actually applied for aid and for which amount
„
be defined = Student told that she will apply for aid
Aid will be calculated and disbursement is authorized; open item will be posted on
student account and on sponsor account
Cancelled = Sponsor did not pay/student will not use aid
Postings will be reversed
© SAP AG 2010
„
For internally managed aid, you can define your own statuses. Your institution could decide to
minimize administrative work and to record only confirmed financial aid.
© SAP AG
IHE203
7-18
7. Sponsoring: SLCM Managed Aid - Grant
Status
In Customizing, you define the statuses according to the steps in the
sponsoring procedure at your institution e.g.:
„ expected – confirmed
„ announced - awarded - accepted
IMG
It is also possible to define a status for cancellation to indicate that a
previously posted grant had to be reversed.
You define
„ A standard version for statistical documents.
„ Whether the status is blocked for any calculation (expected aid or aid
that is already authorized for disbursement).
„ Whether the status allows for disbursement authorization and actual
posting on student’s and sponsor’s account.
© SAP AG 2010
„
You define the different statuses in customizing under the IMG path: Student Lifecycle Management
→ Student Accounting → Grants → Define Grant Status → Grant Management with External
System → Define Grant Statuses for External Management System. Based on your settings, grants
will be evaluated and posted.
„
You also define a standard version. If a grant status reaches that standard version, a statistical
document is displayed.
© SAP AG
IHE203
7-19
7. Sponsoring: SLCM Managed Aid - Grant
Status Example
Example of possible configuration settings:
Exp. Grant
IMG
Status
Version
Disb. Auth.
TBD
002
Item is not calculated
(result = zero) and not
posted
EXP
002
Item will be calculated;
will be posted as a
statistical document
CFM
002
Item will be calculated
and will be posted as real
open item
CAN
002
Calculation result = zero;
already posted items will
be reversed
© SAP AG 2010
„
TBD (to be defined): If you don not select a check box, the grant will not be calculated (that is, the
result will be zero), either in expected mode or in authorized disbursement mode. Nothing will be
posted.
„
EXP (expected): In expected aid mode, the grant will be calculated and posted as a statistical
document. In disbursement authorized mode, the grant will neither be calculated nor posted.
„
CFM (confirmed): In expected aid mode, the grant will not be calculated. In authorized
disbursement mode, the grant will be calculated and the result will be posted as real (actual) debit on
the student‘s account and as real (actual) credit on the sponsor‘s account.
„
CAN (cancelled): The calculation result will be zero. If a statistical or real document was already
posted before, it will be reversed.
„
Version 002: In the definition of the versions for statistical documents, you define the standard
display version. Only statistical documents with this specific version show up in the account display.
This version is relevant only for statuses that include a posting and do not yet lead to the actual
disbursement authorization, that is, do not lead to the posting of a real credit or debit.
© SAP AG
IHE203
7-20
7. Sponsoring: Document Versions
As long as financial support is not confirmed or accepted, you can post
the amount as statistical document. These documents can have different
versions that you assign to the different steps in the procedure from
expectation until confirmation.
Version
Status
Display?
001 expected
002
IMG
ST
1000
awarded
003 accepted
SP
With this configuration, only
financial aid that is already
accepted is displayed
1000
© SAP AG 2010
„
You define the standard display version when you define the versions for statistical documents.
Only statistical documents with this version show up in the account display. Actual postings will
always be displayed.
„
For internally managed aid, all statuses are assigned to the same version. If this version is being
displayed, you see the document. If not, you cannot see it.
„
The status for externally managed aid can be assigned to different versions depending on the process
stage, that is, awarded, accepted or disbursed.
© SAP AG
IHE203
7-21
7. Sponsoring: Summary of Configuration
Steps
1. Define the business partner type and number ranges
2. Define sponsor account category (link to Student Lifecycle
Management)
3. Configure Grants:
IMG
© SAP AG 2010
„
IMG path: Student Lifecycle Management → Student Accounting → Grants.
„
You may need to adapt the interfaces between SAP and the complementary software product to fit
your institution‘s requirements.
„
To enhance the standard solution you can use:
• BAdI: Checks Before Posting of Grants
• If you want to perform additional customer-specific checks before you disburse grants or post
anticipated grants. You must implement the method GRANTEVAL_CHECK before you can
perform these checks. Please, see the documentation for details.
• FI-CA Event P901
If you have institutional requirements for the reconciliation key.
© SAP AG
IHE203
7-22
7. Sponsoring Process: Determining G/L
Accounts for SLCM Postings
Header
BP Position 1
G/L Position 1
BP Position 2
G/L Position 2
...
...
G/L Position n
BP Position n
Student ID
Revenue
account
Reconciliation
account
Customizing
account
determination
Acc. Det. ID (Student Account Category)
Main transaction
Sub-transaction
IMG: Contract Accounting
Customizing
account
determination
IMG: SLCM
Student Accounting
© SAP AG 2010
„
As all student accounts have the same contract account category (for example: ST), the contract
account category cannot serve as differentiator for determining accounts.
„
As all sponsor accounts may share the same contract account category (for example: SP), additional
parameters are available to determine accounts.
„
Therefore, the G/L account determination of postings originating in Student Lifecycle Management
depends on additional criteria.
© SAP AG
IHE203
7-23
7. Sponsoring Process: Posting
It is possible to work with one document type or to use several ones.
© SAP AG 2010
„
The document type and its associated number range are defined in the IMG paths:
• Financial Accounting > Contract Accounts Receivable and Payable > Basic Functions >
Postings and Documents > Basic Settings > Maintain Document Number Ranges
and
• Document > Maintain Document Assignments > Document Types > Maintain Document Types
and Assign Number Ranges
© SAP AG
IHE203
7-24
7. Sponsoring Process: Determine Main and
Sub Transaction
If your institution tracks the sponsors by different receivable accounts, it might
be appropriate to define the Main and Sub Transactions by Grant Type.
© SAP AG 2010
„
Requirement:
• You have defined the Main and Sub Transactions in Contract Accounting: IMG path:
- Financial Accounting > Contract Accounts Receivable and Payable > Basic Functions >
Postings
and
-
Documents > Document > Maintain Main Transactions
and
- > Maintain Transactions for Public Sector Contract Accounting > Maintain SubTransactions
© SAP AG
IHE203
7-25
7. Sponsoring Process: Determination of SLCM
Grant G/L Accounts
Select key fields
Mandatory
xx
Grant Type
Used
X
IMG
IMG: Student Accounting/Grants/Posting/Define Clearing Accounts
Grant Type
*
SP CI Acct
ST CI Acct
194500
194500
SL
194510
194510
Student Loan
SC
194590
700500
Scholarship
...
...
...
© SAP AG 2010
„
The Grant Type identifies different financial aid programs.
„
Your institution may want to post to different G/L accounts to assist with the sponsor’s
reconciliation process. For example, you may want to keep loans separate from scholarships.
„
Although the IMG refers to clearing accounts, the G/L accounts could also represent revenue or
expense accounts. If you use P&L accounts, you will have to define CO objects in the Grant Master.
„
The Funds Management objects are derived from the grant master.
„
Posting area = PC09
© SAP AG
IHE203
7-26
7. Sponsoring Process: Posting Grant
(Financial Aid) Disbursement
Expense Acct.
Grant Clearing Acct.
1000
1000
1000
1000
SP
ST
2150
Revenue Acct.
1000,
grant xy
PERSL
“real”
1000,
beneficiary abc
PERSL
real
disburse?
© SAP AG 2010
„
The Grant Evaluation (internally managed aid) or Financial Aid Interface (externally managed aid)
creates two documents when posting estimated or actual financial aid:
• A credit entry on the student‘s account
• A debit entry on the sponsor‘s account
„
Due to technical constraints related to Funds Management, the system cannot create one single
document with two business partner items with opposite signs.
„
Only actual disbursements are transferred to the General Ledger. The G/L account could be a
Clearing account or a P&L account.
„
The CO objects and if applicable, the FM objects and Business Area, are determined from the
SLCM Grant Master.
© SAP AG
IHE203
7-27
7. Sponsoring Process: Posting Incoming
Grant (Sponsor) Payments
Bank Acct.
1000
SP Rec. Acct.
1000
SP
1000,
Student#
PERSL
real
1000
Σ
1000
© SAP AG 2010
„
Some sponsor agencies, especially loan agencies, supply electronic payment files for specific
students. These files can be posted to the sponsor’s account and cleared using special clearing rules,
for example, “Match debits and credits by Grant Recipient and Term.”
© SAP AG
IHE203
7-28
7. Sponsoring Process: Unit Summary
You should now be able to:
„
Discuss the different processes for internally and externally managed
financial aid.
„
Store sponsor master data, grant master data and conditions, and payment
conditions.
„
Configure the system for processing different forms of financial aid.
„
Calculate internally managed aid.
© SAP AG 2010
© SAP AG
IHE203
7-29
© SAP AG
IHE203
7-30
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
8-1
8. Document Posting & Processing: Overview
Content:
Part 1:
Document Lifecycle
Document Structure and configuration of Document Types
Integration of FI-CA sub-ledger with the FI, CO and FM
Account Balance Display and Snapshot
Part 2:
Transaction and Account Determination
Business Transactions defined by Main and Sub Transaction
Determination of G/L Accounts and CO Objects
Part 3:
Public Sector Request
© SAP AG 2010
© SAP AG
IHE203
8-2
8. Document Posting & Processing: Unit
Objectives
At the conclusion of this unit, you will be able to:
Explain the concepts of documents and processes in Contract Accounting
Understand the structure and configure document types
Transfer postings in the FI-CA sub-ledger to the General Ledger
Find and analyze the postings that you have transferred
Use the Account Balance Display
Explain the functions of the Main transactions and Sub transactions
Configure the automatic general ledger account determination in FI-CA
Understand the link between General Ledger, Controlling and Funds
Management
Post and analyze documents and line items
Post Public Sector Requests
Explain the function of standing and general requests
© SAP AG 2010
© SAP AG
IHE203
8-3
8. Document Posting & Processing:
Business Scenario
The University invoices students for tuition and fees for other services such
as housing, dining, parking permits, day care, etc. The institution wants to
ensure that the revenue and the payments are posted to the correct general
ledger account.
© SAP AG 2010
That all items posted in FI-CA respond to sub-ledger accounting.
Items are regularly compressed and transferred to the general ledger by reports.
© SAP AG
IHE203
8-4
8. Document Posting & Processing - Part 1:
Lifecycle of an Open Item (1)
© SAP AG 2010
The lifecycle of a receivable item in Contracts Account Receivable and Payable reveals which
processes from Contracts Account Receivable and Payable are handled in FI-CA:
• The usual form of posting an open item is from an invoice. Open items can be posted
automatically in fee calculation, interest calculation, dunning or returns processing. Alternatively,
open items can be posted manually, e.g. request.
• 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.
• Payments are initiated either by the business partner (cash payer) or via payment runs (direct
debit). In the context of student accounting, financial aid (grants) are considered payments.
Payments usually clear open items.
© SAP AG
IHE203
8-5
8. Document Posting & Processing - Part 1:
Lifecycle of an Open Item (2)
© SAP AG 2010
The lifecycle of a receivable item in Contracts Account Receivable and Payable continues on if the
payment is returned, e.g. NSF, or the student/sponsor does not pay the outstanding charge:
• 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 and/or company charges.
• Open documents can be deferred manually. A deferral can take place automatically in returns
processing. The original due date is retained in the case of a deferral. If the deferral date is
reached and the item is still open, the original due date is used again for further business
processes.
• 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.
• 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.
• Overdue items can be dunned. Dunning charges or interest on arrears can be posted.
© SAP AG
IHE203
8-6
8. Document Posting & Processing - Part 1:
Lifecycle of an Open Item (3)
© SAP AG 2010
The lifecycle of a receivable item in Contracts Account Receivable and Payable is eventually
brought to an end accepting the fact that the student will never pay the amounts owed:
• Overdue items can be entered as doubtful, adjusted individually or written off.
• Items can be submitted to external collection agencies. Payments such as interest and external
collection agency charges can be posted automatically or manually.
© SAP AG
IHE203
8-7
8. Document Posting & Processing – Part 1:
Structure-Document Type & Number Ranges
© SAP AG 2010
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.
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,
automatic clearing, dunning proposal, interest run, etc).
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, SLCM fee calculation), 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.
Suggestions:
If your institution produces outgoing checks then find out the requirements of your house bank since
the check number = document number for automatic check number assignment.
© SAP AG
IHE203
8-8
8. Document Posting & Processing – Part 1:
Structure: Posting Date and Document Date
The document entry date/time is the date/time when the entry was made in system.
The document date is the date on which the original document was created.
The posting date is the date on which the document was posted in contract accounts
receivable and payable (FI-CA).
Note: For documents originating in SLCM, the dates above are set to system date
and system time.
The system uses the posting date to:
Determine the fiscal year and posting period when transferring summary records to the SAP
ERP general ledger. This information is required for period-based updates of the G/L account,
Controlling, and, if appropriate, Funds Management, Special Ledger, and Grants
Management.
Select open items at a key date or within a particular period.
© SAP AG 2010
© SAP AG
IHE203
8-9
8. Document Posting & Processing - Part 1:
Structure of Contract Accounting Documents
A document has three parts:
Header record
BP items
G/L items
A document includes various control objects:
Document Type and Number Range
Reconciliation Key
Document Source (Origin Key)
Posting and Document Dates
Main and Sub-transaction
Determination of Reconciliation Account (Receivables/Payables)
Determination of Revenue/Expense Account
Assignment of Controlling Objects (optional)
Derivation of Funds Management Objects (optional)
© SAP AG 2010
An FI-CA document consists of:
• Header data, including document type, currency, and reconciliation key (DFKKKO)
• Business partner items (DFKKOP)
• G/L items (DFKKOPK)
If a document is created manually or automatically, you only have to create the Business Partner
item; the general ledger item is created automatically.
You will find most of the control parameters in customizing under the IMG path: >Financial
Accounting>Contract Accounts Receivable and Payable>Basic Functions>Postings and
Documents>Basic Settings
• Maintain Document Number Ranges
• Posting and Documents>Document
• Maintain Document Assignments
• Define Account Assignments for Automatic Postings
The structure of a document can change according to the business process, for example, Installment
plan (repetition groups) or payment or partial payment. Splitting the item of the source receivable
document into cleared and open positions does not change the original document number. For the
cleared position, an additional field is introduced to the table (sub-item number).
© SAP AG
IHE203
8-10
8. Document Posting & Processing - Part 1:
Structure of Contract Accounting Documents
Doc.Header
BP Item(s)
Company code
Business partner
Contract account
Reconciliation account
Amount
Due date
Main and sub-transaction
Contract object
FM objects
PSCD specific like Period
Financial Aid information
...
Document number
Document type
Document source
Reconciliation key
Currency
Document date
Posting date
…
Classification key
G/L Item(s)
Company code
G/L account
Controlling Objects
FM objects
Amount
© SAP AG 2010
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 about the person making entries and about 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.
A number of FI-CA Events (11xx) allow an institution to enhance the contents or processing of
documents.
• For example, when posting manually, Event 1119 can be used to create error messages prior to
posting the document. This allows the user to correct the document prior to posting.
The classification key provides a similar function to the reference number, but allows keys with a
length of up to 35 characters.
The classification key is an enhancement supported in the system. This means that the attribute is
not initially active in the delivered system; you have to activate it explicitly in your installation if
you want to use this.
© SAP AG
IHE203
8-11
8. Document Posting & Processing - Part 1:
Structure of a Payment Document
© SAP AG 2010
The clearing document that can be posted, for example, during incoming payment, only consists of a
document header and the offsetting item(s).
The following information is stored in the offsetting items: the payment amount, the corresponding
general ledger account, and information on the cleared document.
The document number of the clearing document, the clearing date, and the clearing amount are
stored in the business partner items of the cleared document.
This means that both documents are linked as long as the clearing exists. The payment document
does not maintain a business partner item since all information on the business partner item can be
viewed in the linked, cleared receivables document.
If clearing is reversed, the connection between the clearing document and the receivable is deleted,
and the payment document is given a new business partner item with all posting information.
The clearing information is stored in the clearing history, even if clearing is reversed.
© SAP AG
IHE203
8-12
8. Document Posting & Processing – Part 1:
Clearing Open Items
FI - G/L Account
Tuition
Tuition Fee
Fee Rev.
Rev.
100,-- (1)
FI - G/L Account
Contract Account
Bank
Bank
(2) 100,--
C.
C. Lear
Lear
100,-- (2)
(1)100,--
Doc. Header
DFKKKO
Doc. Header
Invoice 123
BP Item
DFKKOP
DFKKKO
100,-
100,-
Payment 456
© SAP AG 2010
Business scenario:
• Student is charged $100 for tuition fees
• Student pays $100
Result in FI-CA:
• Two physical document header records but only one physical BP item record
The redundant fields can be reconstructed another way. Therefore, they are omitted from the data for
the payment. The result is a physical record that only contains a few more attributes than the original
BP item (DFKKOP). This physical stored record with its data represents both an item in the invoice
document and an item in the payment document.
© SAP AG
IHE203
8-13
8. Document Posting & Processing - Part 1:
Clearing Open Items (Partial Clearing)
FI - G/L Account
Contract Account
Tuition
Tuition Fee
Fee Rev.
Rev.
100,-- (1)
Open item before clearing
After first clearing 60,-
After second clearing 10,-
© SAP AG 2010
C.
C. Lear
Lear
(1)100,--
60,-- (2)
10,-- (3)
FI - G/L Account
Bank
Bank
(2) 60,-(3) 10,--
BP item
Sub-item No. 000
Amount
100,-
BP item
Sub-item No. 000
Clearing Doc. 4711
Amount
40,Sub-item No. 001
Amount
60,- - 60,-
BP item
Sub-item No. 000 Clearing Doc. 4711
Amount
30,- Sub-item No. 001 Clearing Doc. 0815
Amount
60,- - 60,Sub-item No. 002
Still open
Amount
10,- - 10,-
Business Scenario:
• Student is charged $100 for tuition fees
• Student makes a partial payment of $60
• Student makes another partial payment of $10
Result in FI-CA:
• The original BP item is split into sub-items to reflect the partial payments.
• Sub-item 000 always shows the remaining open amount, for example, $30
The posted documents do not retain their status. Under certain circumstances, document changes
and clearing of open items sometimes require that the document is saved in a different physical
form.
The split is required if a partial amount of the open item is cleared. An entry in the Business Partner
table 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. To achieve this, an additional key field is introduced into the Business Partner table: the subitem number (OPUPZ).
Repeated partial clearing is allowed.
If a student makes an overpayment, i.e. pays more than the open amount, then the system creates a
new credit item which triggers further processing, e.g. repayment or used for items with a future due
date.
© SAP AG
IHE203
8-14
8. Document Posting & Processing - Part 1:
Structure: Statistical Documents
There are different ways of posting a document:
Post as a “real” open item:
A regular open item that is transferred to the general ledger and included in all business
processes.
Post “statistical” items:
The open item is not transferred to the general ledger. It can be included in invoices and
dunning but it cannot trigger dunning activities. It can, however, be paid for and cleared. In
this case, it would be transferred to the G/L.
Obsolete
Post financial aid “statistically”
Expected aid is recorded as a line item. This is
a “sample” document.
© SAP AG 2010
Statistical postings make it easier to deal with uncertain receivables, since these postings are not
transferred to the general ledger. Statistical documents do not have general ledger item(s) and are
not forwarded to the General Ledger.
Installment documents are a typical example of a statistical posting since the underlying source
receivables have already been posted in the general ledger.
When statistical items are paid, 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.
If your institution is using Estimated Financial Aid postings, make sure you define them as statistical
(Statistical Key = Z).
© SAP AG
IHE203
8-15
8. Document Posting & Processing – Part 1:
Contract Accounting as a Sub-ledger
SAP R/3 PSCD Sub-ledger
Housing
Library
System
Sub-ledger
documents
(PSCD)
Intermediate
file
Selection
SLCM Fee
Calculation
Core R/3 Administrative Systems
FI-GL
General Ledger
FM
Funds Management
FI-SL
Special Ledger
CO-PA
Profitability Analysis
Data transfer
Operational
systems
Summary
Records
© SAP AG 2010
The PSCD component serves as a sub-ledger as well as an integrator of accounting data that
originates (for the most part) from various calculation procedures, for example, a Housing System,
Library System, or SLCM Fee Calculation. The calculating systems pass their (calculated) posting
data to PSCD via a universal interface 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 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 SLCM Fee Calculation and Grant Evaluation serve also as a “feeder systems” for PSCD.
Account derivations (G/L and CO) are made in the fee calculation run and posted to the student‘s or
sponsor‘s account in the PSCD part of she system. SLCM fee postings also use FM derivation rules
set up in FMDERIVE.
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.
© SAP AG
IHE203
8-16
8. Document Posting & Processing - Part 1:
Funds Management - Posting Flow
Business partner position
BP1 /
Object Tuition
FM-Type A (Invoice)
FM-Account
G/L position
G/L Account
FM-Type
200
PSCD
Total table
DFKKSUM
Revenue 1
80000
- 200
FIAcc.
_
FM-Account
Revenue 1
Business partner position
BP2 /
Object Tuition
FM-Type A (Invoice)
100
FMAcc.
FMType
∑
14000
Revenue
1
A
300
80000
Revenue
1
_
- 300
Revenue 1
FM-Account
G/L position
G/L Account
_
FM-Type
80000
Revenue 1
FM-Account
FI
- 100
FM
80000
300
14000
Revenue1
Invoice: 300
300
© SAP AG 2010
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 IMG path: >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).
© SAP AG
IHE203
8-17
8. Document Posting & Processing - Part 1:
Funds Management - Integration Example
Payment Lot
ISIS-PS
CA
Total table
DFKKSUM
Business partner position
GP 1 / Object
Tuition
FM-Typ
(Clearing)
C
FM-Account
G/L position
G/L Account
FM-Typ
_
- 200
Revenue 1
Bank
FM-Account
200
FIAcc.
FMAcc.
FMType
∑
14000
Revenue
1
C
- 300
13100
Bank
_
200
Bank
FM
FI
13100
200
14000
Revenue1
Revenue
1
Red.
Red.Invoice
Invoice:
Payment:
Payment
200
-200- 200
200 200
© SAP AG 2010
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.
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.
© SAP AG
IHE203
8-18
8. Document Posting & Processing - Part 1:
FM Update Logic: Interpretation of Documents
© SAP AG 2010
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.
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.
The transaction class is automatically determined from the business transaction and the G/L
accounts used. The transaction class is used to determine in a reset of clearing or a clearing with
payment the FM type of the G/L position. The transaction class is stored in the document header.
© SAP AG
IHE203
8-19
8. Document Posting & Processing - Part 1:
Transfer to G/L: Reconciliation Key
Reconciliation Key
Key,
under which summary records are listed for transferring the FI-CA documents to
the general ledger
Automatic
determination in the case of mass postings (such as payment runs)
Manual
entry in the case of single postings (when posting a document, for example)
Default
values for individual postings
Summary Records
“Transfer
The
unit” for postings from subledge to general ledger accounting
documents from subledger accounting are consolidated into summary records
Summarization
criteria include:
Posting date
Account assignment data “G/L account, cost center …)
© SAP AG 2010
Summary records are saved in the DFKKSUM* tables.
Other summarization criteria include:
• Company Code
• Business Area
• General Ledger Account
• Currency Key
• Additional account assignments of controlling such as Cost Center, Order or Profit Center.
• Additional account assignments of Funds Management, such as Fund 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 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.
© SAP AG
IHE203
8-20
8. Document Posting & Processing - Part 1:
Transfer to G/L: Structure of Reconciliation Key
© SAP AG 2010
Various business processes create a reconciliation key in the system. The reconciliation key is
identified by the current day in the business year (Julian date) - which is derived from the creation
date - and the source or name.
Reconciliation Keys for documents originating in SLCM contain the Origin Key, e.g. P1-081201-01
represents the 1st run of the Fee Calculation on 2008/12/01.
Document source:
• P1 = IS-PS: Student Fees
• P2 = IS-PS: Manual Adjustments of Student Fees
• P3 = IS-PS: Externally Managed Financial Aid
• P4 = IS-PS: Internally Managed Financial Aid
• P5 = IS-PS: ISR Related Fees
Reconciliation keys that have been created automatically are closed automatically.
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 the transfer to the General Ledger.
Display transferred totals records in FI with Transaction FB03 (Document Display):
• Click on the pushbutton: [Document List]
• Enter the Reference Transaction: FKKSU
• Enter the Reference Key Reconciliation Key +*
© SAP AG
IHE203
8-21
8. Document Posting & Processing - Part 1:
Summary Table Entries: Reconciliation Key
G/L
Header
Reference Key: 888
Line Items
Subledger Table
....
Library
Reconciliation Key: 888
Real
Estate
BP 237
BP 237
Rev. 1
Rev. 2
300
50
-300
-50
475
-400
-75
Summary
Table
Header
Line Items
BP 237
Rev. 1
Rev. 2
Summary Items
Batch for Key: 888
Header
Reconciliation Key: 888
BP 237
Rev.1
Rev.2
475
-400
-75
Line Items
BP 237
Rev. 1
Rev.2
125
-100
-25
Compression
© SAP AG 2010
The reconciliation key can be structured by user (group) specifically for online postings. Userdependent and user-independent reconciliation keys can also be proposed for origin keys stored in
Customizing. However, for this to happen, the SAP function modules FKK_SAMPLE_1113_USER
or FKK_SAMPLE_1113 must be used in Event 1113.
For Student Accounting processes (Fee Calculation, Grant Evaluation, and Application Fee
Postings) the reconciliation key determination is performed via Function Module
CMAC_SAMPLE_P901. This Function Module could also be replaced by a customer Function
Module.
The reconciliation key must be closed before the values are transferred to the general ledger. This
ensures that no other postings are carried out for this reconciliation key and that the recorded values
cannot be changed.
During mass closing (Transaction FPG4 (Close Record Keys Automatically), 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.
If necessary, you can also delete reconciliation keys that have been created but are not used. To do
this, select the flag: Delete Unused Open Keys or Delete Unused Closed Keys..
Posting totals can be displayed with the Report RFKKABS30 (Itemization for Posting Totals): The
report selects all FI-CA documents posted under a reconciliation key
To transfer summary records to the general ledger, the relevant posting period must be open in
FI/CO/FM. Use Transaction FPG1 (Transfer Posting Totals to GL) or Report RFKKGL00.
The relevant posting period must be open in Financial Accounting for summary records to be
transferred, or an alternative posting date must be maintained in Table TFK001Z via Transaction
FPG0 (Maintain Alternative Posting Data). If the posting date in FI is closed, the system will post as
of the alternative date, if one has been defined. Easy Access Menu: Accounting>Financial
Accounting>Contracts Account Receivable and Payable>Periodic Processing>Forward Postings.
© SAP AG
IHE203
8-22
8. Document Posting & Processing - Part 1:
Transfer to G/L: PSCD > Summary > FI Document
© SAP AG 2010
Documents in a reconciliation key are cumulated according to posting date, general ledger account
and other accounting objects.
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.
• 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:
• For checking summary records use Report: RFKKABS1 (Check Total Records) / Report
RFKKABS8 (Recreate Totals Records) / Report: RFKKGL20 (Check General Ledger
Documents)
For transferring summary records to the General Ledger in correction mode use: Report RFKKGL00
(Transfer of FI-CA Total Records to General Ledger).
© SAP AG
IHE203
8-23
8. Document Posting & Processing - Part 1:
Reconciliation: General Ledger Documents
© SAP AG 2010
Report RFKKGL00 (Transfer of FI-CA Totals Records to General Ledger) transfers the summary
records accumulated in the reconciliation keys to the General Ledger. Report RFKKGL20 (Check
General Ledger Documents) is used to reconcile between the General Ledger and Contract Accounts
Receivable And Payable. This report reads the documents from the General Ledger that were posted
by the transfer of PSCD summary records. It then compares these documents with the PSCD
summary records. Differences are displayed in color and marked with a red traffic light. If posting
terminated (for example) causing differences that cannot be posted, you can select the corresponding
menu option in the output list to correct these differences. 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 PSCD postings totals match the
totals of the associated PSCD documents and that the balance of the PSCD documents is zero. The
report displays any discrepancies between the posting totals and the PSCD documents. The
differences can be corrected in dialog or in background processing. If PSCD 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.
The Report RFKKOP04 (Item List) creates a list of open items for Business Partners on a particular
date in PSCD. You can use the report during the final work (month, quarter, year) or for
reconciliation purposes.
© SAP AG
IHE203
8-24
8. Document Posting & Processing - Part 1:
PSCD Reconciliation with the General Ledger
© SAP AG 2010
Report RFKKGL30 (Itemization of G/L documents from FI/CA): The report displays the documents
from Contract Accounts Receivable And Payable (PSCD) 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 ((Itemization of G/L documents from FI/CA): 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 Sub-Ledger at any given point in time.
You can use the Report RFKKABS6 (Display for General Ledger Transfer) to reconcile the General
Ledger accounts: The report outputs postings that were transferred to the General Ledger. The
postings are displayed as an overview of balances or as line items with the corresponding posting
date and, if available, an alternative posting date.
© SAP AG
IHE203
8-25
8. Document Posting & Processing - Part 1:
Transfer to G/L: PSCD Reconciliation of Open Items
© SAP AG 2010
Report RFKKOP10 (Reconciliation between Open Items and G/L) reconciles Contract Accounts
Receivable and Payable (PSCD) with the General Ledger (FI). It reconciles the current balance for
all reconciliation accounts or the reconciliation accounts specified. The following balances are
determined per company code, business area and reconciliation account:
• Balance of current open items in contract accounts receivable and payable
• 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 (Reconciliation between Open Items and G/L) 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, use Report RFKKOP04 (Item List)
with the relevant reconciliation account as current OI list.
© SAP AG
IHE203
8-26
8. Document Posting & Processing - Part 1:
Account Balance Display
Account display: Initial screen
Business partner
Contract account
Contract
Company code
Criteria are combined
using ‘and’ logic.
Only items for
Installment plan
Reference
List categories are defined in customizing
and can be viewed (and changed) by
Selecting the Detail button.
List category
List category
Detail
Additional selections
User-specific selection
Selection Criteria
A user may enhance selection
values and store these settings in
his user master for re-use.
List display
Line layout (variant)
Sorting variant
Initial screen
List display variants are defined in
customizing. Line variants determine which
fields are to be displayed, and sorting variants
determine how resulting items are sorted.
© SAP AG 2010
Through its Account Balance Display functionality, PSCD enables you to obtain quick and
comprehensive account information regarding open, cleared, or statistical items.
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 line items are displayed for an 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 six fields defined in the line layout
variant for sorting (in ascending order). User parameter 814 selects the last setting of normal versus
reduced initial screen (that is, the selection screen where parameters are entered prior to actually
viewing an account balance).
User parameter 815 saves the last recorded initial list display (sub-list) screen, but will be
overwritten if parameter 810 is active.
© SAP AG
IHE203
8-27
8. Document Posting & Processing - Part 1:
Account Balance Display: Navigation Area
422 / P001
John Q Public
Anywhere
Navigation
Navigation area
area
Receivables
Down payments
Posting date
Due date
Date
Transaction
12/10/05
Manual posting
400
11/11/05
Manual posting
200
….
….
Totals Payment list
Total amount
Debit
Chronology
Open amount
Credit
….
© SAP AG 2010
Using navigation, the user can display the partner / account combination for the selected partner /
account. This enables the user to easily determine which other accounts a partner has or which other
partners belong to this account.
Sub-lists are available while in the account balance display. For example, when the chronology sublist is selected, the system returns a chronological list of transactions for the selected item/ account,
sorted according to posting date or due date. The second row of sub-lists depicted above only
appears when chronology is selected.
The system separates the display data into two sections: postings that took place prior to the system
date and postings that have taken place after the system date.
From the Account Balance display, you can drill down to the actual document. Documents created
by Student Lifecycle Management, for example student fees and financial aid postings, contain
SLCM-specific information (see the Public Services and Additional Information tabs).
Suggestion: Include the Grant (PSGRANT) and Contract Objects (PSOBTYPE) on the student line
item. Additionally, the sponsor line should includes the recipient, that is, the student (PSRECPT).
This field contains the student‘s Business Partner number.
Both documents contain information about the Academic Year and Session (PERSL).
© SAP AG
IHE203
8-28
8. Document Posting & Processing - Part 1:
Account Balance Display: Line Layout Variants
Student File --> Account
IMG
default
Line Layout Variants
Subsequent Variants
A10
1
Standard account
A11
A11
1
Account/contract
A12
A12
1
Account/contract/document
A13
A13
2
Account/contract/line-item
Line Layout Variant Type
© SAP AG 2010
Each line layout variant must either be defined as a totals (1) variant or a line-item (2) variant.
Subsequent variants are optional parts of line layout variant configuration and allow the user to
dynamically select the level of detail displayed while performing an account balance display.
Hint: If a user wants the last line layout variant that he was using to default for subsequent account
balance displays, Parameter 810 must be set to X (that is, if user A was viewing an account balance
display using variant Q1 and he wanted variant Q1 to default upon his next execution of the account
balance display, parameter 810 must be on). To be able to switch freely between variants in the
account balance display, parameter 812 in the user profile must be set to X.
Note: You can configure the default line layout variant in the IMG/contract accounting. This default
is the line layout that is used for the student account display called up from the student file.
Recommendation: Define a separate layout for display of sponsor accounts. IMG path: Financial
Accounting>Contract Accounts Receivable and Payable>Basic Functions>Account Balance
Display.
© SAP AG
IHE203
8-29
8. Document Posting & Processing - Part 1:
Account Balance Display: Further Functions
Additional Features in the Account Display:
Sort, find, and total
Change line layout; add field to line layout; SAP List Viewer
View clearing history
View interest schedule
View installment plan and/or source receivables
Dunning and returns history
View master data (business partner, contract account and contract object)
Send account information
Write-off; submit items to collection agency
Period restriction for item selection
Call up Context Menu
© SAP AG 2010
There are numerous standard functions available to meet your institution’s requirements.
Furthermore, there are FI-CA Events (12xx) that can be used to adapt the Account Balance Display
to your needs:
• 1200 – Acct Balance: Set Header Data (for example, add HOLD information form SLCM)
• 1205 – Account Balance: Supplement Data (for example, add SSN and student‘s name to sponsor
account displays)
Note:
Restriction of Item Selection: If you select 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.
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.
Documents without Business Partner Items: 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.
© SAP AG
IHE203
8-30
8. Document Posting & Processing - Part 1:
Account Balance Display: Creating Snapshots
© SAP AG 2010
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. To do
this, you must enter the Business Partner with many items in the customizing under the IMG path:
Financial Accounting>Contract Accounts Receivable and Payable> Basic Functions> Account
Balance Display>Define Business Partner for Creation of Snapshots. This setting is one of the
current system settings and, therefore, you can access it in the Easy Access Menu under
Accounting>Contracts Account Receivable and Payable>Settings>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.
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:
• 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 upto-date and with the date of the snapshot.
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.
© SAP AG
IHE203
8-31
8. Document Posting & Processing - Part 1:
Business Partner Overview
© SAP AG 2010
The Business Partner overview is most useful when a Business Partner has multiple contract
accounts. You can enhance the Business Partner overview using customizing and Events P120 to
P130.
The Business Partner overview is configurable. You can assign a configuration to individual users in
user maintenance or you can define it as the standard.
The Contract Accounts and Contract Objects of the Business Partners are displayed hierarchically in
a tree structure. The Contract Objects Are subordinate to the contract accounts. The user can
navigate in this tree by double-clicking or by using the environment menus. The system displays
some data for the master data object that is currently selected in the top screen area. You can use a
customer-specific program and sub screens to define the master data information.
The system displays the additional data for a Business Partner on a tab page. You can customize the
sequence of the tab pages and how they are displayed.
Data retrieval is carried out in Events. You can replace the standard Function Modules for data
retrieval by customer-specific Function Modules.
You can navigate from the user interface to a number of other transactions. Additional functions that
you can set in customizing are provided as pushbuttons or menu entries for calling editing functions.
You can define the Business Partner overview settings in Customizing under:
• Configure Business Partner Overview
• Maintain Additional Functions for Business Partner Overview
© SAP AG
IHE203
8-32
8. Document Posting & Processing - Part 1:
Unit Summary
You should now be able to:
Explain the concepts of documents and processes in Contract Accounting.
Understand the structure and configure document types & number ranges.
Transfer postings in the FI-CA sub-ledger to the General Ledger.
Find and analyze the postings that you have transferred.
Use various reconciliation reports.
Navigate to the account balance display and configure it for your need.
© SAP AG 2010
© SAP AG
IHE203
8-33
8. Document Posting & Processing - Part 2:
Structure of Business Transactions
© SAP AG 2010
A Business 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 combination of the Main and Sub-transaction controls the determination of the GL Account
(mostly P&L) and corresponding additional account objects, e.g. business area, and CO account
assignment data.
External transactions are defined by the customer. Internal transactions are delivered by SAP and
control the way in which application-specific processing programs run. Do not delete internal
transactions as they are hard-coded in programs.
Internal transactions are allocated to external transactions in the IMG. Note: Not every external
transaction needs to be allocated to an internal transaction.
FI-CA and industry-specific versions use internal main and sub-transactions that are assigned by
various business processes and that control these processes.
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.
© SAP AG
IHE203
8-34
8. Document Posting & Processing - Part 2:
Assigning Main and Sub Transactions
IMG
Assignment of External Transactions to Internal Transactions
App. area Internal main Internal sub
Name
Main external Sub external
Name
P
0010
0100
Interest charge
5010
0100
Interest charge
P
0010
0120
Dunning charge
5010
0120
Dunning charge
P
0040
0100
Return charge 1
5040
0100
Return charge 1
….
….
….
…….
….
….
…….
….
….
….
…….
….
….
…….
Customers can rename internal
main and sub transactions. The
names defined here are used in
the parameterization table.
These are internal main and
sub transactions; they are hard
coded in the system
© SAP AG 2010
Internal transactions are transactions that take place within PSCD. Some examples of these
transactions are Charges, Interest, Payments on Account, Clarification Postings, and so on. These
Main and Sub-transactions 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 of
whether the customer chooses to rename the transactions (that is, if the customer wishes not to
rename the entry for main transaction 0010 sub-transaction 0100, then he must place identical
entries in the space for external assignment).
These internal transactions are hard-coded. Do NOT delete them.
Main and Sub-transactions are used to identify items based on their type (interest, charge, and so
on), as well as the business process from which they originated (payments, account statements, and
so on). The combination of main and sub-transactions are also referred to as a Business
Transaction, which controls account determination and the flow of application-specific processing
programs. Several Sub-transactions could be linked to one Main Transaction. For example, the Main
Transaction “Charges” may be associated with Sub-transactions such as Dunning Charge, Return
Charge 1, Return Charge 2, Correspondence Charge, Installment Plan Charge, and so on.
A user can define new 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.
© SAP AG
IHE203
8-35
8. Document Posting & Processing - Part 2:
Maintain Main and Sub-transactions
PSCD Main Transactions Overview
Application area
Application Area
Main
Description
Main transaction
P
5010
Charges
P
Interest
….
PSCD Sub-transactions
P
5040
....
P
….
Application area
Main transaction
P
5010
Sub-transaction
0100
P
5010
IMG
Sub transaction Description
….
0100
Return charge
0110
Installment plan fee
0120
….
Dunning charge
….
Main and sub-parameters: 5010 / 0100
Description
+/-sign
Due date
Withholding tax amount
Additional receivable rule
Payment [include in p. list]
Ignore [ ignore for invoices]
© SAP AG 2010
Your institution may define new entries in this table for business transactions not defined as internal
to PSCD. These additional Main and Sub-entries can be used in General Ledger account
determination (Posting Areas P000 and P001).
Parameters are set for the Main and Sub-transactions, for example:
• +/- sign: You choose between “not specified,” “negative amount,” or “positive amount”
• Due date to be used
• Withholding tax rule
• Any additional receivable rule
Additional Receivable: This identifies a process as an additional receivable. An additional
receivable refers back to another receivable, for example, dunning charges and interest. In many
cases, additional receivables should not be dunned/have interest calculated on them on their own. An
item (main receivable) that is not indicated as being an additional receivable can have interest
calculated on it and can trigger a dunning letter if no lock has been set for it. You can set the exact
characteristics of the additional receivable depending on the operational company code. In the
simplest case, it is enough to define one rule for additional receivables.
All postings in PSCD contain information on the business transaction in the Main and Subtransactions. 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 further business
transactions (dunning procedure and so on).
© SAP AG
IHE203
8-36
8. Document Posting & Processing - Part 2:
Posting Areas
Menu: Go to/Select Keys
Select key fields
Mandatory
Key Field 1
X
Key Field 2
Key Field 3
Used
X
X
X
IMG
Switches into
list display!
Menu: Environment/Access Sequence
Access sequence
Sequence Key 1 Key 2 Key3
1
2
3
Perform:
Simulation
© SAP AG 2010
In many contexts, the system has to derive accounts or other data. The derivation is maintained in a
Posting Area. For all derivations, you use the same tool. You can maintain all posting areas with
Transaction FQC0 (C FKK Acct Determination General) or the relevant menu path in the IMG.
Transaction FQCR (Account Determination: List) selects and outputs data from account
determination.
You can always enter several derivation rules. If you do not see the list view at first, choose Goto
Select Keys.
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, 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 choosing Simulation. There is also an error analysis if the derivation was
not possible.
© SAP AG
IHE203
8-37
8. Document Posting & Processing - Part 2:
Determining G/L Accounts (Generic)
Header
BP Position 1
G/L Position 1
BP Position 2
G/L Position 2
...
...
G/L Position n
BP Position n
Acc. Determination ID (=CA Cat)
Acc. Determination ID (=CA Cat.)
Main transaction
Main transaction
Sub-transaction
Reconciliation
account
Revenue
Account
Sub-transaction
Customizing
account
determination
Customizing
account
determination
© SAP AG 2010
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 sub transactions 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)
The event for determining the reconciliation account is 1101. The Event for determining the revenue
account is 1100.
© SAP AG
IHE203
8-38
8. Document Posting & Processing - Part 2:
G/L Account Determination (Generic)
Select key fields
Main transaction
Sub-transaction
Acc. Determination ID
Mandatory
IMG
Used
X
X
X
Maintain reconciliation/revenue account overview
Acc. Det.ID
Main transaction
Sub-transaction
G/L Account
*
*
*
140099
*
6040
0120
273000
35
4010
0100
140000
...
...
...
...
© SAP AG 2010
The account determination ID is automatically derived from the contract account category or the
contract object when posting an item. Use Event 1017 to set default values when creating a Contract
Account.
Each individual posting in PSCD is allocated to exactly one receivables / payables account (P000) in
the General Ledger. A Negative Transfer Amount Is A Credit, And A Positive amount a debit.
Note:
General Ledger accounts used in Business Partner items (receivables, payables, down payments, etc.)
must be designated as Reconciliation Account Type V. This prevents unintentional direct postings to
these accounts and avoids potential complication of the reconciliation process.
P&L Accounts: 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 automatically determine the general ledger account in which to post (P001).
P&L Accounts may also carry a CO assignment.
If applicable, you also need the Business Area in the BP line item and the G/L line item.
© SAP AG
IHE203
8-39
8. Document Posting & Processing - Part 2:
Account Assignment Derivation
FM derivation can take place
When building a document from a BP line item
Automatic documents such as dunning charges, interest
Manually created documents such as Request
When completing a G/L line item with FM assignments
The derivation tool is used in the first case only
FMDERIVE
In the second case the old logic is used:
Commitment item
from
G/L account
Funds center
from
Commitment item
Funds
from
Funds center
© SAP AG 2010
Activation of Funds Management Integration: Step 1
• Activation of FM fields for document tables as defined in customizing (DFKKOP, DFKKOPK).
• Allocation of the relevant commitment items T30,60,90) to the relevant G/L accounts.
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 Subtransactions (for example, 0060/0600 Payments on Account).
- For main and sub transactions that represent payment transactions, the “Payment” indicator
must be set for the Main and Sub transaction.
- 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.
See SAP Note 686383 for more information.
Note: The FM Fields is automatically activated for Contract Accounts receivable and payable. You can
use account assignment derivation to automatically determine Funds Management account assignments
values from other account assignments as long as a logical dependency exists between them and
payable by activating the ECC extension set for FICA_FM.
© SAP AG
IHE203
8-40
8. Document Posting & Processing - Part 2:
Derivation Types
For active Fund Management:
Each PSCD-relevant posting must contain the FM objects.
SAP supplies a derivation tool to automate the account assignments
when posting manually or with mass processes.
Derivation Rule
Function Call
Table Lookup
Derivation
Step Types
Enhancement
Move
Clear
© SAP AG 2010
A complete FM account assignment must be entered (Commitment Item, Funds Center Fund,
Functional Area, Funded Program, Grant) for each PSCD-relevant posting. Account assignment
derivations reduce the number of account assignments that have to be entered manually in PSCD or
other components such as FI or CO when you make manual postings.
If there is a logical dependence between FM account assignments and account assignments from
other components, such as FI or CO, the values in the FM account assignments can be derived
automatically from the other account assignments. The derived values appear as default values
which can be overwritten if necessary. This automatic derivation is referred to as a Derivation
Strategy.
The purpose of the account assignment derivation is to determine automatically Funds Management
account assignments values from other account assignments as long as a logical dependency exists
between them. Different derivation types can be used to map different logical dependencies between
source and target fields:
• Derivation Rule: This rule defines which account assignment values of the source field or a
combination of source fields leads to account assignment values. The fixed account assignment
values of the source and target fields are maintained in one of the tables assigned in the rules.
• Table Lookup: This is the key field of a table, which is used as the source field to fill target fields
with the content of the key field.
• Move: This rule moves the content of a source field or a constant to a target field.
• Clear: This rule clears certain field content of an account assignment.
• Enhancement: User-Exit SAPLFMDT001 can be included in the derivation strategy.
• Function Call: You can include the Function Calls defined by SAP in your derivation strategy.
Users cannot define their own Function Calls.
© SAP AG
IHE203
8-41
8. Document Posting & Processing - Part 2:
Table Maintenance
Source Field From-To Values IN/OUT
Main (HVORG) Sub (TVORG) Valid from
CI
FC
FUND
FUNCT.AREA
9000
1000
01.01.2005
= 400000
100100000 1000
0100
9000
1010
01.01.2005
= 400100
200100010 1000
0200
© SAP AG 2010
In most institutions, the FM specialists supporting SAP FI/CO/FM maintain the Derivation Tool
(transaction: FMDERIVE). PSCD business processes are built around the Main and Sub
Transaction. Therefore, it is not uncommon that the PSCD experts use the Table derivation strategy.
You can go straight to the table maintenance from customizing by using the button: “Maintain Rule
Entries”.. You can also maintain the rules entries under Master Data → Assignment → Edit
Account Assignment Derivation.
Depending on the derivation rule entries in customizing, date-dependent entries can be maintained.
You can enter value areas for source fields.
© SAP AG
IHE203
8-42
8. Document Posting & Processing - Part 2:
Unit Summary
You should now be able to:
Define parameters to control contract accounts and general ledger account
determination
Assign CO objects to Revenue in Student Accounting
Post and analyze documents and line items
© SAP AG 2010
© SAP AG
IHE203
8-43
8. Document Posting & Processing - Part 3:
Request - Overview
Request
Request *
release
Standing
Request
release
General
Request
release
Status: released
Status: released
Debit/Credit
Status: released
Debit/Credit
* Payment Request, Acceptance Request
FI-CADoc.
Σ
FI
Incoming
Payment
© SAP AG 2010
Requests can be used to post outgoing and incoming invoices, for example, charges and refunds.
If you want to introduce the dual-control principle for requests in your institution, you can trigger a
workflow when an approval is required to create, change, or reverse a request.
Once a request is released, an FI-CA document is created. The result is a Request document and a
regular FI-CA document. You define in the IMG whether you want an individual FI-CA document
to be created for each request item.
You can choose whether the FI-CA document should be created directly or in a separate step. To do
this, you can choose the Generate Documents function from Requests.
Requests are classified by the following request classes, which cannot be changed:
• Request
• Standing request
• General request
The request category differentiates between acceptance request and payment request. The request
category cannot be changed.
You can get a list of requests from the request processing transaction, where you can see documents
already posted for a request. You can also go to the corresponding request from a contract
accounting document.
You can define request types in customizing. For each request type, you can choose the plus/minus
sign and the document type that you wish to assign to the document. .
© SAP AG
IHE203
8-44
8. Document Posting & Processing - Part 3:
Acceptance and Payment Request
One-screen transaction
Acceptance req.
Payment req.
Line-based entry
Derivation of FM data from
main/sub-transaction or CO
accounts
Work list Flexible
workflow
© SAP AG 2010
The transaction for processing requests is a single-screen transaction.
In the upper area of the request, you can choose if you want to create a new request, which can be
created with a template, or if you want to display an existing request. You have to tell the system
which request category you want use.
In the middle area, you can enter the request header data, including the data you can see in the FICA document header, such as the document date and the document type.
In the lower area, the request items are entered.
In contrast to creating an FI-CA document, editing a request is line-based. In one line, you can find
the business partner data and the G/L data. The assignment between BP data and G/L data is always
unique. Mandatory fields are company code, business partner, contract account, contract object,
main and sub-transaction, and amount. With appropriate configuration, the net due date, G/L
accounts, FM data, and CO data are derived. Generally, you can create a request for several business
partners and several company codes.
If you must always enter similar requests, you can create a request template, thereby reducing the
amount of entries you have to make. When you create a new request, you can use this template by
calling the Create Using Template function. When you create a request using a template, you can
use existing requests as well as request templates.
Look at events 65xx if your institution has specific requirements.
© SAP AG
IHE203
8-45
8. Document Posting & Processing - Part 3:
Standing Request: Overview
Header Data
Document Date
02/15/2005
02/15/2005
Posting Date
02/15/2005
02/15/2005
Document Type
DR
Execution Data
Due date
period
Execution Period
001
001
First Due Date
02/15/2005
02/15/2005
Due date
frequency
Frequency
- Adding dates
- Excluding dates
Last Due Date
02/15/2006
02/15/2006
No End Date
monthly
Interval
01
01
Special
SpecialDate
Date
Request Item 02/15/2002 To 02/15/2003
BPartner
BP1
Mtrans
Contract
501001234567 4030
SubTrans Amount Item Text
100
0100
Rent
FI-CA doc.
BP1 100,
05/15/2005
06/15/2005
© SAP AG 2010
Standing requests are an efficient tool for creating FI-CA-Documents on a periodic recurring basis.
A standing request is a template, which contains all relevant data to create FI-CA documents
periodically.
You can create standing requests for acceptance requests and payment requests.
In the run data, you enter the first and the last due date, or you define that there is no end date.
Additionally, you have to insert a frequency (for example, monthly) and, based on the frequency, an
interval (02 stands for every two months).
SAP supports the following frequencies:
• Daily
• Weekly
• Monthly
• Last day of the month
• Yearly
You can exclude or add special dates by using the Special Date function.
© SAP AG
IHE203
8-46
8. Document Posting & Processing - Part 3:
Standing Request: Changes - Versions
First version
BPartner
BP1
Mtrans
Contract
501001234567 4030
Run Data – Version 1
First Due Date
Current version
SubTrans Amount Item Text
500,0100
1st Rate
BPartner
BP1
02/15/2008
02/15/2008
Mtrans
Contract
501001234567 4030
Last Due Date
SubTrans Amount
100,0100
02/15/2008
02/15/2008
Item Text
Rent
Run Data – Version 2
First Due Date
03/15/2008
03/15/2008
Last Due Date
02/15/2008
02/15/2008
05/15/2008
05/15/2008
New current version
BPartner
BP1
Mtrans
Contract
501001234567 4030
SubTrans Amount Item Text
150,0100
Adjustment
Run Data – Version 3
First Due Date
06/15/2008
06/15/2008
Last Due Date
02/15/2009
02/15/2009
© SAP AG 2010
You can change standing requests by creating a new version.
The versions can differ by run data and/or posting date and other accounting data regarding one
standing request.
The execution dates of the different versions must not overlap. If the execution dates of two
different versions overlap, one version must be changed.
© SAP AG
IHE203
8-47
8. Document Posting & Processing - Part 3:
Standing Request: Creating Documents
Periodic mass run
Standing request
FI-CA documents
FPDUDC
Req. No.
4711
BPartner
BP1
Due Date incl. 04/15/05
Amount
100,-
From Req. No.
4000
To Req. No.
5000
First Due 02/15/05
Last Due 02/15/06
Doc. No. 1100012
BPartner
BP1
Amount
100,-
Due Date 02/15/05
Update history
© SAP AG 2010
Using the Generating Documents Transaction from Standing Requests, you can create FI-CA
documents on regularly recurring dates.
You can do this by using the mass activity. You can enter a date until which documents should be
created from the standing requests. You can limit the standing requests that should be included in
the processing according to business partner, contract account, or contract. You can also select by
standing request number for processing.
To restrict the number of standing orders by the due dates or the request numbers, go to the tab page
for the date and fiscal code number.
In one run, the program creates a contract accounting document for each standing request and due
date. If several execution dates for a standing request fall in an execution time period, the system
creates several contract accounting documents with the different due dates for the standing request.
© SAP AG
IHE203
8-48
8. Document Posting & Processing - Part 3:
General Request: Business Scenario
Bank Statement
Transaction code: Direct Debit
Sold-to party:
TELEKOM
Bank key:
10020030
Bank account:
12345
Note to payee
Connect. 987654
---- ------------------------- ---- ---- -
Telekom
Telekom
(2) 80,--
80,-- (1)
Bank
© SAP AG 2010
You use general requests when you expect the same type of revenues or expenditures, but their
amounts are not yet fixed.
For example, you can enter general requests for the revenues using administrative and usage charges
or a general payment request for telephone charges.
The general request simplifies the administrative process because a payment can be made without
there being a concrete payment request in a particular case. You can also use it to represent
participation in debit memo transactions.
You can incorporate a workflow for the approval of general requests.
© SAP AG
IHE203
8-49
8. Document Posting & Processing - Part 3:
General Request
Intern/Extern
Intern/Extern (Customizing)
(Customizing)
Request Number
Request Category
Acceptance/Payment
Acceptance/Payment Request
Request
Header data
Posting Date
Reference
Status
Doc.type
Differentiation
Differentiation of
of documents
documents
Created from
Created at
Request items
Account Assignm.
BPartner ContractAcc. Contract MTrans. STrans. FM GL/Acc. CO TaxCode Valid to
IfIf business
business partner
partner is
is
unknown:
Dummy
unknown: Dummy BPartner
BPartner
Per
Per line
line unique
unique contract
contract object
object
Validation
Validation date
date for
for
general
request
general request
© SAP AG 2010
© SAP AG
IHE203
8-50
8. Document Posting & Processing - Part 3:
General Request: Payment
Account Balance
(View: detailled payment list)
Incoming Payments
Note to Payee
Amount
Payment
Lot
XYZ
1001
Electronic Bank Statement
XYZ
200
200-
Payment on Account
Account
DocNo.
1000
MTrans STrans Amount
1001
0050
0100
200-
Payment Lot
XYZ
Payment Document
Doc. Header
General Request
Doc. Header
Doc.No.
BPartnerposition
0815
Ccode
0001
Request Items
Pos. CompCode BPartner Contr.Acc. Contract
1
2
3
--0001
---
--1234
---
--1000
---
1001
DocNo.
--XYZ
---
BPartner
1234
C.Acc. Contract M/Strans
1000
Amount
XYZ 0050/0100 200-
GL/Position
CompCode
0001
GL/Acc.
113109
Amount
200
© SAP AG 2010
In the case of incoming or outgoing payments using electronic account statements or the cash desk,
the system recognizes that the payment is made due to a general request.
The payment is first posted as a payment on account without debits.
So that the system can recognize that the payment is due to a general request, it saves the
combination Main Transaction 0050/Sub-transaction 0100 as soon as a payment can be assigned to a
general request.
The system determines the Main and Sub-transaction that were actually saved in the payment
document from the IMG activity Assign External Transactions.
The system transfers the account assignment from the general request for the master data..
You can set whether you want the system to use the Contract Object or the Classification Key to
assign the general request for the incoming payments and outgoing payments.
The “Classification Key” is a new field for the general requests. This field ensures that the
corresponding general request is found with the incoming payment and outgoing payment using the
classification key. If the field is not selected, the link from payment to general request is established
through the contract object.
The Classification Key must be activated beforehand in the IMG.
© SAP AG
IHE203
8-51
8. Document Posting & Processing - Part 3:
General Request: Creating Invoices
Periodic mass run
General request
Req.No.
BPartner
4711
4711
GP1
GP1
Contract
XYZ
XYZ
OGRM3
From Req.No.
To Req. No.
4000
4000
5000
5000
GP1
GP1
(2) 200,-
200,- (1)
Update history
© SAP AG 2010
If you want to generate debit entries for payments made on general requests, choose Generate
Documents for General Requests.
The system automatically clears the contract accounting documents with the payments according to
the customizing settings.
You can list all relevant documents to check the funds consumption on general requests.
© SAP AG
IHE203
8-52
8. Document Posting & Processing - Part 3:
Work list: Approve Requests
Selection
Clerk Mode
Administrator Mode
Resubmission Cases
In Process by me
In Process by other user
Resolved
Locked resubmission by me
Approved
Rejected
Cancelled
Deleted
New
resubmission
date
FKKORDA
Worklist: approve requests
Status Status Name Request No. Amount
In process
Clarify
Lock
Unlock
2424
1000.00
User
Resub. Date
TRAINING
08/15/2005
Set Clar. Case for
Resubmission
Change
Status/User
Approve
Reject
© SAP AG 2010
You can approve requests not only using the workflow, but also using a work list.
You define which classes and categories of requests should be approved through a work list in
customizing.
Event 5510 was enhanced for customer-specific differentiation between approval by work list or by
workflow. You can also suppress the entry of an approval reason for Event 5510 when starting the
workflow.
© SAP AG
IHE203
8-53
8. Document Posting & Processing - Part 3:
Requests - Additional Functions
Print request - correspondence type 0039
Enter notes
Set payment blocks, dunning blocks, interest blocks and clearing blocks
Enter documents for each request item
Specify a tax code that contains several tax rates
Fill the “Classification Key” field in the request items
Display requests in the account balance
Approve requests using the workflow and using a worklist
Use BAPIs to edit requests
© SAP AG 2010
For requests, standing requests and general requests, you can:
• Print requests. To print a request, all the header data of the request and all request items are
available with additional information about the business partners and the contract accounts. To
print standing requests, all execution data and special dates are available.
• Enter notes for request. If you create documents from the requests, the notes are transferred to the
notes for the documents.
• For the request items, set the payment blocks, dunning blocks, interest blocks and clearing blocks
that are transferred to the documents when they are created. However, you can only set one
blocking reason and one validity time period for each request item and block.
• If you create requests with many lines and, under certain circumstances, with several business
partners and contract accounts, this can lead to extended documents that can no longer be
displayed clearly. Therefore, you can create documents from requests for each request item. You
can define the corresponding specifications in Customizing for requests for each request type.
• Enter requests with a tax code that contains several tax rates. The calculated tax amount that is
displayed in the request item is the total of the amounts of the individual tax rates.
• Fill the new fields „Classification Key“ in the request items if you have activated the standard
enhancement for the classification key. Since the classification key is a header field of the
document, you can only enter different classification keys in a request if you create documents
for each request item.
• Display requests in the account balance by defining relevant function modules for Events 1203,
1209 and 1211.
© SAP AG
IHE203
8-54
8. Document Posting & Processing - Part 3:
Requests: BAPIs
BAPI_REQUEST_ADDLINEITEMS
BAPI: add line items in request
BAPI_REQUEST_ADDPERIODS
BAPI: add periods in request
BAPI_REQUEST_ADDSPECIALDATES
BAPI: add special dates in request
BAPI_REQUEST_CHANGE
BAPI: change request
BAPI_REQUEST_CREATE
BAPI: create request
BAPI_REQUEST_DELETE
BAPI: delete request
BAPI_REQUEST_DELETEPERIODS
BAPI: delete periods in request
BAPI_REQUEST_DELLINEITEMS
BAPI: delete line items in request
BAPI_REQUEST_DELSPECIALDATES
BAPI: delete special periods in request
BAPI_REQUEST_EASYCREATE
BAPI: create request with template
BAPI_REQUEST_GETDETAIL
BAPI: read request
© SAP AG 2010
© SAP AG
IHE203
8-55
8. Document Posting & Processing – Part 3:
Customizing
IMG
Request Class
Request Category
Request
Payment Request
Request Category
Payment Request
Number Range
01
Doc. Type
CR
© SAP AG 2010
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Basic
Functions>Requests
In customizing, you have to define a number range per Request Class and Request Category.
You also have to configure a Document Type per Request Category, which can be used as default
value.
In customizing for Contract Accounts Receivable And Payable, there is an IMG activity in which
you can define default values for the clearing documents for General Requests. Use the IMG path:
Financial Accounting>Contract Accounts Receivable and Payable>Basic
Functions>Requests>General Request>Define Specifications for Clearing Documents for General
Requests.
If you want the system to clear the Contract Accounting documents automatically with the
payments, you must select the relevant field in customizing using the IMG path: Financial
Accounting>Contract Accounts Receivable and Payable>Basic Functions>Requests> Define
Basic Settings for Document Creation.
© SAP AG
IHE203
8-56
8. Document Posting & Processing - Part 3:
Unit Summary
You should now be able to:
Post requests
Explain the function of standing and general requests
© SAP AG 2010
© SAP AG
IHE203
8-57
© SAP AG
IHE203
8-58
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP AG 2010
© SAP AG
IHE203
9-1
9. Correspondence: Overview
Contents
„
Correspondence Concepts and Definitions
„
Correspondence Handling and Customization
„
Inbound Correspondence: Requests and Receipt
„
Print Workbench Overview
© SAP AG 2010
© SAP AG
IHE203
9-2
9. Correspondence: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Identify various correspondence types.
„
Configure and handle correspondence.
„
Work with correspondence history.
„
Define address determination .
„
Create outbound and inbound correspondence as a periodic process.
„
List the components of the print workbench.
© SAP AG 2010
© SAP AG
IHE203
9-3
9. Correspondence: Business Scenario
„
Your institution plans to create invoices and other correspondence, such
as checks.
„
Some students may have to file certain documents on a regular basis.
Your institution wants to reflect the process in the system and keep track
of the incoming correspondence to remind the student.
© SAP AG 2010
© SAP AG
IHE203
9-4
9. Correspondence: Definitions
Correspondence
All written output you send to your business partner and printed
evaluations, reports, statements, etc.
Inbound correspondence
A Business Partner’s obligation to file a written item without
reminder.
Correspondence History
Contains entries for written correspondence and stores requests
and receipts of incoming correspondence.
Print Workbench
Tool for generating printed correspondence.
© SAP AG 2010
„
The course refers to “printed” correspondence when the document is sent by e-mail as a PDF. The
recipient may or may not print the correspondence.
© SAP AG
IHE203
9-5
9. Correspondence: Use
You can create correspondence
„ In a mass run
--> Periodic Processing/for Contract Accounts/Correspondence
e.g. Invoice, Account Statement, Business Partner Statement
„
On demand/Individual Creation
--> Menu choice in certain transactions: Account Balance, Cash Desk, Contact Center
e.g. Online Check, Account Information. Account Balance / Print
„
In connection with other processes
--> Function Module in Customizing or Customer Enhancement
e.g. Dunning Letter, Payment Notifications
© SAP AG 2010
„
SAP delivers several Correspondence Types. For example:
• Business Partner Statement: All open items that were posted after the last Business Partner
Statement (Event 1913)
• Balance Information: All open items for a certain contract account that were posted after the
last balance information
„
Using Business Partner Statements is recommended, for example if:
• Several Contract Accounts exist for a Business Partner and you only want to use one.
correspondence to inform your business partner of the balance 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.
„
Using Balance Notifications is recommended if, for example:
• External auditors want to inform a sample of customers about the current balance of their
customer account.
• Customers must be informed about the running balance once in each period (requirement in
specific countries).
© SAP AG
IHE203
9-6
9. Correspondence: Types of Correspondence
SAP delivers the following types of correspondence:
Returns (0001)
Interest Statement (0007)
Account Statement (0002)
Payment Medium Check (0015)
Dunning Notice (0003)
Online Check (0021)
Installment Plan (0005)
Cash Receipt (0009 or 0043)
Payment Advice Note (0006)
Cash Journal (0010 or 0037)
Account Information (0013)
Write off Notice (0034)
Document (0014)
Public Sector / Student Lifecycle Management Invoice (P004)
© SAP AG 2010
„
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, 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, however, is directly influenced by the user. For example, the user can
specify under user-specific selection criteria that he wishes to see only items posted against contract
account ABC during the month of January, and whose amounts lie between 1000 and 10000 units of
currency.
„
The invoicing function is used to inform Business Partners of receivables for which they are liable
and to send them printed payment requests.
„
Invoicing is a Mass Activity that is fully integrated in the correspondence component. An invoice
groups all open items into a billing amount. The invoice with this amount is sent to the customer.
Depending on your customizing settings, the paper notification sent to a customer is an invoice with
(or without) an attached payment document.
„
To address Student Lifecycle Management-specific needs, such as identifying courses or Programs,
SAP delivers Form Class FMCA_INVOICE.
© SAP AG
IHE203
9-7
9. Correspondence: Types of Correspondence
(2)
SAP delivers the following types of correspondence:
Payment Notice (0019)
Payment Form for Installment Plan (0008)
Incoming Correspondence (P700)
Correspondence Dunning (0020)
Student Lifecycle Management Student Correspondence (CM00)
Student Lifecycle Management Admission Correspondence (CM01)
Get more information about correspondence types at:
help.sap.com SAP ERP SAP ERP Central Component Collection and
Disbursement Basic Functions Correspondence Creating Individual
Correspondence and Creating Correspondence in Mass run.
© SAP AG 2010
„
You may define your own Correspondence Types as long as they use the standard customer naming
conventions.
„
You can design your own Application Forms using delivered samples as the basis.
„
Specific to Student Lifecycle Management:
• SAP also delivers Correspondence Types and sometimes Sample Forms:
• From the SAP Easy Access Menu, choose: Student Lifecycle Management>Correspondence.
• On the Correspondence Tab in the Student File, you will see all correspondence that has been
produced for that student. You can also reprint individual correspondence from this tab.
© SAP AG
IHE203
9-8
9. Correspondence: Billing > Public Sector
Invoice (P004)
You can assign an Invoice Type to a:
„
Contract Account
„
Contract Object
Invoice types are maintained in customizing. You can decide:
„
Whether you want to include items that were previously entered in a printed invoice
(so that the Business Partner gets a complete overview of all open items)
„
Whether you want to include statistical items
„
Whether you want to include deferred items
„
Whether you want to include negative items
„
Whether you want to allow a negative balance
You then assign the relevant Application Form to the Invoice Type.
© SAP AG 2010
„
You have to allocate a Bill Type to a Contract Account or Contract Object level, depending on
whether or not the indicator for creating correspondence is set at Contract Object level.
„
The Bill Type is used to select items or exclude items from being processed for correspondence.
Note: Only open items are relevant for a bill.
„
The system uses the payment program to determine which items should be included in bill
processing.
„
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 invoice types can be printed. The invoice
type determines the items to be printed and what the invoice looks like.
„
…
© SAP AG
IHE203
9-9
…
„
Additional texts should be added to the invoice at the time of printing (PSCD print workbench) by
an exit in the application form.
„
You can define whether the Mass Activity for creating invoices only groups together items for
invoices that have no incoming payment method, or whether all items, irrespective of their payment
method, are included (Event 0600, FMCA_INV_ALL_ITEMS_0600).
© SAP AG
IHE203
9-10
9. Correspondence: Correspondence Type
Configuration
Correspondence Type: 0002 (Account Statement)
Recipient Control
Do we allow additional or
alternative recipients?
Events
Print event
Generation event
Miscellaneous
Application area
Periodic correspondence?
Gaps allowed?
Suppress correspondence if
no items present?
Inbound correspondence?
-----------------------------------------------------------------------------
Your
Account
© SAP AG 2010
„
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.
„
The following two Events are necessary and are associated to each Correspondence Type:
• 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
• A Generation Event: Function Module needed to create or generate a correspondence request
„
Miscellaneous settings control which application area can use a given Correspondence Type, and if
the Correspondence Type event is periodic.
© SAP AG
IHE203
9-11
9. Correspondence: Handling Correspondence
Data
Input
Dunning
data
Returns
data
Account
statement
data
Invoice
data
Additional data
Storage
Creation
Creation
Correspondence
Correspondence Data
Data Container
Container
Key data
tables (DFKKCO*)
Output
Print
Print (Trans:
(Trans: FPCOPARA)
FPCOPARA)
Print
any
type
© SAP AG 2010
„
Correspondence data is created by different application programs and stored in an abstract manner.
Key data from dunning, returns, account statements, returns, etc. are stored in the Correspondence
Data Container which is a set of tables (DFKKCO*). Each entry within this table represents an
object that can be sent to a business partner.
„
In general, the data container references additional data that resides in the originating program.
„
The printing run is done in a separate step within the Correspondence Menu. From the
Correspondence Data Container, you can select any data that you wish to print.
„
Centrally stored correspondence data can be used for different purposes, such as sorting, archiving,
defining send controls and application forms, re-printing and test printing, and for specific data
selections.
„
It is recommended that printing be carried out soon 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.
© SAP AG
IHE203
9-12
9. Correspondence:
Correspondence History
After Correspondence has been produced it can be displayed for:
„
All correspondence for a specific business partner
„
A specific correspondence type for all business partners
SAP Menu > Contract Accounts Receivable and
Payable > Account > Further Information >
Correspondence History
Correspondence for Students is also visible from the Student File (PIQST00)
© SAP AG 2010
„
By creating an entry into the Correspondence Container, the correspondence history is filled
(Transaction: CORRHIST or FPCOHIST: Display Correspondence History).
„
Correspondence history stores information about all correspondence, including inbound
correspondence.
„
History capabilities include archiving of correspondence (reorganization of table DFKKCOH) and a
Pixel Viewer for letters. The Pixel Viewer is a viewing tool like Adobe Acrobat Reader and is used
to read optically archived documents.
© SAP AG
IHE203
9-13
9. Correspondence: Additional Features of
Correspondence
„ Selection
methods for students
„ Processing in different languages
„ Shipping (paper, e-mail, fax)
„ Archiving
„ Address Determination
© SAP AG 2010
„
In Student Lifecycle Management, it is useful to select students based on specific attributes. You can
also use Selection Methods that are integrated in many Student Lifecycle Management applications
to select students in FI-CA mass activities, such as correspondence.
„
Correspondence can be produced in different languages.
„
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.
„
Archiving: You can archive entries to the correspondence history. Only the objects of the container
are archived, not the printed document. If you want to archive and display printed
correspondence, you must additionally configure customizing within the Basis Services of
Application Server of SAP NetWeaver.
© SAP AG
IHE203
9-14
9. Correspondence: Correspondence Control
Contract Account / Correspondence Data
Invoicing
Invoicing type
Lock
Correspondence control
Correspondence variant
Correspondence to alternative/additional partners
Correspondence variant
Correspondence dunning procedure
Correspondence dunning lock
Recipient for individual correspondence types
Correspondence recipient
Correspondence
type
….
Correspondence
name
….
Alternate Correspondence
recipient?
recipient
….
….
Activity
Partner
description
….
Activity Description
….
….
© SAP AG 2010
„
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.
„
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.
„
Address determination: If you use an alternative recipient, you must enter an additional/alternative
recipients for the Contract Account or Contract Object before you create a correspondence request.
The alternate Business Partner must exist and must have a valid address.
© SAP AG
IHE203
9-15
9. Correspondence: Output Options
© SAP AG 2010
„
You select the print setting via the appropriate indicator in the print dialog. Use F4 to see possible
values.
„
Raw data is sent to the print workbench and processed there, instead of creating own forms in each
program.
„
If you require raw data (which means that the layout design of the form has to be done in an external
printing system), RDI acts as a raw data interface for SAPScript, XFP for Adobe Forms = PDF.
„
SAP provides three storage methods:
• Print
• Archive only
• Print and archive
„
You select the print setting via the appropriate indicator in the print dialog. There are five possible
settings:
• * SAPscript Form 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)
„
For additional details on the Print Workbench, please see SAP course IUT280.
© SAP AG
IHE203
9-16
9. Correspondence:
Overview - Creation of Correspondence
Event controlled through business
transaction
Dunning
Returns
Interest calculat.
Installment plan
Event 705
0003
Function
Correspondence requisition
Event 701
0001
Selection
Function
Event 704
Event 713
0007
0003
Function
Event 709
Function
Contract
Account
0005
Customer
Acct. Statem.
Get additional
data
Reference Dunning
data
data
Event 704
P004
Function
Event 702
0001
Periodically through correspondence
runs
Invoicing
Correspondence print
SAPLFKCC
Function
Correspondence requisition
Function
FK: FI_CA_Dunning
Print
workbench
Refusal
Form
Customer
Reminder
Customer
Invoice
Selection
KA: Correspondence type
FK: Form class
© SAP AG 2010
„
General steps within correspondence:
• Creation of correspondence requisition is performed via business transactions or correspondence
runs.
• Storage of reference data in the correspondence container.
• Select the correspondence data from the correspondence container and prepare the data for
printout via a correspondence print run.
• Print the correspondence data via SAPScript, Smart Form, Print Workbench, or the raw data
interface (to print via an external printing system).
© SAP AG
IHE203
9-17
9. Correspondence: Correspondence Variant
For Each Contract Account Category:
ƒ Identify the types of correspondence to be produced
„ Assign the types to a Correspondence Variant
„ Assign the Correspondence Variant to the Contract Account or Contract.
Example:
Your institution typically uses different documents for specific
partners/accounts, and defines three variants.
Variant
Description
Z001
ZST
ZSP
Standard
Student
Sponsor
Types
0002, 0003,
0002, 0003, Student Lifecycle Management 00
P004
© SAP AG 2010
„
All periodic Correspondence Types must be assigned to a Correspondence Variant.
„
You assign the appropriate Correspondence Variant to the Contract Account and/or Contract Object.
© SAP AG
IHE203
9-18
9. Correspondence: Customizing
Correspondence Variants
Correspondence
Correspondence Variant
Variant Z001
Z001
IMG
Change
Change View:
View: Correspondence
Correspondence Variant:
Variant: Overview
Overview
Correspondence type Correspondence name Interval Shipping control Charge schedule
0002
Account statement
0003
Dunning notice
0013
Account information
Key in which the type of correspondence (such as
a Return Notification or an Account Statement)
and accompanying control attributes are defined.
1
Frequency with which correspondence
is to be produced for the specific
Correspondence Type.
© SAP AG 2010
„
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 run is
executed.
„
All periodic correspondence (for example, Type 0002 – Account Statement) must be defined in the
Correspondence Variant.
„
Shipping control is used to send a document, such as an invoice or dunning notice, in different forms
and in multiple copies, for example by e-mail or fax.
„
You can use Event 775 to vary the dispatch control for a given correspondence. For example, your
institution may decide to send the first dunning correspondence (that is, a friendly reminder) by email to the student’s university e-mail address, but to print and mail any subsequent dunning
correspondence to the student’s home address.
„
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.
„
Customizing is done in two areas of the IMG.
• Contract Accounts Receivable and Payable>Basic Functions>Print Workbench
• Contract Accounts Receivable and Payable>Basic Functions>Correspondence
© SAP AG
IHE203
9-19
9. Correspondence: Inbound Correspondence
Inbound Correspondence
„
Used to record a Business Partner’s obligation to file a written notice, for example, a
promissory note (loan), transcripts, and so on.
„
You generate a correspondence request according to the rule that is stored in the Contract
Object.
„
The obligation and its fulfilment are visible in the inbound correspondence history and in
the correspondence history.
© SAP AG 2010
„
In PSCD you are not restricted to the administration of payments and financial issues. You can also
manage obligation’s to file written notices.
„
The management of inbound correspondence can be compared with the posting of documents and
payments. When you generate inbound correspondence, you create an open item. You record the
date of receipt in the correspondence history. If an obligation is overdue, you can dun the businesspartner.
„
Note: With the standard delivery you cannot dun or invoice financial and non-financial obligations
together in one letter.
„
Inbound correspondence can only be defined on the Contract Object level in PSCD.
„
You must start a Mass Run to create a correspondence request. The Mass Run generates an entry
into Inbound correspondence-history (Transaction FMCAINCOH - Process Inbound
Correspondence) with the due date of the expected correspondence.
„
If the Business Partner does not send the letter, you can start a dunning run and a dunning note, to
inform the Business Partner of his obligation.
© SAP AG
IHE203
9-20
9. Correspondence: Inbound Correspondence Procedure
2 Generation of Inbound
Correspondence
1
Contract
Objects
Object
Object 11
Display/Change
Date of Receipt
Date of Deferral
Dunning Lock
3
Correspondence
History
Object
Object 22
Object
Object 33
Object
Object 44
4
Corr. Dunning Run
Corr. Printing Run
© SAP 2008
The procedure consists of the following steps:
Create the actual obligation and write it to the correspondence history.
• Mass Run = Easy Access Menu: Accounting>Financial Accounting>Contract Accounts
Receivable and Payable>Periodic Processing>For Contract Objects>Inbound
Correspondence> Generate Inbound Correspondences
• For a Contract Object = from master data maintenance for the Contract Object: tab page
“Inbound Correspondence”, pushbutton “Inbound Correspondence” and then choose “New”
„ Manage inbound correspondence:
• Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing>For Contract Objects>Inbound Correspondence>Inbound
Correspondence History
• From master data maintenance for the Contract Object: tab page “Inbound Correspondence”,
push button “Inbound Correspondence” and then choose “Existing.”
„ Dun overdue correspondence and print a dunning notice:
• Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing>For Contract Objects>Correspondence/Correspondence
Dunning Run.
• Note: Customize the correspondence dunning procedure using the IMG path: Financial
Accounting>Contract Accounts Receivable and Payable>>Business Transactions>Inbound
Correspondence Dunning .
Note: Afterwards, you can display the dunning in the correspondence dunning history. Do NOT
confuse it with the dunning history, which refers to open payments.
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing>For Contract Objects>Inbound
Correspondence>Correspondence>Dunning History
„
„
© SAP AG
IHE203
9-21
9. Correspondence: Inbound Correspondence Considerations
You have to decide
„ The
„ How
„ If
status: active or not
you need a correspondence only once, you set the status on “immediately“.
„ When
„ You
„ If
IMG
often does the Business Partner have the obligation to send the correspondence?
is it due?
can restrict the obligation to a certain period of time.
there is an exemption period (e.g. seasonal obligations)
„ Which
correspondence dunning procedure has to be applied
IMG
© SAP AG 2010
„
Status: You can assign a status in contract object master data maintenance. The status of the contract
object determines whether inbound correspondence can be generated (you set a flag) for this
contract object when you run the Generate Inbound Correspondence program. You define a status in
the IMG: Contract Accounting Æ Business Transactions Æ Inbound Correspondence.
„
In the IMG, you can also define tolerance days for the calculation of the due date. You can specify a
tolerance in months and days for each of the periods provided with the standard system. The last day
of a period is used as the reference date for the postponement of the due date. Specify the number of
months or days by which you want to postpone the due date for inbound correspondence, starting
from the end of the period.
„
Example: You want to stipulate that inbound correspondence that is generated quarterly is due one
month after the end date for the calculation period. To do this, make the following entries:
• Period: Quarterly
• Correspondence Type: P700 (Inbound Correspondence)
• Month: 1
• Days: No entry
„
You define the obligation in the A/P and A/R data of the contract object in the Inbound
Correspondence tab.
„
If you need a correspondence only once, set the status to “immediately”.
© SAP AG
IHE203
9-22
9. Correspondence: Overview
SAPscript
Form class
Data
hierarchy
Smart Form
PDF-based Form
Layout
Database
Form class library
information
Application form
Event-driven
hierarchy
Text 1
Data: ...
Select * from ...
Call function
OPEN_FORM ...
Print Program
Text 2
generates
© SAP AG 2010
„
You can find more details about the Print Workbench in the documentation for SAP component CAGTF-PWB.
„
The Print Workbench offers an improved way to create 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.
„
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 should be printed on a specific piece of correspondence.
© SAP AG
IHE203
9-23
9. Correspondence: Unit Summary
You should now be able to:
„
Define and create the different types of correspondence
„
Configure and handle correspondence
„
Work with correspondence history
© SAP AG 2010
© SAP AG
IHE203
9-24
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
public
© SAP AG 2010
© SAP AG
IHE203
10-1
10. Payments: Overview
Contents
„
Incoming and Outgoing Payment Processing
„
Payment and Check Lots
„
Cash Journal
„
FSCM Biller Direct
„
Payment Run Setup and Execution
„
Generation of Payment Media
„
Outgoing Check Processing and Management
„
Payment Card Management
© SAP 2008
© SAP AG
IHE203
10-2
10. Payments: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Differentiate between incoming and outgoing payment transactions that are
initiated by the public sector organization
„
Set up payments and check lots
„
Post manual payments using cash journal
„
Describe payment runs and payment card processing
„
Categorize payment control data as pertaining to customizing, master data,
or posting data
„
Discuss generation of payment media
© SAP 2008
© SAP AG
IHE203
10-3
10. Payments: Business Scenario
„
Your institution maintains offices where students can pay by cash, check,
and credit card. The payments are processed manually by a cashier.
„
Your institution accepts bank transfers and Web payments.
„
Your institution executes the payment run on a daily basis to refund tuition
fees and to distribute excess financial aid.
© SAP 2008
© SAP AG
IHE203
10-4
10. Payments: Initiation of Payment
Transactions
Initiated by business partner
Initiated by university
Incoming payments of self-payers:
Incoming and outgoing payments:
Incoming cash
Incoming checks
Incoming bank transfers
Incoming payment cards
Biller Direct (web payments)
Outgoing
checks
Outgoing bank transfers
Payment cards
Bank direct debit
Bank collection
Also:
Payment/Check Lot
internal clearing (transfer postings)
Payment Program
Cash Journal
© SAP 2008
„
In PSCD, we distinguish between payments that are initiated outside your institution and payments
initiated within your institution.
„
The payment program considers the open items due from all business partners or contract accounts
selected by the institution. The program can be used to process both incoming and outgoing
payments.
„
When the payments is initiated outside, the Business Partner (Student, Sponsor, Parent etc) decides
when to pay. Payments initiated from outside can be processed manually at a cashier’s office (cash
journal) or by a payment lot. Payments can be processed “on account” and cleared later or can be
applied directly to open items.
„
When payment is initiated inside, the institution decides when it will collect or disburse payments
from/to the business partner. All payments initiated by your institution are processed by the payment
program.
„
SAP Biller Direct falls into both categories. The Student initiates the payment providing a card
number or bank account. This creates a payment request which is cleared when running the
payment program. Depending on the local banking arrangements, the institution receives the funds
through the card authorization process or the settlement process with the card institution/bank.
„
MG path: Financial Accounting> Contract Accounts Receivable and Payable>Business
Transactions>Payments>Incoming/Outgoing Payment Creation
© SAP AG
IHE203
10-5
10. Payments: Processing of Incoming
Payments - Externally Initiated
The following incoming payments are initiated by the Business Partner
(Student, Parent, Sponsor, other Agencies):
„
„
„
„
„
Cash
Check
Payment card
Bank transfer
Payment forms
© SAP 2008
„
Externally 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 an
externally generated payment method as well as an internally generated method.
„
An 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 payment
manually to one or more open items.
„
Payments not assigned to an open item can be posted on account or put into the clarification
controller for clarification activities.
© SAP AG
IHE203
10-6
10. Payments: Payment Lots and Check Lots
Incoming check data
Bank transfer data from
an account statement
Check
Check lot
lot
Lot is generated manually
Payment
Payment lot
lot
Lot generated automatically
(can be done manually)
Bank statement
© SAP 2008
„
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.
„
You enter payment/check lots manually if the payment information exists in written (paper) form.
This is normally the case for check payments (example, admission application fees, housing
deposits), 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.
„
Interfaces:
„
Data Transfer from Electronic Account Statement to Payment Lot
„
Report: RFKKKA00- Data Transfer from Account Statement to Payment/Returns Lot
(Transaction FPB7): This 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.
„
If you convert country-specific bank formats into the MultiCash format, you can use this report
(RFKKkA00) to transfer data from the MultiCash statement file and line item file to payment and
returns lots in PSCD.
„
The files can also be generated using neutral interfaces. However, these must have the SAP format which means they must not contain any country-specific formats from the electronic bank
statements.
© SAP AG
IHE203
10-7
10. Payments: Parallel Data Processing: Lots
Close lot
items
1
2
Post lot
= activity
run
3
Technical
Settings
Technical
Settings
Log
Log
Schedule
Manual postprocesses
Enter
Authorized reopening
Lots are processed in the following steps:
Lot
completed
& update
history
DB
4
Schedule
© SAP 2008
„
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 or interface program) or by cash journal.
• 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 is permitted. No payments can be added or deleted
from 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 (bank account). Payment differences can be automatically posted to special profit and
loss accounts.
„
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 on account (where the account can be determined, but the open
item to be cleared cannot).
„
Authorization object F_KK_SOND with Activity 011 is needed to reopen closed Payment/Check
Lots.
© SAP AG
IHE203
10-8
10. Payments: Payment/Check Lot: Header
Screen Structure
Payment lot Create: Default Entries and Status
Control totals and status information
Debit specified
Credit specified
Specifications for the posting document
51
Document type
Reconciliation key
Document date
Items specified
Posting date
Currency
Exchange rate
Specifications for posting items in the bank clearing account
Bank clearing account
Company code
Value date
Business area
Line item
Specifications for selecting and clearing open items
Clearing reason
01
01
Selection categories
C
C
BB
IMG
© SAP 2008
„
A manual payment/check lot consists of a header entry, one item per payment and, optionally,
several sub-items per payment. In the header, data is saved that is valid for the entire lot, along with
data that is used as the default value 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 reason (for example, incoming
payments) and the selection categories (for example, partner number, contract account number).
„
Selection information is used to identify the open items that must be cleared with the payment
and/or to prepare the data for payment on account.
• Information is always given in the form Selection category / Selection value.
Example: C stands for Contract Account; B stands for Business Partner; P stands for Period Key.
• Selection categories are defined in customizing: IMG path: Financial Accounting >Contract
Accounts Receivables and Payable>Business Transactions> Payments>Incoming/Outgoing
Payment Creating
© SAP AG
IHE203
10-9
10. Payments: Payment/Check Lot: Processing
Selection Categories
Selection Categories
T
Description
D
C
F
B
O
R
P
Document number
Contract account
Net due date
Business partner
Contract account
Reference for payment form
Period key
+ any field in structure FKKOP!
© SAP 2008
„
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, Payment Form Reference Number
(reference number assigned to a payment form from an external system), Document Number,
Reference Document Number, Net Due Date, And Student Number (if different than BP number).
Of all possible fields, the system displays only those that were specified as a selection category for
your application in this activity.
„
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Basic
Functions>Open Item Management>Specify Selection Categories
© SAP AG
IHE203
10-10
10. Payments: Payment/Check Lot: List Entry
of Payments Screen
Further details
Payment
amount
500
Screen template
Field
T value
K 11-2135
T
Field
value
Value
date Currency
….
With list entry, you fill in
one line for each
payment. Variants can
be defined in
customizing to tailor the
line layout structure. It is
possible to change
screen variants while
processing.
Entries here determine what
type of field value must follow
(for example, contract
account).
© SAP 2008
„
Using the button “Further Details” or double-clicking on the desired line brings you to the detail
screen (not shown in graphic) for the item selected. You can then enter further data for the payment.
„
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Business
Transactions>Payments>Incoming/Outgoing Payment Creation
„
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).
© SAP AG
IHE203
10-11
10. Payments: Payment/Check Lot - Detailed
Specifications
Payment data
Selections
163190
Bank number
163190
Bank account
Check number
Account holder
Usage text
Additional information
Post on account
Clarify
Repayment
Note to payee
Posting data
Bank country
Reference
Field appears for check lots
Transfer posting to
Clarification account
Refund method
Definitions for selection of items
C Field value
C Field value
C
11-2135
C 11-2135
.
.
.
C Field value
PO bank account
Control key
Check returned
Standing order
Uses “short” account
assignment
Partial amount
© SAP 2008
„
On the detail screen, you can add further specifications that are required for the allocation of
payment or with a subsequent clarification.
„
Selections within a line are linked by AND, 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 x 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. The item is marked for repayment by the method chosen here.
„
It is possible to use an entry screen in the Payment Lot transaction, where you can only enter
selections.
„
Moreover, a search function helps the user to search according to the content of a column in the item
list.
„
When a payment lot item is displayed, the payment assignment can be reset or you can go to
clarification processing. Clarification is only possible if the clarification case has not been reserved
for another user.
© SAP AG
IHE203
10-12
10. Payments: Payment Advice
© SAP 2008
„
„
„
„
„
A payment advice may be created automatically or manually and serves as an advance notice of
what items will be paid by a business partner. The advice, in turn, can be used to select items to be
cleared when performing a manual clearing posting or (more likely) posting a payment/check lot.
The selection category defined in the header section of the payment advice note will default for all
lines contained in a payment advice, but can be overwritten individually if the can overwrite flag is
set.
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. For a
payment advice to be used and found when posting a payment/check lot, a selection category for the
AVKEY field (payment advice number) must be created, e.g. Z.
In addition to the business partner or the contract account, you can also use the payment advice
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 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 (Transfer of Payment Advice Notes from a Sequential File) also transfers
payment advice notes from a sequential file and uses the data to generate one or more payment
advice notes. It carries out the following activities:
• Reads the application server file specified and checks the data contained therein
• Creates one or more payment advice notes provided the data records are correct
• Closes the payment advice notes provided the corresponding indicator is set.
• Defective data records are saved separately and can be transferred once you have corrected them.
© SAP AG
IHE203
10-13
10. Payments: Interpretation Rules: Note to
Payee
© SAP 2008
„
Interpretation rules are used to automatically analyze notes to payee texts. The analysis occurs when
payment data is automatically transferred to payment lots. Values and rules have to be defined in the
IMG so that the system can identify a selection criteria (for example, a business partner or a contract
account object).
„
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.
„
Data Transfer from Electronic Account Statement to Payment/Returns Lot:
„
Report RFKKKA00/Ttransaction FPB7:((Data Transfer from Account Statement to
Payment/Returns Lot). Selects payments, returns and payment orders that are imported into the
bank data memory during the proces-sing 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. Or, you can output selected data from the bank data memory in a
file. In another step you can then import the created files into payment lots, payment order lots or
return lots. You can do this using the PSCD transfer programs RFKKZE00 (Payment Lot Transfer)
and RFKKRL00 (Returns Lot Transfer). The system uses the business transaction and the amount
+/- sign to decide the lot type a payment position is transferred to. (see also Event 0950)
„
…
© SAP AG
IHE203
10-14
…
„
Report: RFKKKA00/Transaction FPB17 (Transfer MultiCash files FI-CA). Data transfer from
MultiCash files to payment, payment order and returns lots.): If you convert country-specific bank
formats into the 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 PSCD. 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: IMG path: Financial Accounting>Contract Accounts Receivable and
Payable>Business Transactions>Payments> Incoming/Outgoing Payment Creation
© SAP AG
IHE203
10-15
10. Payments: Note to Payee - Configuration
© SAP 2008
„
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.
„
To simplify the customizing settings for the interpretation rules for the note to payee, you can use
Transaction: FP_NOTE_TEST (Note to payee Analysis – Test) to test the note to payee analyses.
„
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Business
Transactions>Payments>Incoming/Outgoing Payment Creation
© SAP AG
IHE203
10-16
10. Payments: Interpretation of Note to
Payee - Example
© SAP 2008
„
The above example shows the values provided by the bank (either from a Bank Statement into FI or
posted a payment lot generated from an import file).
„
Payment allocation by processing the payment lot: In the case of payment lots, items from the bank
clearing account are posted to payment usage or to the interim account. The document number is
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
© SAP AG
IHE203
10-17
10. Payments: Clarification Work List
Clarification Work List
Contains all cases (postings) that need clarification. You can create a
workflow to assign items to different users.
You can
„
„
„
„
„
„
Find payments
Check the posting document
Look for similar master data
Assign the payment to an open item
Post online
Generate correspondence with the bank
© SAP 2008
„
Items requiring clarification arise where you post a payment/check lot but either some or all
payments could not be posted to a contract account (due to missing or incorrect customizing, for
example). When you post a payment/check lot, these items are posted to an interim account defined
in Customizing and included in a clarification work list.
„
By processing the clarification work list, you can make transfer postings for these items from the
interim account to a contract account. You can carry out post processing for a single payment/check
lot or for all items requiring clarification (for more than one payment/check lot.
„
You can clarify payment/check lot items in the following ways:
• Correct the payment item (the data by which the item was selected) and restart postings for
selected items (with open item clearing or on account).
• Post and clear selected items manually (with open item clearing or on account). It is possible to
partially clear items while clarifying. Partial clearing can be posted more than once. It is also
possible to transfer post items using short account assignment defined in Customizing. In
conjunction with this posting, it is possible to begin a workflow (for example, to send an e-mail
to the department receiving the posting).
• Create a repayment (refund) request if you cannot assign the payment amount received to a line
item. The system then makes a transfer posting from the interim account to a clearing account for
repayments.
• A 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.
„
...
© SAP AG
IHE203
10-18
…
„
The customizing for processing clarification worklists is supplied by SAP. IMG:path: Financial
Accounting>Contract Accounts Receivable and Payable>Technical Settings> Prepare Processing
of Clarification Worklist. Check and, if necessary, modify the settings.
© SAP AG
IHE203
10-19
10. Payments: Selecting Clarification Cases
from Payment Lot
Selection
Administrator mode
Resubmission cases
Workflow cases
Critical cases
In Process by me
In Process by other user
Resolved
Set to Resubmission
FPCPL
Worklist: Payment Lot
Status Status Name Doc. No. Amount
In process
4711
80,-
Clarif.Account
Acc.Holder
113300
Smith W.
Open item
clearing
Posting on account
Transfer posting to
clearing account
Clarify
Lock
Unlock
Set Clar. Case for
Resubmission
Change
Status/User
Arrangement of
repayment
© SAP 2008
„
The selection options in the payment clarification list enable you to limit open clarification cases
according to clarification accounts and account holders.
„
If you have implemented Workflow, you can also define mapping rules by using the new roles
2100008 (Limited Selection Clarification Work list) and 2100009 (Limited to Acute Clarification
Cases) and assigning each clarification case to at least one processor or a group of processors.
„
You can automatically transfer the bank details of Business Partners that you obtained during
clarification processing into the Business Partner’s master record. Use the Transfer Bank Data from
Clarification Cases function in the menu under Master Data Æ Business Partner.
„
You can transfer payments from payment or check lots that are in clarification, and which you
cannot assign, after a predefined period using a program. This will remove them from the
clarification work list. 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.
„
The function Maintain Exception Accounts for Payment Clarification enables you to define different
rules and individual default values for creating proposals that clarify incoming payments.
© SAP AG
IHE203
10-20
10. Payments: Credit Processing
© SAP 2008
„
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 (correspondence type 0032) can be used for processing in
credit clarification.
„
You can also access the credit list by choosing Account Æ Process Credit.
„
To define the default selection criteria, use the IMG path: Financial Accounting>Contract Accounts
Receivable and Payable>Business Transactions>Define Selection Criteria for Credit Clarification
© SAP AG
IHE203
10-21
10. Payments: Payment/Check Lot - Changes
to Protected Fields
The following protected fields can be changed:
Payment lot created automatically:
Payer’s bank data
Note to payee
Check lot:
Check number
© SAP 2008
„
In Payment Lots created automatically, you can change the bank data of the payer and the note to
payee during clarification. A correction is necessary, for example, if a data reader has incorrectly
interpreted a hand-written note to a payee. To carry out this function you need Authorization 017
for Authorization Object F_KK_SOND.
• To make the fields on the Payment Data or Note to Payee tab pages ready for input, choose Edit
Æ Change Bank Data.
„
In Check Lots, you can use the special Correct Check Number function to correct the check number
for individual payments in lots that have already been closed or posted. You may need to make a
correction, for example, if, when creating the check deposit list, you discover that check numbers
have been entered incorrectly. To carry out this function you need Authorization 014 for
Authorization Object F_KK_SOND. You make the change in the Check Lot display.
• On the first screen, choose Edit Æ Correct Check Numbers.
• Call up the detailed display for the check payment to be corrected and choose Edit Æ Correct
Check Numbers. The Check Number field is then ready for input You can overwrite the number
and save.
© SAP AG
IHE203
10-22
10. Payments: Cash Journal Overview
© SAP 2008
„
There are two options for processing manual payments:
• Cash Journal
The Cash Journal comprises functions typical for cashier operations. The Cash Journal
functionality includes the mapping of a Cash Desk structure and a role-based authorization
concept. Cash deposits, withdrawals and differences can be posting documents 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.
Payment at Cash Desk is an integral function of the Cash Journal.
• Payment at Cash Desk
This function is only used to process payments.
„
If your institution wants to use the comprehensive functions offered by the Cash Journal, it must
be activated in customizing. IMG path: Financial Accounting>Contract Accounts Receivable and
Payable>Business Transactions>Payments>Processing Incoming and Outgoing Payments> Cash
Desk/Cash Journal.
• …
© SAP AG
IHE203
10-23
…
• 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
Cash Desk, this Cash Desk is automatically closed. If you want to make further postings to this
Cash Desk, you must open the cash desk again.
© SAP AG
IHE203
10-24
10. Payments: Cash Desk Structure
© SAP 2008
„
You can use the Cash Journal to reflect the cash structure of your institution. For example, you can
define a cashier office for the main campus and one for each off-campus location.
„
From the Easy Access Menu, choose Accounting>Financial Accounting>Contract Accounts
Receivable and Payable>Payments>Cash Journal>Cash Journal Master Data.
„
The Cash Journal contains three user roles to which you can assign your employees:
• Standard role 22000001: Branch office manager
• Standard role 22000003: Cashier with special duties
• Standard role 22000005: Cashier
„
You can assign the following activities for the cash desks to specific roles:
• Open/close one or all Cash Desks for the branch
• Post deposits, withdrawals, and Cash Desk differences
• Daily or historic evaluations of Cash Desk balances for a cash desk or the whole branch
• Transfer of responsibility for postings to another user
„
The postings in the transaction data are executed and evaluated with the role assigned to the user.
„
The Company Code and the Bank Clearing Account, as well as Lots that have already been created
according to the Payment Category, are proposed depending on the Cash Desk. If an open Lot is not
available, the system automatically creates a corresponding Payment Lot. The branch and the Cash
Desk are the first 5 figures of the name.
© SAP AG
IHE203
10-25
10. Payments: Individual Enhancements to
Cash Journal
© SAP 2008
„
Individual Enhancements:
„
Bar Code Reader & Payment Card Reader Devices
„
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. The bar code scanned must be interpreted in Event FKK_SAMPLE_6060.
Payment Card reader devices have been added and work similar to bar code scanners. See Events
6065 and 6070.
„
There are 5 additional customer functions that can be activated and used for Event 6120.
„
There are many other Events (60xx – 61xx) to enhance Cash Desk/Cash Journal to an institution’s
specific requirements
© SAP AG
IHE203
10-26
10. Payments: Cash Journal Processing
© SAP 2008
„
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.. 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 returned to the customer.
© SAP AG
IHE203
10-27
10. Payments: Post Manual Payments with
Business Partner
The cashier can initiate various actions, including receipt printing.
© SAP 2008
„
This transaction allows a user to enter payments manually. Cash, Card, and Check payments are all
permitted within this transaction.
„
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).
„
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 under the IMG path:
Financial Accounting>Contract Accounts Receivable and Payable>Business Transactions>
Payments>Processing Incoming/Outgoing Payments. Expense and revenue accounts for posting
of differences are also defined in Customizing (in the Automatic G/L Account Determination
section).
„
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.
• Simple Selection: You may enter a Business Partner, a Document Number or a Barcode (see
picture above)
• General Ledger Posting: The payment is transferred to a P&L account in the General Ledger.
© SAP AG
IHE203
10-28
10. Payments: Post Manual Payments without
Business Partner
© SAP 2008
„
Simple Selection /General Ledger Account Posting
„
The middle area contains two tab pages one for entering selection criteria for the payment.
„
General Ledger Posting: The payment is transferred to a P&L account in the General Ledger.
„
(picture above)
„
G/L postings are basically “departmental deposits”. You can create individual documents and
transfer them to the G/L postings as separate line items (see Short Assignment in the IMG). You can
also enter a tax code, if appropriate.
„
The third part of the screen 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.
© SAP AG
IHE203
10-29
10. Payments: Cash Journal - Post
Deposits/Withdrawals
Hide Header
Deposit
Screen
Withdrawal
Screen
© SAP 2008
„
The screens to post deposits or withdrawals are divided into two areas. You can hide the header
data. The fields required for posting a deposit or a withdrawal 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 or withdrawal with the “reversal of special posting documents” function,
provided this has not already been fully or partially withdrawn.
„
You can select and activate the balances for withdrawals. 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.
© SAP AG
IHE203
10-30
10. Payments: Cash Journal - Post Differences
© SAP 2008
„
The screen to post differences is 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.
© SAP AG
IHE203
10-31
10. Payments: Cash Journal - Payment on
Installment Plan
© SAP 2008
„
If, during the clearing proposal, the allocated open item turns out to be an Installment Plan item, you
can display the Installment Plan and, if necessary, change it during the online processing of the
clearing proposal for clearing the source receivables.
© SAP AG
IHE203
10-32
10. Payments: Post Payments at Cash Desk
and Clear
Process incoming payments “On Account” and clear later
OR
Assign payments to specific open items and clear immediately
© SAP 2008
„
Payments (non-G/L) can be processed “on account” (set OnAcct flag or set as default in
customizing) and later cleared by the automatic clearing run. This approach saves time for the
cashier and enforces institutional clearing rules.
„
On the other hand, your institution may decide to let the customer decide which open item is to be
paid. In this case, the cashier has to mark the appropriate open item(s).
© SAP AG
IHE203
10-33
10. Payments: Cash Journal: Daily Closing
Open Cash Desk
Postings in
Cash Desk
Close Cash
Desk
Cash Desk
Closing
© SAP 2008
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Payments>Cash Journal
„ A typical day at a Cash Desk could look like this:
• Morning: open Cash Desk and compare cash balance to previous day
• Post incoming/outgoing payments
• Go to lunch. Print cash balance and close cash desk
• Return from lunch. Open Cash Desk and compare cash balance
• Post incoming/outgoing payments
• Late afternoon: Perform closing procedures, including:
- Count cash, reconcile it to the cash balance, and post differences if needed
- Total checks and payment cards transactions and reconcile to cash balance
- Complete bank slips and post deposit or withdrawal referring to the paperwork (flag line item)
• Execute Cash Desk Closing which automatically closes the cash desk and the reconciliation key.
„ You can close a Desk without performing the closing procedures, for example, cashier goes for
lunch. After lunch, the cashier would open the Desk again and continue with postings.
„ SAP delivers reports, including:
• Overview of Cash Desk Closing: shows closing carried out across all cash desks and branches
• Cash Journal Evaluations, which displays payment totals and details by tender and Cash Desks
within branches
„
© SAP AG
IHE203
10-34
10. Payments: FSCM Biller Direct The Internet Option
FSCM Biller Direct:
„ Can be found in the component FSCM Supply Chain Management
„ Supports the creation/payment of electronic invoices over the Internet
„ Contains the following functions, among others:
„
Payment of incoming invoices over the Internet and the creation of direct requests and
complaints
„
Maintains the data for the address, credit card and bank details/bank account
„
Generates balance confirmations, payment directives and the monthly display of
balances and individual items.
© SAP 2008
„
SAP FSCM Biller Direct and Contract Accounting are integrated.
„
SAP offers different modes:
- Standard view: Student selects which items to pay
- Balance view: Student does not select, but just enters the payment amount, which could be less
(partial payment) or more (overpayment) than the outstanding debt. This depends on your
configuration. Universities typically do not allow the student a choice.
„
SAP delivers many Events (12xx) to adapt SAP Biller Direct to your institution’s needs. You may
want to code Event 1242 for follow-up processes like removing HOLD when card payments have
been authorized by the card institution.
„
Contract account Customizing is described in the SAP Biller Direct Implementation Guide. There is
also a modification and security guide.
„
If your institution accepts bank transfers in FSCM Biller Direct, it may be appropriate to store the
incoming bank details separately from outgoing bank details. This is possible by using FICA Event
1053.
„
Note: Make sure you use the guides for FI-CA, not FI-AR.
„
Note: Use transaction EBPP to test Biller Direct payments without the web front end.
© SAP AG
IHE203
10-35
10. Payments: Configuration of FSCM in PSCD
Define Customer Contact:
„
Set up Contact Class/Activity (e.g., ZPAY Web Payment)
„
Set up Contact Types (e.g., ISR Payment, Web Payment)
„
Set up Contact Direction (e.g., I for incoming or O for outgoing)
Biller Direct
„
Settings for Customer Portal in the Internet
„
Logging of Activities
„
Notification Settings
„
Default Values for Clearing
„
Specifications for Overpayments
„
Reversing Overpayments
„
Clearing Overpayments
© SAP 2008
„
Customer contacts are configured under the IMG path: Financial Accounting>Contract Accounts
Receivable and Payable>Basic Functions>Customer Contacts.
„
Biller Direct configuration is found under the IMG path: Financial Accounting> Contract Accounts
Receivable and Payable>Integration>Financial Supply Chain Management> Biller Direct.
• For real-time authorization of a payment cards, you need to develop a Function Module to call
your third-party provider and a merchant ID. Read the Biller Direct documentation, especially
Event 1236 for online payment authorizations.
• Appropriate configuration for payment cards exists in cross-application component and PSCD
(see posting area 1120).
„
Note: PSCD and certain Web configurations must correspond. Refer to the Biller Direct
Configuration Guide for FI-CA.
© SAP AG
IHE203
10-36
10. Payments:
FSCM Biller Direct: One Student’s Account
Tuition
Fee
Student
Business
partner
Parking
ticket
PSCD
© SAP 2008
„
Students can be informed about an invoicing by e-mail or SMS.
„
The student accesses their account using the Web browser. They can display the bill and make
payments by payment card or bank transfer.
„
During the web process, the payment method and card number (DFKKOPC) or bank details are
stored on the open items marked for payment.
„
A subsequent payment run will clear the marked open item and produces a payment medium if
appropriate.
„
For further information, see: http://help.sap.com/bp_bblibrary/500/html/W22_EN_DE.htm.
© SAP AG
IHE203
10-37
10. Payments: Payment Program
The following incoming payments/clearances are initiated by the
organization itself:
„ Debit
memo (bank) collection
direct debit
„ Transfer payment (internal clearing)
„ Payment cards
„ Bank
May impact Dunning or Invoicing!!
Before initiating payments, consider:
What is to be paid?
When?
To or from whom?
How?
Through which bank?
Groups the due items
Check, direct debit, credit card
© SAP 2008
„
This section provides an overview of the payment program:
„
IMG path: Financial Accounting>Contract Accounts Receivable and Payable>Business
Transactions>Payments>Incoming/Outgoing Payment Creation
„
There are several types of payments, initiated by the organization itself, that are available for use
within PSCD. These payment methods are generally used in association with the payment program.
„
For direct debit, often country-specific legal requirements apply. For further information, please see
the online documentation and release notes in the Service Market Place.
„
Note: If an incoming payment method is valid (not locked), then it is the university’s responsibility
to collect the money. For this reason the Dunning Proposal does not include open items of this kind.
© SAP AG
IHE203
10-38
10. Payments: Payment Method Configuration
Configuration is performed in two steps:
1. Definition of the Payment Method itself
Payment method classification
Processing type (Bank Account, Payment Card, Internal Clearing)
Required master record specifications
Payment medium format
Company Code area (Document Type, Clearing Reason, and Note To Payee
Category)
2. Specifications for Company Code
Assignment to company code
© SAP 2008
„
Through the use of the payment method, it is possible to ensure that marked items are processed
separately from unmarked items. The payment method in the document is not checked against the
payment methods defined in the contract account. In addition, by entering a payment method in an
item it is possible to ensure that any minimum/maximum amount limits valid for this payment
method 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 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.
© SAP AG
IHE203
10-39
10. Payments: Payment Program Control Data
- Master Data
© SAP 2008
„
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.
„
To use payment data that is set at the contract object level, Payment parameters on the contract
object active must be set.
© SAP AG
IHE203
10-40
Posting Document
10. Payments: Payment Control Data:
Line Item
Payment method
Payment locks
Alternative payer/payee
Override data in contract
account/contract object
Due date for net payment
Deferral date
Due date for cash discount
Grouping
Can Only Be Cleared
Item category (from main/sub transaction)
Payment and Clearing Locks
© SAP 2008
„
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.
© SAP AG
IHE203
10-41
10. Payments: Payment Program Process
Overview
Contract
object
Payment run
parameters
Customizing
Contract
account
Documents
Business
partner
Test run *
Payment run *
Payment data
and exceptions
Payment document
View payment list
Clarification list for
payment exceptions
Create payment medium
check
Euroscheck
Payment
advice
accompanying
sheet
* parallel processing !
© SAP 2008
„
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.
„
If desired, a test run of the payment program can be executed prior to the actual payment run. The
test run creates a payment list, but 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. They cannot be changed.
„
From the payment data, payment media are created. Payment media can be created in electronic
form (bank transfer) or in hard copy (paper check).
„
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, and current
payment run parameters.
© SAP AG
IHE203
10-42
10. Payments: Payment Program: Program
Flow
.
.
Next partner
.
Next interval
Reserve intervals
.
Dispatcher for
payment program
Read items for partner
Group items
Read contract account
Check payment blocks
Read business partner
Determine payment method/bank
Post payment document
Update payment data
Confirm intervals
© SAP 2008
„
Parallel processing distributes the load across several machines to improve performance. By
choosing suitable sizes for the selected blocks, more rapid access is possible and less memory is
required to process the data.
„
Parallel processing is achieved by apportioning the data set to be processed. The business partner, or
the combination of business partner and contract account, are suitable interval objects for parallel
processing.
„
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 that is not yet in operation. The
worklist 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.
© SAP AG
IHE203
10-43
10. Payments: Events in the Payment Program
.
.
Next partner
.
Next interval
Reserve intervals
.
Read items for partner
Group items
Read contract account
Check payment blocks
Read business partner
Determine payment method/bank
Post payment document
Update payment data
Confirm intervals
© SAP 2008
„
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 using the documentation for the associated example
Function Modules FKK_SAMPLE_06xx.
„
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
© SAP AG
IHE203
10-44
10. Payments: Payment Program Runtime
Parameters
Run Parameters
- Company codes
- Business partners
- Contract accounts
- Payment method
priority list
- Payment Card Type
- Posting parameters
- Due date interval
- Selection of banks
- Dynamic selections
- Technical settings
- Simulation run?
Posting date
Reconciliation key
© SAP 2008
„
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, and so on) if she is authorized
for this activity and she 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. This allows for a lot of flexibility. For example, you could
decide to select only financial aid items for payment.
„
Selection according to company code is mandatory. The defined payment method is countryspecific. For this reason it is only possible to select company codes within a country that has the
same currency in each payment run.
„
The posting date of the payment run is applied as the baseline date for determining the due date,
except:
• 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, the due date for net payment is used.
Note: 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.
© SAP AG
IHE203
10-45
10. Payments: Grouping of Open Items to Be
Paid
„
„
„
„
„
„
„
„
„
„
Business Partner
Alternative Payer
Payer’s Bank Details
Responsible Company Code
Contract Account by which payment transactions are made offset
Payment Lock
Payment Method
Currency Key
Grouping Term from Open Item
Free Grouping of Application Area
© SAP 2008
„
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.
„
The grouping term corresponds to field “Custom group” in document items.
„
Free grouping is an additional way to define groups of data which should be handled by the payment
run in a different way. This grouping field overwrites the customer key.
© SAP AG
IHE203
10-46
10. Payments: Determination of Payment
Method and Banks
Validation of payment methods defined in the contract account, contract object, or
document
Copy business partner bank from contract account, contract object, or document (if the
payment method requires bank details)
Select house bank per payment method (if necessary, taking into account payment
optimization)
© SAP 2008
„
Several payment methods can be specified for outgoing payments in a contract account or contracts
object’s master data. In this case, the checks outlined in the steps 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.
© SAP AG
IHE203
10-47
10. Payments: Run Parameters: Selection of
Banks
Respons. co code Payment method Currency House bank Account ID Ranking order
P001
S
EUR
DRE
GIRO
1
P001
S
EUR
DB
GIRO
2
P001
U
DB
GIRO
1
P001
U
DRE
GIRO
2
2
© SAP 2008
„
The payment program is 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.
„
It is only possible to prioritize banks for bank selection optimization. It is not possible to enter
available amounts for each of the respective bank accounts.
„
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 clearing account in the responsible
company code first. This procedure is the same for outgoing payments.
© SAP AG
IHE203
10-48
10. Payments: Example: Item Grouping (1)
Payment
Contract account
B. Partner 100000
1000000
125
4
200
Account 1000000
Account category : ST (Student Account)
Payment method: 01
329
FI-CA
FI
Clearing Account (bank)
163000
Contract
Contractobject:
object:Meals
Meals
Receivable:
Receivable:125
125++44
Contract
Contractobject:
object:Housing
Housing
Receivable:
Receivable:200
200
329
© SAP 2008
„
Payment Method 01 on the Contract Account is inherited by both Contract Objects. Therefore, the
items can be grouped together
© SAP AG
IHE203
10-49
10. Payments: Example: Item Grouping (2)
Payment
Contract account
B. Partner 100001
1000001
125
4
200
Account 1000001
129
200
FI-CA
Account category : ST (Student Account)
Payment method: 01
FI
Clearing Account (bank)
Contract
Contractobject:
object:Meals
Meals
Receivable:
Receivable:125
125++44
Contract
Contractobject:
object:Housing
Housing
Payment
method:
Payment method:02
02
Receivable:
Receivable:200
200
163nnn
129
200
© SAP 2008
„
Payment Method 01 on the Contract Account is inherited by the Contract Object “Meals.”
However, Contract Object “Housing” has Payment Method 02. Therefore, the two “Meals” items are
grouped but the “Housing” item is considered separately.
© SAP AG
IHE203
10-50
10. Payments: Payment List
Payment data list
BusPartner Payee name
Cty City
Street
Cont. acct
Bank number
Payee acct no.
Doc. no.
CoCd P House Acct
Cash disc.
Amount paid Curr.
Doc. no.
Main SubT Doc. Date Due date Dis % Amount FC clearing amount Curr. Ind. PBk Contract
0000000407 Last Name Field on
US
House number on Sta
000003509000
Exception
V001
00000200133
11/12/1998 11/12/1998 0.00
1,000.00
1,000.00
00000200133
11/12/1998 11/12/1998 0.00
150.00
150.00
USD
USD
6
6
11-280011000
0000000407 Last Name Field on
US
House number on Sta
000003509000
Exception
V001
00000200133
11/12/1998 11/12/1998 0.00
75.00
75.00
00000200133
11/12/1998 11/12/1998 0.00
500.00
500.00
USD
USD
6
6
11-58001000
11-58001000
0000000407 Last Name Field on
US
House number on Sta
000003509000
Exception
V001
00000300017
11/12/1998 11/12/1998 0.00
500.00500.00- USD
16
15-78001000
Payment exception
Item indicator
contains the key
for the reason for
the exception
© SAP 2008
„
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.
© SAP AG
IHE203
10-51
10. Payments: Additional Features of Payment
Program
Application log
„
Records all activities
Log
Additional log
„
Activated in the parameters for the payment run
„
In live systems, it is possible to limit the log to individual business partners/contract
accounts (to analyze user errors)
Copy template (defined in Customizing)
Deletion of payment run
© SAP 2008
„
The application log gives information about what activity (changing parameters, scheduling,
deleting data) has been carried out, by whom, and when.
„
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 payment. The
user can define what is to be logged.
„
The copy template contains predefined parameters and may be used to create a payment run, but the
template itself cannot be executed as a payment run. In addition, 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.
© SAP AG
IHE203
10-52
10. Payments: Creation of Payment Medium
Modular structure of the payment medium program
„
Purpose: Faster implementation of new formats, e.g. EBPP
Grouping of payments to payment media
„
Purpose: Parallel Processing
„
Payments are grouped depending on format of payment medium
„
Possible grouping fields: payment medium format, company code, house bank and
account, debit/credit memo
Flexible structuring of note to payee
„
With symbols (SAPscript syntax)
„
With application/customer-specific function module
© SAP 2008
„
In contrast to the payment program, payment media cannot be created simultaneously using business
partner or contract account objects; rather, a process must be started for each payment medium,
taking into account the country-specific requirements.
„
The structure of the note to payee is adjustable 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 or 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
business partner data (FPP1, FPP2) on the Payment Transactions tab in the Bank Chains area. The
FI_PAYMENT_BANK_CHAIN_SET Function Module determines the bank chains during payment
media creation and places them in the corresponding structures.
© SAP AG
IHE203
10-53
10. Payments: Note to Payee Content Hint
Payment method
Note to payee type
# of information
lines
# of item text lines
Function modules
Note to payee structure
Customizing
Customizing for
for note
note to
to payee:
payee: content
content
Language Notification type Line number Note to payee
E
1
01
Contract &PAYP-VTREF&
E
1
02
Amount &PAYH-WAERS(C)& &PAYP-AUGBW(C)&
E
…
1
03
Your Account &PAYH-ACC1R&
…
…….
© SAP 2008
„
You can specify that payment media are to be created in the business partner’s language. If this flag
is not set, 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 code SE38, enter program ID
SAPFKPY3, and choose Execute. Text in recipient’s language is the flag to look for.
„
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 item content (FQP5 Æ Note to Payee: Content), the sequence (item number)
decides whether the content is prepared per payment or per item. If, for example, you have specified
two information items per payment and one information item per item, you have to provide a total of
three items 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 item is then repeated for each item.
The fields from the structure PAYP are useful here.
„
Note: Before you create a payment media, you must define a variant: SE38, SAPFKPY3 →
Maintain variant.
„
In the variant, you define the appropriate format for the payment media, print parameters and file
directories to store the records for the bank produced by the payment run.
© SAP AG
IHE203
10-54
10. Payments: Outgoing Checks - Overview
X
0
Credit
Replacement
Accounting dep.
"
Made and/or
void checks
Field service
House
Bank
Bank
Customer
Check cashing
Check deposit
Check creation
X
© SAP 2008
„
This gives an overview of Check Management
„
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Payments>Checks>Check Management
„
IMG:path: Financial Accounting>Contract Accounts Receivable and Payable>Basic Functions>
Check Management
„
A check can have the following status:
• Open
• Cashed
• Invalid
• Locked
„
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 (Check Extract for Report Files). 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 (Document Reversal after Check Lock) 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 U.S. customers and is known by the name “stop payment.” It is an alternative to the previous
method 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.
© SAP AG
IHE203
10-55
10. Payments: Outgoing Check Management
Checks can be issued by the payment program and printed later
Checks can be issued online and printed immediately
Check processing/management
„
Checks with external number assignment (check number is already pre-printed on
the check)
„
Checks with internal number assignment (without any gaps)
„
Checks with automatic number assignment (check number is the same as the
payment document number)
© SAP 2008
„
Application Form FI_CA_DME_CHECK_SAMPLE serves as a template for a check form with an
accompanying letter. You can adapt it to fit your institution’s branding, for example, add a logo.
„
Check number management influences the reconciliation process:
• In FI-GL, reconciliation is performed in a check clearing account that is managed on an openitem basis. Checks with automatic assignment of check number (payment document number =
check number) are reconciled automatically.
• If you use the internal and external check number assignment, that is, the payment document
number and check number are different, you must carry out the reconciliation in FI-CA.
„
To facilitate reconciliation of checks in FI, transfer each payment document separately to the
General Ledger and implement Event 940 which allows the institution to use something meaningful
in the assignment field, the reference key and the item text.
„
Some institutions require to report issued checks as a file (a.k.a. Positive Payment File
RFKKCHK01) to the bank to allow encashment. See also Transaction FPCHR (Check
Management) and select menu path: >GoTo>Create Report File. The file layout may have to be
adjusted to your house bank’s requirements.
„
If your house bank sends encashment data in an electronic file, you can load the information into FICA using Transaction FPB12/Report RFKKCR00 (Transfer of Cashed Checks). The file layout
may have to be adjusted to your house bank’s requirements.
„
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 check printing indicator must be set.
When you set the indicator, the applicable clearing account must be used in online check printing.
© SAP AG
IHE203
10-56
10. Payments: Outgoing Check Management
There are
many ways
to select
check data.
© SAP 2008
„
It is possible to store the check image and link it to the payment document if your institution has
implemented Optical Archiving.
„
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.
„
Check Management offers the following features:
• You have 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 and save additional recipient information separately.
© SAP AG
IHE203
10-57
10. Payments: Payment Cards - Direct Debit
Process
© SAP 2008
„
When a customer uses a payment card to pay for goods or services, 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 receivables account (reporting account).
„
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.
„
Payment card authorization can be done online using third-party software.
„
SAP offers a number of events (14xx) dealing with payment card processes.
„
SAP also provides several transactions to assist payment card processing:
„
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing>Data for Externals>Payment Card Organizations
„
Note: The process described above is somewhat different at US universities.
© SAP AG
IHE203
10-58
10. Payment: Payment Card Formats
No payment medium print format due to:
„
Card formats/cards not standardized like bank formats/country
„
Simultaneous processing for online clearing and payment program (payment medium
formats valid for one payment run only)
A file is created that customers can add to and send (after mapping)
„
File: BFKKOPKH, event 1410
„
Data for payment: BFKKOPKC, event 1411
„
Data on paid item: BFKKOPKD, event 1412
„
Summary data: BFKKOPKS, BFKKOPKSI
© SAP 2008
© SAP AG
IHE203
10-59
10. Payments: Unit Summary
You should now be able to:
„
Differentiate between incoming and outgoing payment transactions that are
initiated by the public sector organization
„
Set up payments and check lots
„
Post manual payments using cash journal
„
Describe payment program and payment card processing
„
Categorize payment control data as pertaining to customizing, master data,
or posting data
„
Discuss generation of payment media
© SAP 2008
© SAP AG
IHE203
10-60
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP 2008
© SAP AG
IHE203
11-1
11. Clearing and Account Maintenance
Contents
„
Clearing Definition and Concepts
„
Automatic versus Manual Clearing
„
Open Item Processing
„
Clearing of Payments
„
Account Maintenance
© SAP 2008
© SAP AG
IHE203
11-2
11. Clearing and Account Maintenance:
Unit Objectives
At the conclusion of this unit, you will be able to:
„
Discuss clearing concepts
„
Distinguish between account maintenance and direct open-item processing
„
Analyze automatic versus manual clearing control
„
Configure and list automatic clearing controls at contract account and lineitem levels
„
Create manual payment postings that clear open items
© SAP 2008
© SAP AG
IHE203
11-3
11. Clearing and Account Maintenance:
Business Scenario
„
The student makes a payment to clear outstanding fees.
„
The institution has disbursed financial aid. The aid is used to clear unpaid
fees.
© SAP 2008
„
Every open item must be cleared at some point. There are different procedures to enable you to clear
items. The most frequent are:
• Externally initiated: The student clears the item by paying the fees.
• Internally initiated: Receivables Ttuition & Fee) and Payables (financial aid) are cleared against
each other.
„
Since these clearing processes are normally mass processes, the system must be to determine
automatically the payment usage or to create automatically the clearing proposal based on
predefined rules.
© SAP AG
IHE203
11-4
11. Clearing and Account Maintenance:
Clearing Control: Considerations
Before you define the clearing process, consider the following:
Which criteria determine item(s) to be paid first?
Oldest due date, payments for certain purposes
Which items do I want to exclude from clearing (if any)?
Additional receivables
Partial / over payments allowed?
Write off tolerances?
99% or 1 USD
Must amounts match before clearing is allowed?
Do I clear different types of payment transactions differently?
Do I want to control the payments made on account (clarification)?
© SAP 2008
„
PSCD clearing control is used by the system to determine how items on an account are selected and
cleared.
„
Clearing control includes rules for under and overpayments, how far in advance to look for open
receivables if a credit exists, and how to post amounts when a corresponding item cannot be found
(on account, to clarification, and so on).
„
Clearing control is based on selection rules (determine what is cleared) and clearing variants (define
how clearing is carried out).
„
With the exception of the clearing category table, the clearing control settings are industry-specific.
Since the clearing types are allocate to the standard processes and supplied by SAP, every
application area is responsible for maintaining and supplying their standard settings.
„
In the specifications for clearing types, you can configure the determination of clearing variants,
selection restrictions, information on payments on account, as well as the control for writing off
statistical items.
© SAP AG
IHE203
11-5
11. Clearing and Account Maintenance:
Clearing Control - Definitions
© SAP 2008
„
Clearing Control: Definition
„
The PSCD 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.
„
The clearing category is optional (it can be used for individual clearing rules at contract account
level). If you do not assign a clearing category, the system uses the clearing variant.
„
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).
© SAP AG
IHE203
11-6
11. Clearing and Account Maintenance:
Clearing Control: Clearing Types
© SAP 2008
„
Clearing types are hard-coded in the system.
„
Clearing types are structured according to their areas of use (for example, incoming payment,
account maintenance).
„
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.
„
Clearing type 06 (payment run) is only used in clearing control if you have defined a special
payment group. If you did not enhance the payment program (payment run), the payment program
does not use clearing control.
„
The clearing control parameters are defined in Customizing. Use MG path: Financial
Accounting>Contract Accounts Receivable & Payable>Basic Functions>Open Item
Management>Clearing Control
© SAP AG
IHE203
11-7
11. Clearing Types:
Defaults for Incoming Payments
Clearing type ‘05’ (payment lots)
11
Clearing variant
IMG
Non-assignable payment handling
Do not post on account (‘ ‘)
Post on account if contract account can be
explicitly determined (‘1’)
Post on account (‘2’)
22
Alternative clearing variant
33
Selection criteria
44
Write off statistical items; which and when?
55
Control data: payment on account; amount controls
66
Program enhancements
© SAP 2008
„
For each clearing category, you can have one “alternative” clearing variant. The clearing category
can be assigned to the contract account.
„
For each incoming payment it is possible to set parameters defining how to handle payments which
are not directly assigned to open items. For example, you could default to post the incoming
payment always on account rather than clearing it immediately. That creates a separate payment
document which might be easier to understand for the accounting staff than immediate clearing.
„
Program enhancements allow for the use of customer function modules, e.g. for the selection of
open-items or how statistical items should be written off.
© SAP AG
IHE203
11-8
11. Clearing and Account Maintenance:
Clearing Control - Example: Incoming Payment
© SAP 2008
„
A student makes a payment without specifying the payment usage.
„
Payment must be assigned automatically according to a strategy set up in the system. The system
checks the due date of an item or an item group. It also has to check whether the paid amount
corresponds exactly to a receivable. Only then can the payment be assigned.
© SAP AG
IHE203
11-9
11. Clearing and Account Maintenance:
Clearing Control: Integration
© SAP 2008
„
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.
„
Clearing Control is used:
• To generate a clearing proposal during payment allocation 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
(MFKK_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 in 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).
© SAP AG
IHE203
11-10
11. Clearing and Account Maintenance:
Clearing Control: Clearing Variant
© SAP 2008
„
PSCD clearing control is used by the system to determine how items on an account are selected and
cleared. It includes rules for under and overpayments, how far in advance to look for open
receivables if a credit exists, and how to post amounts where a corresponding item could not be
found (on account, to clarification, and so on).
„
A clearing variant contains several steps. The individual steps control the selection, grouping,
sorting, and amount-dependent assignment of the open items for clearing. The steps are executed in
the sorting sequence of their numbers, you can, however, call them up directly according to each
clearing rule.
„
The individual clearing steps inherit the clearing proposal and the remaining open amount from the
previous steps.
„
Items that are completely cleared in a clearing step are not included in subsequent steps.
© SAP AG
IHE203
11-11
11. Clearing and Account Maintenance:
Clearing Control: Characteristics
© SAP 2008
„
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 period is specified on
payment).
„
Characteristics are used in:
• 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
© SAP AG
IHE203
11-12
11. Clearing and Account Maintenance:
Clearing Control: Clearing Steps
© SAP 2008
„
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 characteristic value for the individual values of a grouping
characteristic. Examples: Combine two attributes of a characteristic into one group (company code
0001 = company code 0002); exclude certain characteristic values (from the clearing analysis in the
current clearing step or generally); restrict the clearing analysis to certain values (such as company
code 0001 only).
„
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. For example, if items are grouped according to company code and sorted according to due
date, the group (company code) that contains the item with the oldest due date has the first place in
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).
© SAP AG
IHE203
11-13
11. Clearing and Account Maintenance:
Clearing Control: Grouping Characteristics
© SAP 2008
„
The above picture shows an example of how the clearing control works for grouping original
characteristics.
„
Grouping characteristics can be attributes in Table FKKOP or can be specifically derived in a
Function Module (use customer name space).
© SAP AG
IHE203
11-14
11. Clearing and Account Maintenance:
Clearing Control: Sorting Characteristics
© SAP 2008
„
The above picture shows an example of how the clearing control works for sorting original
characteristics.
„
Sorting is generally used when an institution has its own self-defined priority for items.
© SAP AG
IHE203
11-15
11. Clearing and Account Maintenance:
Clearing Control: Sorting Within Groups
© SAP 2008
„
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.
„
Ranking within the sorting string is comparable to alternative grouping within the grouping string.
© SAP AG
IHE203
11-16
11. Clearing and Account Maintenance:
Clearing Control: Sorting String
© SAP 2008
„
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.
© SAP AG
IHE203
11-17
11. Clearing and Account Maintenance:
Clearing Control: Group Rules
© SAP 2008
„
Group tules 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 mount 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 items 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.
© SAP AG
IHE203
11-18
11. Clearing and Account Maintenance:
Clearing Control: Amount Check Groups
© SAP 2008
„
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.
© SAP AG
IHE203
11-19
11. Clearing and Account Maintenance:
Clearing Control: Minimum Amount Clearing (Tolerance Group)
le
ra
nc
e
to
W
ith
in
Minimum amount limit
>3
(tolerance group ‘001’
3 or 1% of open item)
IMG
Open item
(receivable)
273
Incoming payment
270
No
tw
Minimum amount limit
<3
Receivable for 273 is
cleared
Special expense account
in general ledger
Debit posting: 3
ith
in
AND
Partial clearing of
open item
270 (sub-item 1)
partial clearing allowed in
the clearing variant
Remaining open item
3.00 (sub-item 0)
© SAP 2008
„
You can enter the tolerance group in the contract account master data specifications. The tolerance
specifications (currency, expense, and revenue -- both as absolute amount and a percentage) are
stored in Customizing under Maintain Tolerance Groups in the Open-Item Management section of
the IMG.
„
You can specify that you wish a payment notice (Correspondence Type 0019) to be automatically
generated when either an under or overpayment has been posted, respectively. These settings are
made in Customizing for the Tolerance Group.
© SAP AG
IHE203
11-20
11. Clearing and Account Maintenance:
Clearing Control: Special Features
© SAP 2008
© SAP AG
IHE203
11-21
11. Clearing and Account Maintenance:
Clearing Control: Clearing Strategies (1)
© SAP 2008
© SAP AG
IHE203
11-22
11. Clearing and Account Maintenance:
Clearing Control: Clearing Strategies (2)
© SAP 2008
© SAP AG
IHE203
11-23
11. Clearing and Account Maintenance:
Clearing Control: How Can I Test It?
© SAP 2008
© SAP AG
IHE203
11-24
11. Clearing and Account Maintenance:
Account Maintenance
Account maintenance
Account maintenance is the process of clearing (or partially clearing) debit and credit entries
that have been posted to a contract account.
Account maintenance may be performed manually or automatically.
© SAP 2008
© SAP AG
IHE203
11-25
11. Clearing and Account Maintenance:
Account Maintenance: Process
Business partner: 1740
Contract accounts: 410 & 420
Select open Items
Clearing proposal: BP 1740
Enter clearing amounts
Items cleared
150
410
150
50
420
50
200
200
Difference 0.00
© SAP 2008
„
If Open Items exist in an account on the debit (invoices) and on the credit (payments on account,
credit memo) sides, you can clear or partially clear these items using account maintenance.
„
The clearing proposal uses the setting of clearing control for account maintenance. Items allocated
to proposals are already activated, but you can change the results by deactivating them in (manual)
account maintenance. If you work without a proposal, you have to manually activate the items that
you want to be cleared against each other.
„
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Account>Maintain (FP06).
© SAP AG
IHE203
11-26
11. Clearing and Account Maintenance:
Example of Account Maintenance
Open Items
Clearing
A1
A1
20
50
20
50
70
A2
10
23
A2
30
Sub-item
(partial clearing)
10
20
3
A3
30
70
30
A3
30
35
30
5
Sub-item
(overpayment)
© SAP 2008
„
You can select open items in the initial screen for account maintenance. In the processing screen,
you can change or add items to this selection, as well as include other contract accounts or business
partners.
„
Items allocated to the proposal from clearing control are already active. However, you can change
the allocation and ignore the proposal.
© SAP AG
IHE203
11-27
11. Clearing and Account Maintenance:
Manual Account Maintenance - View 1: Clear
© SAP 2008
„
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.
© SAP AG
IHE203
11-28
11. Clearing and Account Maintenance:
Manual Account Maintenance - View 2: Change
© SAP 2008
„
In account maintenance you can perform document changes as well as carry out clearing. You can
switch between both processing views in the transaction.
„
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.
„
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 not 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”.
© SAP AG
IHE203
11-29
11. Clearing and Account Maintenance:
Manual Account Maintenance: Transfer Posting
Account maintenance: process open items
Business Partner
Contract Account
Document
Due
Gross amount
Gross clearing
400000131
20000000000
40000016
01.02.2005
203.00
203.00
400000131
20000000000
30000001
01.04.2006
-199.00
-199.00
Processing status
Difference
Tfr Posting Amt.
0.00
EUR
4.00
Tfr Pstg To
SAP
© SAP 2008
„
In account maintenance, you can transfer difference amounts to a G/L account defined in
customizing. You have to specify the amount to be posted and, similar to the payment lot, a short
account assignment that the system can use to determine the Company Code, Account, Business
Area, and CO account assignments.
„
You cannot transfer to tax-relevant accounts.
© SAP AG
IHE203
11-30
11. Clearing and Account Maintenance:
Automatic Clearing Run
Automatic Clearing
Selection parameters
Date ID
Identification
Since clearing every single account
can be time consuming, you can
preselect a subset of contract
accounts. In this procedure, only
accounts in which offsetting items
were posted are selected.
General selections
Company code
Business partner
Contract account
Net due date
Posting parameters
Reconciliation key
Authorization
Authorization group
© SAP 2008
„
A program is provided for automatic clearing of contract accounts. The assignment of open items is
carried out according to rules defined in customizing.
„
You maintain parameters/rules for automatic clearing (predefined values for document type and
clearing reason) in customizing under the IMG path: Financial Accounting>Contract Accounts
Receivable and Payable>Basic Functions>Open Item Management>Define Default Values for
Automatic Clearing.
„
Additional “exception” parameters exist in automatic account maintenance for the handling of
certain exceptions
„
An automatic clearing run can be run in parallel mode for high volume processing.
„
Easy Access Menu: Accounting>Financial Accounting>Contract Accounts Receivable and
Payable>Periodic Processing>For Contract Accounts>Automatic Clearing (FPMA).
© SAP AG
IHE203
11-31
11. Clearing and Account Maintenance: Manual
Posting with Clearing - Open Item Selection Conditions
Enter selection criteria
Standard selections
Business partner
And
Or
Contract account
Contract
Payment form number
Payment form reference
Document number
Reference document no.
Net due date
Selection by payment notice
Payment advice note
Company
Company code
code
Or
„
Selection conditions
are used to determine
and select only those
open items (OI) that
you wish to clear.
„
The available
selection conditions
depend on the type of
incoming payment
processing.
Clearing
Clearing proposal
proposal
Create proposal
© SAP 2008
„
Open items to be cleared may belong to a:
• Business partner
• Contract account (usually second criteria)
• Contract object
• Company code
• Applied period (this is may be the first criteria in public sector organizations)
• Due date
„
On the resulting screen (after system has searched and found items that match search criteria entered
on the screen shown above), it is possible to perform a refined search. Simply place the cursor on the
field (within a column) that you wish to use for refinement and then choose::
• Edit Æ Find. You will be prompted to enter the value(s) for which you wish to search.
• For example, if you have an idea as to the amount that you are looking for, place the cursor on
the “Amount” field and then choose Edit Æ Find and enter the amount range. This type of search
can be refined a second or third time.
© SAP AG
IHE203
11-32
11. Clearing and Account Maintenance:
Manual Posting with Clearing: Display
Post document: Display
Document posting: Process Open Items Command column
Partner
Account Contract
x Suppressed
Summarization
Switched off
x Switched on
Invoice amount
x Gross
Net
Clearing amount
x Gross
Net
Displayed
Doc. No.
MUSTERFRAU 0000000003 11-RBZMUSTERFR
000001000
MUSTERFRAU 0000000003 11-RBZMUSTERFR
000001000
MUSTERFRAU 0000000003 11-RBZMUSTERFR
000001000
Editing Status
Number of items
3
Amount entered
Display from item
1
Assigned
Display currency
x Transaction currency
Difference
Local currency
Line layout
Cash discount fields
© SAP 2008
„
In addition to standard display options, you can use create line layouts in customizing to configure
the display of fields.
© SAP AG
IHE203
11-33
11. Clearing and Account Maintenance:
Example of Manual Posting with Clearing Display Options
Document posting: Process Open Items
Partner
Account Contract
Doc. No.
USD Gross
000001000
581
581
MUSTERFRAU 0000000003 11-RBZMUSTERFR
000001000
693
693
MUSTERFRAU 0000000003 11-RBZMUSTERFR
000001000
697
697
Display from item
3
1
Amount entered
Assigned
Difference
If no specifications
exist, the open
items are cleared
by due date and
age.
„
Overpayments,
as well as partial
payments, are
processed at this
point.
Gross clearing
MUSTERFRAU 0000000003 11-RBZMUSTERFR
Number of items
„
1971
1971-
© SAP 2008
„
By double-clicking on the fields in the USD Gross (or any currency) 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.
„
The amount entered may be insufficient to clear all the activated open items completely. By doubleclicking in a field in the Gross clearing column, partial clearing of the open item is proposed for the
amount that is not yet assigned. You can change this default value manually. Alternately, you can
enter individual amounts in the fields in the Gross clearing column.
„
By putting a check mark in the box at the beginning of the line, you can select multiple open items
for activation or deactivation as a group (this is also possible from the menu, function keys, or line
commands).
© SAP AG
IHE203
11-34
11. Clearing and Account Maintenance:
Unit Summary
You should now be able to:
„
Discuss clearing concepts
„
Distinguish between account maintenance and direct open-item processing
„
Analyze automatic versus manual clearing control
„
Configure and list automatic clearing controls at contract account and lineitem levels
„
Create manual payment postings that clear open items
© SAP 2008
© SAP AG
IHE203
11-35
© SAP AG
IHE203
11-36
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP 2008
© SAP AG
IHE203
12-1
12. Dunning and Collections
Contents
„
Dunning Terminology: Definition of Dunning Activities, Procedures, Levels,
and their respective uses
„
Dunning Process: Dunning Proposal and Dunning Run
„
Additional Dunning Activities
„
Collection Agency Management
© SAP 2008
© SAP AG
IHE203
12-2
12. Dunning and Collections: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Discuss the dunning requirements of your institution
„
Explain the dunning terminology
„
Configure a dunning procedure with dunning levels, charges, and activities
„
Execute a dunning proposal, print, and perform an activity run
„
Analyze the dunning history
„
Explain functions related to collection agencies and write-off
© SAP 2008
© SAP AG
IHE203
12-3
12. Dunning and Collections:
Business Scenario
„
Some students are slow in paying their debts. Your institution wants to send
reminders to these students regarding their outstanding balances.
© SAP 2008
© SAP AG
IHE203
12-4
12. Dunning Procedure: Definition
A Business Partner (Student, Sponsor) is dunned for:
„
Overdue receivables
Tuition Fees, Library Fines, Parking Tickets
„
Additional receivables
Service Charges, Interest (if explicitly defined as such)
The Dunning Procedure determines:
„
The conditions under which a Business Partner is to be dunned
„
What has to be done in this case
© SAP 2008
„
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. However, many institutions treat them just like normal
(main) receivable.
„
An item not marked as additional receivable in its transaction attributes (a main receivable) can be
subject to interest calculation or trigger dunning if no blocks are set.
© SAP AG
IHE203
12-5
12. Dunning and Collections:
Questions to determine Procedure
Before defining the Dunning Process ask some basic questions:
Do you have different requirements for different customers?
dunning procedures
=
How often do want to you dun?
= dunning levels
What do you want to do? Do you send a reminder letter, charge a penalty, set a hold, or hand the receivables over to a collection agency?
= dunning activities
What are your dunning conditions?
„
Prerequisites
minimum amount, number of days in arrears
„
Action
dunning notice, cancellation of agreements
„
Dunning Charge
fixed, staggered, or scaled charge
© SAP 2008
„
The structure of a dunning procedure is very individual and depends on the business requirements of
your institution and relevant legal conditions.
„
Your institution may require different dunning procedures for different customer accounts, for
example, one procedure for students and another for sponsors.
„
A dunning procedure is made up of separate dunning levels that either run in sequence, or can be set
manually. 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.
„
The different dunning levels contain all necessary information to control the dunning process flow.
„
One of the most frequently used dunning activities is the creation of a dunning notice.
© SAP AG
IHE203
12-6
12. Dunning and Collections:
Example of Levels
Dunning Procedure:
Dunning Level 1 (14 days after net due date, dunning letter)
Dunning Level 2 (30 days after net due date, dunning letter with charges)
Dunning Level 3 (40 days after net due date, dunning letter with legal actions)
Contract account 1
1
Due Jan 01
2
Due Feb 01
3
Due Mar 01
4
Due Apr 01
Run Jan 15
Run Feb 15
Run March 15
© SAP 2008
„
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;
each item may or may not have a different dunning procedure.
„
The grouping type enables you to use criteria that dictate separate dunning notices for certain items.
The grouping type enables you to use other desired criteria (such as the period key) in addition to the
standard criteria (dunning procedure, currency, main company code).
„
In customizing, you default the dunning procedure for a contract account category. This means that
all contract accounts of the same type (mostly, the same revenue, “Contract account 1,“ for example)
are dunned according to the same dunning procedure.
„
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).
© SAP AG
IHE203
12-7
12. Dunning and Collections:
Dunning Configuration
Dunning procedure category
IMG
Dunning procedure
1:n
Dunning level category
Dunning level(s)
Dunning
requirements
1:n
Dunning activity(s)
Charge schedule
Dunning charge
© SAP 2008
„
The dunning procedure is the driver for dunning.
„
It is defined in customizing and you can define different dunning levels for each dunning procedure.
They determine the dunning interval, the grace periods for the due date determination, 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.’
„
Before defining several dunning procedures and forms, you should check whether you can fulfil all
your requirements using one dunning procedure and one form.
You should select “Always dunn. notice?” for the last dunning level so that items at this level are
not skipped.
„
You can store the header and footer texts separately for your dunning notices.
„
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.
© SAP AG
IHE203
12-8
12. Dunning and Collections:
Configure Dunning Levels
Change View “FICA Dunning: Dunning Levels Details”
Dunning procedure
30
30
IMG
Dunning level
Minimum number
of days that must
have passed since
due date for net
payment
Can dunning level
be skipped?
33
Dunning level
Dunning level category 04
04
Legal
Legal action
action to
to follow
follow
Selection parameters
35
35
Days in arrears
14
Dunning frequency
14
Always dun
Optional dunning level
Charges
02
02
01
01 Processing charge
02
02 Postage costs
Charge schedule
Payment deadline 14
14
Dunning recipient
Alternate days/arrears
Alternate dunning freq.
Set dunning level
Already dunned
Interest rates
Calculate interest xx
Interest key
02
02
Update key
11
xx Interest before calc.
Print all items
xx
Creditworthiness number
Interest calculation
(Y/N) according to:
- interest keys (as
customized)
- statistical or nonstatistical posting
Target payment
date printed on the
dunning notice
(added to date of
dunning run)
© SAP 2008
„
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. If this indicator is not
set, then only those items due to be dunned are printed (the items that have reached the number of
days in arrears).
„
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. Up to 3 charges can be
applied per charges schedule.
„
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 delivers an example implementation for such a calculation with
Function Module FKK_SPECIALCHARGE_0360. As standard procedure the interest in the
dunning activity run are calculated and posted according to charges.
„
You can restrict the amount of dunning charges, if dunning interest (penalty charges) is charged as
well as dunning charges. SAP provides a sample Function Module:
FKK_SPECIALCHARGE_0360.
© SAP AG
IHE203
12-9
12. Dunning and Collections:
Overview of Dunning Activities
© SAP 2008
„
SAP supplies a number of Function Modules to carry out various activities.
„
After executing the Dunning Activity Run, all performed activities are recorded in the 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.
„
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
Function Module writes a dunning lock reason in the master data.
„
A workflow can be used, for example, to trigger an agent notification.
© SAP AG
IHE203
12-10
12. Dunning and Collections:
Telephone Lists
© SAP 2008
„
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
(Transfer of Telephone List from Dunning Run to Other System). 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 Easy Access Menu using the path:
Accounting>Financial Accounting>Contract Accounts Receivable and Payable> Periodic
Processing -> For Contract Accounts -> Dunning Notice>Telephone List.. In this Transaction, an
agent can flag an item as completed after a successful telephone call with the Business Partner. In
order to record communication with the Business Partner, the clerk can create customer contacts
manually or automatically. In the customizing settings for customer contacts, you must define the
contact configuration for the program context SAPLFKKDUTL.
„
To provide the Business Partner with information, the administrator can branch from the detailed
information in the telephone list to, amongst others, the account balance, objects connected to the
dunning notice and a customer- or industry-specific function that can be implemented at Event 9011.
© SAP AG
IHE203
12-11
12. Dunning and Collections:
Configure Dunning Activities
IMG
Define dunning activities
Activity Description of activity C.
Function module
0005
Deact.Installment plan
01
0006
Print Dunning form
01 FMCA_DUNNING_PR_CORR_CONT_0350
0007
Dunning event
01 FKK_SAMPLE_0350_SBHINWEIS
0008
Set dunning lock
01
Form for correspondence
FMCA_DUNNING_DEACT_INSTPL_0350
ZFMCA_DUNNING_100
FKK_SAMPLE_0350_LOCK_VKONT
You can define your own
function module
© SAP 2008
„
Dunning activities consist of a Function Module (such as FKK_SAMPLE_0350_CCC) and
correspondence form (optional). It is a key representing an activity that is carried out in connection
with the execution of a dunning run.
„
Under Form for Correspondence, you make the link to your various application forms .
„
Any number of dunning activities can be assigned to various dunning levels, for example:
• Print dunning form
• Starting work-flows
• Send note to clerk using SAP Office
• Deactivate installment plan
• Set a dunning lock for the dunned contract account in the dunning run
• Other user-defined activities
„
Users can develop their own Function Modules for standard activities. For example, an activity to
inform an external system (via RFC) to perform a certain action.
© SAP AG
IHE203
12-12
12. Dunning and Collections: Configure
Dunning Activities Specific to SLCM
IMG
Define dunning activities
Activity Description of activity C.
Function module
Form for correspondence
0006
Print Dunning form
01
FMCA_DUNNING_PR_CORR_CONT_0350
ZFMCA_DUNNING_SP
0006
Print Dunning form
01 FMCA_DUNNING_PR_CORR_CONT_0350
ZFMCA_DUNNING_ST
0009
Collection Agency
01 FKK_COLL_AGENCY_RELEASE_0350
ZFH1
Set Financial Hold
01
CMAC_EVENT_0350_SET
Supplied by SAP but you
can define your own
function module
© SAP 2008
„
Your institution may use different letters for students and sponsors. You may also have different
letters based on level. In this case, you define different application forms (correspondence type
0003) and assign them to activity 0006.
„
Your institution may want to prevent a student from booking additional course, i.e. incurring new
charges, if there are still overdue items. In this case, you may define a customer activity, e.g. ZFH1
- Set Financial Hold, which sets a HOLD of a specific type in the student file. (see other course on
Student Lifecycle Management)
„
SAP has supplied Function Module CMAC_EVENT_0350_SET which you have to add to call-up
point 0350 (IMG: Program Enhancements > Event 0350 > institution specific). However, you could
also code your own function modules.
„
To remove the financial hold when a dunning run has been cancelled, you must add Function
Module CMAC_EVENT_HOLD_CANCEL to call-up point 0395.
„
To remove the financial hold when the student makes a payment, you must add
CMAC_EVENT_0020_HOLD_REMOVE to Call-Up Point 0020. For performance reasons, this
applies only to manual postings, e.g. Cash Journal.
„
SAP has also delivered a sample report CMAC_FINANCIAL_HOLD_REMOVE which can be
used to remove holds en mass.
„
For detailed instructions read the IMG documentation under the IMG path: >Student Lifecycle
Management>Student Accounting>Financial Holds
© SAP AG
IHE203
12-13
12. Dunning and Collections: Configuration
Related to Additional Receivables
IMG
Rules for additional receivables
Resp. comp. code Interest Dunning trigger Interest key Dunning balance Dunn. Level
P001
X
X
X
0003
0004
0005
P004
Can an ‘additional
receivable’
alone trigger dunning?
Should an ‘additional
receivable’
be included when determining
the dunning balance?
Consideration with Dunning
Level of Dunning Notice
© SAP 2008
„
If your institution uses “Additional Receivables” then you can assign specific rules to each
combination of main and sub transaction.
„
The maintenance takes place in the IMG 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)
„
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.
© SAP AG
IHE203
12-14
12. Dunning and Collections:
Charge Schedule - Definition
Charge schedule:
Describes how to determine charges for
„
Late Payment Penalties
„
Charges for certain correspondences, e. g. account information
© SAP 2008
© SAP AG
IHE203
12-15
12. Dunning and Collections:
Dunning Terminology - Charges
Charge Schedule
Charge
Category
1
Charge
Category
2
Charge
Category
3
Charging
„
How much do we charge?
„
How do we post the charge
(main and subtransaction)
© SAP 2008
„
A charge schedule can manage the charge data for a maximum of three Charge Categories. These
charge categories can be processing charges, payment document charges, postage charges, or
customer defined charges.
„
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. When you do
this, you also define, which main and sub-transaction is used, to post charges. The combination of
main and sub-transaction itself determines, whether charges are to be posted by the system as
statistical postings or with an update in the general ledger.
„
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.
© SAP AG
IHE203
12-16
12. Dunning and Collections:
Charge Calculation
You can calculate the charge as
Absolute amount
percentage of the dunning
balance
staggered amounts
percentage with minimum
and/or maximum limit
© SAP 2008
„
You can levy dunning charges as absolute charges, or as percentage charges. Percentage charges
refer to the dunning balance.
© SAP AG
IHE203
12-17
12. Dunning and Collections:
Interest Calculation
Interest Calculation for Dunning is determined by
„
Specifications for Interest on Arrears
„
„
(Document Type, Definition of the Interest Calculation Rule, Interest
Key, Etc. )
Dunning Level
„
(if interest is calculated at all, Interest Key, Update)
© SAP 2008
„
If you want to use interest calculation for dunning, you have to set-up the customizing for interest
calculation in general and you have to configure each dunning level concerning interest calculation.
© SAP AG
IHE203
12-18
12. Dunning and Collections:
Dunning Execution
A dunning run is executed in two steps:
1. Identifying all due items and grouping them
= Dunning proposal run
2. Execute dunning activities
= Dunning activity run
Plus post processing, e.g. Produce Correspondence
= Correspondence Print
© SAP 2008
„
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 that 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. Further changes cannot be edited. If
you would like to have a different dunning proposal, you can delete it, do 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
accounting clerk, a charge or interest postings.
© SAP AG
IHE203
12-19
12. Dunning and Collections:
Dunning Proposal: Maintain Parameters
General selections
Date of Issue
Business partner
Company code
Contract Account
Net due date
Technical settings
Logs
to
to
to
to
© SAP 2008
„
You need to enter parameters for a dunning proposal run whenever you want to create a dunning
proposal. The parameters for a dunning proposal run that has been executed cannot be reused, you
have to enter new parameters under a unique identifier each time. 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.
© SAP AG
IHE203
12-20
12. Dunning and Collections:
Dunning Proposal Run
Determine items due for
dunning
Group
Group items
items in
in dunning
dunning
grouping
grouping
Determine
Determine dunning
dunning levels
levels from
from
dunning
history
dunning history
Determine
Determine
dunning
dunning
proposals
proposals
Check
Check minimum
minimum dunning
dunning
amount
amount for
for dunning
dunning level
level
Dunning
Header
FKKMAKO
Dunning
Items
FKKMAZE
Check
Check dunning
dunning level
level
requirements
requirements
© SAP 2008
„
The dunning proposal run determines all items due for dunning and combines them in a dunning
grouping.
„
Note: 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.
„
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.
„
Note: Dispute Management is a subcomponent of the solution SAP Financial Supply Chain
Management.
© SAP AG
IHE203
12-21
12. Dunning and Collections:
Dunning Grouping
© SAP 2008
„
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.
„
Example: For additional criteria for grouping: Separate dunning notices for each Contract Object.
© SAP AG
IHE203
12-22
12. Dunning and Collections:
Dunning Activity Run
Dunning
Dunning
headers
headers
Correspondence
Note to clerk
Dunning
Dunning
items
items
Dunning
Dunning activity
activity
run
run
Calculate
Calculate charges/interest
charges/interest
Release
collection agency
Post
Post Interest
Interest and/or
and/or
charges
charges
Check
Check dunning
dunning activity
activity
Requirements
Requirements
Update
Update Dunning
Dunning and
and
Activity
Activity history
history
© SAP 2008
„
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 creation date
(MDRKD).
„
The dunning levels and appropriate dunning activities are determined based on the dunning
groupings and dunning items. Upon execution, dunning is then complete.
„
A dunning activity run can result in any type of output (correspondence or a note to an accounting
clerk, for example), a charge or interest posting, or updates in the dunning history and dunning
activity history.
„
Note: 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
(Mass Reversal of Dunning Notices), or cancel the dunning for certain items. Go to: Environment →
Dunning History → Overview → Cancel. (the button with the red arrow).
© SAP AG
IHE203
12-23
12. Dunning and Collections: Dunning Proposal
Run - Technical Information
Reserve interval
Dunning selection
dispatcher
TFK047A
Determine dunning proposal
Next interval
Determine all items
due for dunning
Dunning procedure
Grouping items according
to dunning grouping
Determine dunning level
from dunning history
Check dunning limit for
level
Check execution
parameters for dunning
level
FKKMAZE
FKKMAKO
Dunning history
TFK047C
Confirm interval
Dunning
groups
TFK047B
Dunning levels
Minimum amounts
Dunning
items
© SAP 2008
„
The dunning run is a parallel process, and you can divide the dataset into subsets, or "intervals", so
that several runs can be executed simultaneously. Several jobs are then started simultaneously in
one dunning run, each processing one of the intervals in parallel. If you wish to use several parallel
jobs, you can either run them all on one computer (the application server), or you can distribute
them to several different application servers.
„
You can split the data into intervals either by business partner or by contract account, and the
division is controlled by variants in which you specify the number of intervals the data area for
dunning is to be divided into, and the key area covered by each interval.
„
The dunning proposal is transferred into the dunning history by running the dunning activity run.
Thereafter, the proposal becomes the dunning history.
„
Note: The execution variant is an additional way to influence open items in a dunning proposal run.
You can use it if you define Event 0300.
© SAP AG
IHE203
12-24
12. Dunning and Collections: Dunning Activity
Run - Technical Information
Event 0310: before first interval
TFK047B
Dunning group
Dunning levels
(Event 330: New FKKMAKO entry)
Read Groups (FKKMAZE)
Read Items (FKKMAKT)
FKKMAKO
Read further items (Event 340:
all data has been read)
Post charge 2 (Event 361:
Determine charge 2)
Post charge 3 (Event 362:
Determine charge 3)
Dunning
history header
Determine and post interest
(Event 370, 380)
Dunning activities
(Event 350)
Dunning
history: line
items
Dunning charges
Post charge 1 (Event 360:
Determine charge 1)
FKKMAKO
FKKMAZE
TFK047E/I/H
TFK047L
Activities
TFKFBM/S/C
Mass update
Update history (Event 390)
Function
module(s)
(activities)
Event 320 after last interval
© SAP 2008
„
Technical tips: The following Events/Function Modules are used in conjunction with the dunning
printing/activity run:
• 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
© SAP AG
IHE203
12-25
12. Dunning and Collections: Dunning History
FKKMAKO
FKKMAZE
FKKMAKT
Dunning history header (groupings)
Dunning history of individual items
Activities that have been triggered
© SAP 2008
„
You can only get a dunning history, if at least one complete dunning run (i.e. proposal run PLUS
activity run) was successfully executed.
„
Information about the dunning procedure can be displayed in the header area for each of the dunning
procedures with a sequence number in the contract. This information can be: first and last date of the
dunning procedure, dunning status, oldest and most recent due dates dunned.
„
You can double-click on any one of the activities in the history list to access the item-related
dunning history which will display the dunning header and dunning lines for that activity.
„
You can call dunning history information using Transaction FPL9 (Account Balance Display) 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.
„
A dunning notice can be reversed if it has been wrongly issued for a business partner from within
dunning history functionality. The charges generated as a result of this dunning notice are reversed
as well.
© SAP AG
IHE203
12-26
12. Dunning and Collections:
Collection Processing - Business Scenario
„
After multiple unsuccessful collection attempts, your institution releases overdue items for
submission to an external collection agency.
„
The student decide to pay after all. Your institution has to recall the paid items from the
collection agency.
© SAP 2008
„
The following pages give an overview.
„
The process may vary depending on legal requirements.
© SAP AG
IHE203
12-27
12. Dunning and Collections:
External Collection Agencies: Concept
The submission of receivables is realized in two steps:
1. Store all receivables that have been/are to be submitted (release for
submission) in table DFKKCOLL.
2. Select receivables that are to be submitted from table DFKKCOLL, and
physically submit using RFKKCOL2, which creates a list or file for each
collection agency (submission to collection agency).
© SAP 2008
„
If a receivable is submitted to an external collection agency, it means that a business partner, e.g.
student, has not paid a receivable and that the institution is not able to collect it.
„
The external collection agency must be defined as a SAP Business Partner.
„
Receivables submission is made up of two steps:
„
Entry of database table DFKKCOLL, in which all submitted receivables and receivables to be
released (Release for Submission) are managed.
„
Selection of receivables to be submitted from the DFKKCOLL database table, and physical
submission of the receivables using report RFKKCOL2, which creates a file or list for each
collection agency (Submission to Collection Agency).
„
Submission of receivables can be triggered by:
• Carrying out mass activities: release FP03M, submission FP03DM
• Manually: release FP03E, submission FP03D
• As a result of a dunning activity
„
The result of every submission is the creation of a list or file.
„
You can use Transaction FP03 (Submission to External Coll. Agency) to manage the submission
status of the items.
„
You can recall items, change the status an so on.
© SAP AG
IHE203
12-28
12. Dunning and Collections:
Release and Submission of Receivables
Mass
Mass run:
run: Release
Release
Collection
agency
(FP03M)
(FP03M)
FP03
Dunning
Dunning activity
activity
(event
(event 0350)
0350)
Soft&Easy
Item 1 Smith
Item 2 Jones
Item 3 Roberts
(FKK_COLL_AGENCY_RELEASE_0350)
(FKK_COLL_AGENCY_RELEASE_0350)
Item 4 Wright
Item 5 Clarke
Mass
Mass run:
run: Write
Write off
off
(FP04M)
(FP04M)
FP03D / FP03DM
(Submission)
Write
Write off
off
Item 6 Brown
Total:
$ 1 205 488
(FP04)
(FP04)
Manual
Manual release
release
Status: Released
(FP03E)
(FP03E)
DFKKCOLL
Submission
file
© SAP 2008
„
The Dunning Activity (FKK_COLL_AGENCY_RELEASE_0350) releases a receivable to an
external collection agency. Submission of receivables to collection agencies is possible for items:
• Receivables (also statistical items)
• Credit memos
„
The submission status 01: receivable released is set.
„
Periodic submission run (transaction FP03D or FP03DM) selects the documents and creates a list
and/or a submission file (the submission file can be based on XML). The following data is updated:
• In the collection items (DFKKCOLL): Submission date, submission status (02: receivable
submitted) and a submission amount, if it does not match the amount of the open item.
• In the document: Payment block, dunning block or alternative payer (Posting Area 1054).
Additional documents can be submitted to the collection agency for Event 5069.
„
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 (Menu : Working Periodically
Æ Delete Data).
© SAP AG
IHE203
12-29
12. Dunning and Collections:
Submission Status
Submission Status in Table DFKKCOLL
01: Receivable released for submission
‹
Release processes (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 uncollectable (event 0020)
09: Receivable recalled
‹
Recall receivable
10: Receivable paid directly by customer (event 0020)
11: Receivable partially paid directly by customer (event 0020)
12: Receivable cleared (event 0020)
13: Receivable partially cleared (event 0020)
© SAP 2008
„
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. Please do not change them!
„
Using the mass run Information for Collection Agencies (Easy Access Menu: Accounting>Financial
Accounting>Contract Accounts Receivable and Payable>Periodic Processing>For Contract
Accounts>Submission for Collection), you can forward the following additional information to the
Collection Agencies you use.
• The Business Partner has paid part or all of the outstanding amount to you directly.
• You want to call back one or more items because the collection agency could not collect these
items within a specified period.
• You have reversed the direct payment of a customer for a previously submitted item.
• After the direct payment by a customer, you have partially or completely reset the clearing for a
previously submitted item.
• The direct payment by a customer for a previously submitted item leads to a return, so that the
receivable is now open again.
© SAP AG
IHE203
12-30
12. Dunning and Collections: Submission of
Receivables to Collection Agencies
IMG
Step
Description
Condition
Source Fields
Target Fields
Step 1
Derivation rule 1
-
POST_CODE1
TMPR1 (temporary)
Step 2
Derivation rule 2
BETRH <= 1000
TMPR1 (temporary)
INKGP (BP agency)
Step 3
Derivation rule 3
BETRH > 1000
TMPR1 (temporary)
INKGP (BP agency)
Derivation rule 1
Source Fields
Target Fields
68163
Mannheim
69190
Mannheim
Source Fields
Target Fields
Mannheim
200000078
Source Fields
Target Fields
Mannheim
200000079
Type :
-Derivation rule
-Table lookup
-Assignment
-Initialization
(amount)
Derivation rule 2
Derivation rule 3
© SAP 2008
„
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
(Mass Run: Release for Collection
„
The derivation tool determines the responsible collection agency in one or a number of steps from a
range of source fields of the 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.
© SAP AG
IHE203
12-31
12. Dunning and Collections:
Management of Submitted Receivables
Receivables that were submitted to external collection agencies can be
managed using transaction FP03. The following functions are available in that
transaction:
„
Change submission status (change document is created)
„
Indicator that the receivables were sold to the collection agency
„
Submit receivables
„
Recall receivables
„
Create list of collection items
© SAP 2008
© SAP AG
IHE203
12-32
12. Dunning and Collections:
Inbound Collection Agency Information
The collection agency file contains:
„
Collected payments
„
Uncollected payments
„
Interest
„
Charges
Program RFKKCOPM reads the collection agency file. The file
contains interest and charges that are posted as interest receivables
and charges receivables.
So that the collected payments can be posted, program RFKKCOPM
generates a payment lot or check lot that can also be directly
scheduled.
© SAP 2008
„
A collection agency has completed a collection order and now forwards a file to your institution
informing of the receivables that were collected, and those that were only partially collected or not
collected at all.
© SAP AG
IHE203
12-33
12. Dunning and Collections: Collection
Agency Payment – Incoming Payment
© SAP 2008
„
When you submit an item, you can create a payment form that simplifies the assignment of
payments to open items. If the file from the collection agency contains collected payments, these can
be allocated to the appropriate open items using the payment form number confirmed by the
collection agency.
„
If the collection file contains interest and charges, the system posts these as interest and credit
receivables and they are passed on to the customer.
„
Receivables that have not been collected and are, therefore, irrecoverable can be automatically
written off if you activate the Write-off Item Directly indicator in the write-off parameters of
RFKKCOPM.
„
Collection charges to be paid to the collection agency can be determined using a defined function
module in event 5068 and posted as payables to the collection agency.s contract account. To do this,
you must activate Post Collection Charges indicator in the specifications of RFKKCOPM.
„
If the collection agency provides the information personally or in writing, the payments, interest and
charges receivables must be posted manually. You can use Transaction FPAVI (Payment Advice
Note From Collection Agency) to enter a payment advice note.
© SAP AG
IHE203
12-34
12. Dunning and Collection:
Post Agency Payments
Items in collection agency file
VKONT |
VK1
|
BETRZ |
50
NINBK | BETRI | BETRC | ....
|
Scenario:
|
3
|
2
| ....
A Business Partner has paid 50 EUR plus 3 EUR interest and 2 EUR charges.
Contr. Acc. 1 (VK1)
Receivable
50
(1) Interest receivable
3
(2) Charges receivable
2
(3) Payment
Bank clearing
-50
50
-3
3
-2
2
© SAP 2008
© SAP AG
IHE203
12-35
12. Dunning and Collections:
Information for Incoming Payment
Lin Smith,
Getting a dunning letter
Payment and Collection System
Dunning
program
Lin Smith - Tax
Debit
Payment
Michael Fox,
Is informed about
incoming payment
Bank
© SAP 2008
„
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.
„
Incoming payments are always made with a particular origin key (for example payment lot, manual
payment). If you do not want automatic notification for particular types of incoming payments, you
can define this in Customizing of Contract Accounts Receivable and Payable.
© SAP AG
IHE203
12-36
12. Dunning and Collections:
Information for Collection Agency
© SAP 2008
„
The Collection Agency has to be informed when items are called back and must receive information
on items that have already been submitted. In Customizing, you can specify which information is
included in the file for the Collection Agency.
„
The Information for Collection Agency (FPCI) mass run enables you to create files for the collection
agency that contain the following information:
„
The master data of one or more business partners has changed.
„
The business partner has directly paid part or all of the outstanding amount. The program writes
items with the following submission status in the file:
• 10 (receivable paid directly by customer)
• 11 (receivable partially paid by customer)
„
Items that the Collection Agency cannot recover within a certain period have to be called back.
When this happens the program includes items that have the submission Status 09 (call back
receivable) in the file.
„
The direct customer payment for a previously submitted item was reversed, clearing reset or a return
made.
„
In the case of a reversal, returns or the (partial) reset of a clearing, the items in question receive the
Status 02 (receivable submitted) again. You can inform the collection agency of the re-submission
of items using the information file - as long as the collection agency was already informed of the
customer’s direct payment.
© SAP AG
IHE203
12-37
12. Dunning and Collections: Unit Summary
You should now be able to:
„
Discuss the dunning requirements of your institution
„
Understand the dunning terminology
„
Configure a dunning procedure with dunning levels, charges, and activities
„
Execute a dunning proposal, print, and perform an activity run
„
Analyze the dunning history
„
Explain functions related to collection agencies
© SAP 2008
© SAP AG
IHE203
12-38
IHE203 Student Accounting
Basics
Master Data
Fee Calculation Process
Fee Calculation Configuration
Fee Calculation Configuration Financial
Fee Calculation Other Fees
Sponsoring
Document Posting and Processing
Correspondence
Payments
Clearing and Account Maintenance
Dunning and Collections
Additional Functions
© SAP 2008
© SAP AG
IHE203
13-1
13. Additional Functions
Content
„
„
„
„
Reversals & Reset Clearing
Transfers
Doubtful Entry/Individual Value Adjustment
Write-off Process
„
Deferrals & Installment Plan
Interest Calculation
„
Bank Returns
„
© SAP 2008
© SAP AG
IHE203
13-2
13. Additional Functions: Unit Objectives
At the conclusion of this unit, you will be able to:
„
Reverse documents & Reset clearing
„
Transfer documents
„
Describe follow-up processes involving overdue items
„
Differentiate between deferring the due date and implementing an
installment plan
„
Identify key elements of interest calculation
„
Discuss the Return Process
© SAP 2008
© SAP AG
IHE203
13-3
13. Additional Functions: Reversal
IMG: Contract Accounts Receivable and PayableÆ Business Transactions Æ Reversal
© SAP 2008
„
Document to be reversed:
• After reversal, the business partner items have the clearing document number of the reverse
document.
„
Indicator reverse document:
• Reference to the reversed document using the document number from the reversed document in
the document header.
• In the reversal document, an item is created for every G/L. These items have the opposite +/- sign
to the G/L item.
„
Note: You cannot reverse a document if:
„
If the document has already been cleared. You have to reset clearing before you can reverse the
document.
„
It was not originally posted in PSCD. If you want to reverse such a document, you must reverse it
in the application/solution where it was posted.
„
There is already an installment plan or an interest document. You have to deactivate the installment
plan or reverse the additional documents before you can reverse the original document.
„
Alternative: Post an adjustment using the „Request“ Transaction, especially, if the reversal is for a
previous posting period and month-end/year-end reporting has been done.
© SAP AG
IHE203
13-4
13. Additional Functions: Reset Clearing
IMG: Contract Accounts Receivables and Payables Æ Basic Functions Æ Open Item
Management Æ Reset Clearing
© SAP 2008
„
To reverse a cleared item, it is necessary to reset clearing first.
„
When resetting a paid items, you reopen the paid item.
„
In addition, a credit item is created automatically. The credit transaction, such as a payment on
account, is defined in Customizing.
„
If you reset clearing that resulted from a payment to a customer, a debit transaction must be defined
in Customizing so that the system can create a receivable for the business partner who received the
payment.
„
Instead of the resetting the complete clearing, you can also reset parts of clearing. Clearing reset can
be set for every combination of the following data that occurs during clearing:
• Business Partner, Contract Account, Contract, Company Code, Business Area, Collective Bill
Number
© SAP AG
IHE203
13-5
13. Additional Functions: Transfer
IMG: Contract Accounts Receivable and Payable Æ Business Transactions Æ Transfer
© SAP 2008
„
The transfer process can be useful if a student was mistakenly created twice and has postings under
both business partner numbers.
„
From time to time it might also be necessary to transfer documents between different contracts or
contract accounts for the same business partner, e.g. a sponsor.
„
Before your institution decides to use this process consider follow-up processes such as reporting to
ensure that the same documents are not reported twice.
„
The transfer function does not replace reversals.
„
The account determination does not change when documents are transferred. See also Note 616098
FAQ in OSS and FI-CA Events: 5080 – 5130
„
The transferred items are cleared and a new open item is created for each item under the transfer
posting document number. The new items only differ from the original items in their origin and
posting date. The receivables account, due date, transaction name, and dunning and interest
information remain the same for these items.
„
You can only transfer open receivables or credits including 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 receivables still open. The transfer posting document can be
reversed.
© SAP AG
IHE203
13-6
13. Additional Functions:
Doubtful Entry/Individual Value Adjustment
IMG: Contract Accounts Receivable and Payable Æ Business Transactions Æ
Doubtful Items and Individual Value Adjustment
© SAP 2008
„
For doubtful entries take into account the fact that, for accounting purposes, the business partner,
e.g. student or sponsor, may not pay his/her receivables. For accounting purposes, you must separate
the doubtful receivables from those that are beyond doubt.
„
The process is started in PSCD, although the generated FI-CA documents are only relevant for
general ledger accounting. The FI-CA documents do not have a business partner item.
„
Transaction code for marking open items: FPZW - Adjust Receivables
„
Transaction code for mass run of adjusted receivables: FPRV - Transfer Posting of Adjusted
Receivables. The functionality for reversing the mass run is available.
„
Note:
Many institutions use open item report (the aging report) to select unpaid items of a certain age and
take a percentage of the total of the reported items to post a manual journal in FI.
© SAP AG
IHE203
13-7
13. Additional Functions: Write-Off
Selection Details
BPartner
Contract Acc.
Contract
Document No.
Reference
Total/Partial
Write-off
BP1
BP1
RITEOFF
RITEOFF
W.
W. Riteoff
Riteoff
W/o
Resubmission date
Specifications for Write-Off
(1)100,--
80,-- (2)
FI GL-Accounts
Posting Date
04/15/2005
04/15/2005
Clearing Reason 04
04 Write-Off
Write-Off Reason 02
02 Waiver
Resub. Date
Contract Account
Write-off items/
Write-off Mass run
Account
Determination
Tuition
Tuition Fee
Fee
100,-- (1)
Write
Write -- Off
Off
(2) 80,--
IMG: Contract Accounts Receivable and Payable Æ Business Transactions Æ Write-Offs
© SAP 2008
„
You can carry out writing off manually as well as in a mass run.(Transaction Codes: FP04 (Write
Off), FP04M (Mass Run: Write-Off)..
„
The Function Module called at Event 5010 enables you to specify company-specific check rules.
These check rules then determine which of the open items selected can be written off and displayed
accordingly on the selection screen. In the transaction of a mass run, tab Posting Parameters, you
can set the indicator: Do not use write-off rules.
„
It is possible to write-off debit or credit balances within PSCD.
„
Special revenue and expense accounts for write-off postings can be defined in customizing.
Depending on the write-off reason defined for the write-off process, the same account assignment is
used as in the written off document.
„
Transaction Code FPZW (Adjust Receivables) allows you to write off a percentage of an item.
„
Open items can be written off completely or partially. You can specify the partial amount to be
written off in the Write Off Items transaction. Partial write-offs must be explicitly permitted in
Customizing along with a write-off reason. When an item is written off, the written-off document
items are cleared and a write-off document is created. The system automatically posts the expense or
revenue accounts defined in Customizing. Write-off documents can be reversed. If this is done,
receivables or payables are open again.
„
You must define rules for adjusting tax during write-offs. If the posted expense account is taxrelevant, the system also adjusts the posted tax during write-off.
© SAP AG
IHE203
13-8
13. Additional Functions: Write-Off History
© SAP 2008
„
The Public Sector Write-Off History lists the individual documents which were written off and
entered in the write-off history using the function Write Off Items. It can show the name of the
business partner.
„
When customizing default specifications for writing-off items, you define at what ‘check level’
write-off rules are to apply; the possible levels are at document, business partner, contract account.
For example, if charge-off rules are defined to apply at check level ‘contract account’ then rules will
be applied to each contract account individually.
„
Other customizing areas within the IMG for write-offs include defining allowable charge-off reasons
and automatic G/L account determination (definition of the revenue and expense accounts to be
posted to when executing charge-off function).
„
In Transaction FP04 (Write-Off), you can enter notes for a write-off document created. To do this, in
the menu choose Extras -> Notes -> Enter Notes.
„
After writing off, you can print the information of the write-off document and the written off items.
The data of the write-off document, the cleared items and the data entered during the write off with
additional information on the business partner is available for this. Correspondence Type P034
Write-Off Data is used and uses the Form Class FMCA_WRITEOFF_DOC. SAP provides the
sample form FMCCA_WRITEOFF_DOC_SAMPLE_SF.
© SAP AG
IHE203
13-9
13. Additional Functions:
Deferral versus Installment Plan
Business Scenario:
A
student has temporary difficulties paying the receivable on time. Your institution offers
an extension. This can be done in 2 two ways:
1. Change the Net Due Date. This is widely used by institutions since it is an uncomplicated process.
No configuration is involved.
2. Defer the Due Date. This is a formal process providing a history.
Another
student owes a large sum and is unable to pay the total amount at once. The
student requests to pay in smaller installments over a period of time. The institution sets
up an installment plan for this student.
Your
institution may charge interest and/or a service charge.
Note: Do not mix up the SLCM “Due Date Schedule” with the FI-CA Installment Plan.
The latter is in addition to the SLCM payment schedule
IMG Path: Financial Accounting Æ Contract Accounts Receivable and Payable Æ
Business Transactions Æ Deferral and Installment Plans
© SAP 2008
„
In Student Lifecycle Management, you have the option of setting up a Due Date Schedule which
could split tuition into multiple open items with different due dates. For example, your institution
offers students to pay 60% of the tuition by Date X and 40 % by Date Y.
„
Suppose the tuition is $1000. For this, Student Lifecycle Management would create two items for
$600 and $400 with the appropriate due dates. Let‘s assume that on date Y, the student can‘t pay the
remaining $400 (40%) and asks for the deferral of the due date or for an installment plan.
„
In PSCD, you can set up an Installment Plan allowing the student to pay the remaining $400 in 4
monthly installments of $100. You may or may not charge an installment fee and/or interest.
„
The deferred item will not be dunned in a dunning run and will not be collected from the bank by the
payment program until the new date.
„
Once the deferral date has passed or is deleted from the item, the item can be dunned again and
collected.
© SAP AG
IHE203
13-10
13. Additional Functions:
Installment Plans: Processing
BP 1
BP 1
Open Item 1
Open Item 2
due 01.31.YY
due 02.15.YY
+ Fee/Interest
BP 1
Open Item 1/1
due 03.31.YY
BP 1
Open Item 1/2
due 04.30.YY
BP 1
Open Item 1/3
due 05.31.YY
BP 1
Open Item 1/4
due 06.30.YY
© SAP 2008
„
With an installment plan you divide source items to 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. The installment plan history records the period in which a source item appears in an
installment plan (Account /Other Information /Installment Plan History).
© SAP AG
IHE203
13-11
13. Additional Functions:
Installment Plan: Technical View
Open Item(s)
1
2001366
02/02/2000
Installment Plan
60
Document Number
1
1300060
02/02/2005
10
2
1300060
03/02/2005
10
3
1300060
04/02/2005
10
4
1300060
05/02/2005
10
5
1300060
06/02/2005
10
6
1300060
07/02/2005
10
Repetitive Documents
© SAP 2008
„
One or more open items can be broken down into a particular installment plan.
„
The number of installments within the plan, the interest key (controls grace period, interest
frequency, interest interval unit, and the interest calculation rule) are defined when creating a plan.
Frequently occurring installment terms and conditions can be stored in the system as defaulted
installment plans.
„
If the installment plan is cancelled, it can be manually deactivated. Upon deactivation the original
receivable(s) is/are re-opened and the link between the original receivable and installment plan
deleted.
„
Installments in conjunction with installment plans are represented as repetitive PSCD documents.
„
Dunning of installment plan items is possible within PSCD.
„
Clearing of source items and installment plan items is also supported.
„
Legend:
• OPBEL: Number of the document in contract accounts receivable and payable (FI-CA)
• OPUPK: Item number in the FI-CA document
• WHGRP: Repetition group
• BETRW: Amount in transaction currency with +/- sign
• OPUPW: Repetition item in the FI-CA document
• FAEDN: Net due date
© SAP AG
IHE203
13-12
13. Additional Functions:
Installment Plan: Configuration
An installment plan needs information on:
1. Number of installments, or
2. Net amount of installments
how many?
how much?
1. Start date
2. Intervals between installments
from when on?
when again?
3. Charges
4. Interest
5. Posting of charges and interest
how much else?
how calculated?
when due?
6. Remaining amount
7. Rounding rules
what added to?
which amount?
© SAP 2008
„
You can define an alternative payer to the business partner for installment plan items. Use the 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 input field Card ID to enter a payment card ID. (Note: depending on
your environment, this might not be compliant with PCI standards).
© SAP AG
IHE203
13-13
13. Additional Functions: Interest Calculation
Business Scenario:
Your institution charges interest in conjunction with:
Overdue items
„ Installment plans
„ Dunning notices
„
If your institution wants to calculated interest then you should consider the following:
„
On which occasions do we calculate interest?
„
Are there minimum amount limits for the source item that would exclude the calculation and
posting?
„
How do we calculate interest? How do we round a sum of source items?
„
How do we select the open items?
„
Are there exceptions, that is, are there cases in which do we NOT calculate interest?
„
Is there an amount limit under which we do not process interest?
„
Do we post a minimum amount instead of the calculation result?
„
How do we post and further process interest?
IMG Path: Financial Accounting Æ Contract Accounts Receivable and Payable Æ
Business Transactions Æ Interest Calculation
© SAP 2008
„
General Comments:
Comments
„
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.
© SAP AG
IHE203
13-14
13. Additional Functions:
Business Transactions for Posting Interest
Post Interest Manually
Mass Interest runs
Dunning run
PSCD:
Functions
for
calculating
and
posting
interest
$
100
Interest documents
Create installment plan
G/L relevant or statistical?
DB
Cash Security Deposit
© SAP 2008
„
You can calculate interest:
• Manually: By choosing Account/Interest/Post, you can select one, several, or all line items. You
can choose if you want to take credit items into account. You can print an interest notification.
• Mass run: Periodic Processing/For Contract Accounts/Interest Run
„
You can display an interest document via Account/Interest/Display Calculation.
„
Note: In a dunning run, you can calculate interest for open items only. As cleared items are not
dunned, they are not included in the interest calculation.
„
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 simulation: Interest is calculated for information only; it is not posted.
© SAP AG
IHE203
13-15
13. Additional Functions: Posting of Interest
+
+
Interest
Lock
=
Interest Key
or
Open item
statistically
Amount
Limit
+
Statistics
Indicator
100
100
© SAP 2008
„
The interest key controls interest calculation and can be assigned to contract accounts, security
deposits, individual line items or dunning levels.
„
To help 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 schedule. The schedule shows
the items for which interest was calculated for which amounts at which interval. The interest key is
retained in the interest schedule. 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.
© SAP AG
IHE203
13-16
13. Additional Functions:
Interest Schedule and Interest History
Interest Document
Source Item
1000
100
How
calculated?
When
calculated?
Interest History
Interest Schedule
© SAP 2008
„
An interest document includes the structures of a document in Contract Accounts Receivable and
Payable: 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 schedule 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 schedule can be accessed via an interest document.
„
An interest history records the interest calculation period for each line item on which interest is to be
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. Mark the items on which you want to calculate interest. Select Display interest
„
Note: 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 schedule. If the
rate is changed for dates in the past, nothing will happen. The system will warn you, however, if you
attempt such a change.
© SAP AG
IHE203
13-17
13. Additional Functions: Bank Returns
Business Scenario:
Your institution 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, etc.) and wishes to reflect this business transaction in the system.
Returns Occur
„
if the financial institution is unable to complete a payment order, or
„
a customer disputes a transaction.
The Returns Lot is a grouping of documents that were
„
sent back by a house bank and
„
settled with the same bank clearing account.
IMG Path: Financial Accounting Æ Contract Accounts Receivable and Payable Æ
Business Transactions Æ Returns
© SAP 2008
„
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, which can be created either manually (using return slips), or automatically (by
copying return data from the financial institution with a program that you write yourself).
„
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, etc.
„
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 rather than a
settlement account. Data can be entered automatically or manually into a lot.
© SAP AG
IHE203
13-18
13. Additional Functions: Processing Structure
3. Execute further
activities, e.g.
2. Post Charges
Bank Charge
Charge
Change
Change Contract
Contract
Account
Account
Returns Reason
Return
Return
Document
Document
Returns Lot
1. Cancel clearings
Letter
Letter
Info
Info to
to Clerk/Agent
Clerk/Agent
Set
Set locks
locks
4. Returns History
© SAP 2008
„
First the system determines the receivables or payables that were cleared by incoming or outgoing
payments. This payment clearing is cancelled so that the original receivables or payables are open
again. The system generates a return document containing the offsetting items for the items in the
payment document.
„
Bank charges are posted to the general ledger. You can charge any bank fees to your business
partners (without tax). 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, a new deferral date, a dunning block and/or a
payment block for the reopened receivables, contract account changes, e.g. dunning block,
incoming payment block, outgoing payment block and/or incoming payment method, from direct
debiting to payment on demand.
„
Other activities such as workflow connection, creation of information for clerk/agent, 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.
„
Customers can adapt SAP’s standard solutions.
© SAP AG
IHE203
13-19
13. Additional Functions:
Posting with Bank Charges
1.
2.
3.
4.
5.
6.
7.
8.
Invoice
Payment by Bank Collection
Incoming Payment
Incoming Payment
Reverse clearing (return in
FICA)
Post expense from bank charges
Pass bank charges to student
Raise and debit charges
© SAP 2008
„
Returns are processed automatically as follows. First, the receivables or payables that were cleared
on the basis of incoming or outgoing payments are determined. This payment clearing is cancelled
so that the original receivables or payables are open again. The system generates a return document
containing the offsetting items for the items in the payment document. Any further postings which
are necessary because of taxes or charges are generated and follow-up activities are triggered.
„
Different types of return postings:
• Net return (return amount contains no charges)
• Gross return (return amount contains charges)
• Charges including taxes (gross charge)
• Charges excluding taxes (net charge)
„
The returns lot account is essentially a clearing account.
„
Allocation via the original document number (from the field "Note to payee on bank document")
„
Note:
• 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.
• Postings [5] to [8] can be made within one activity.
© SAP AG
IHE203
13-20
13. Additional Functions: Unit Summary
You should now be able to:
„
Reverse documents & Reset clearing
„
Transfer documents
„
Describe follow-up processes involving overdue items
„
Differentiate between deferring the due date and implementing an
installment plan
„
Identify key elements of interest calculation
„
Discuss the Return Process
© SAP 2008
© SAP AG
IHE203
13-21
© SAP AG
IHE203
13-22