Business Transactions

PDF download from SAP Help Portal:

http://help.sap.com/erp2005_ehp_05/helpdata/en/4b/7bcb53f0f67314e10000000a174cb4/frameset.htm

Created on December 09, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note

This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

© 2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC Page 1 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Table of content
1 Business Transactions
1.1 Payment Plan
1.2 Payments
1.3 Coinsurance
1.4 Interest Calculation
1.5 Dunning
1.6 Returns
1.6.1 Returns Lots
1.6.2 Returns Category
1.6.3 Returns Reason
1.6.4 Creditworthiness
1.6.5 Entering and Posting Returns Manually
1.6.5.1 Entering Returns Lots Manually
1.6.5.2 Closing Returns Lots Manually
1.6.5.3 Posting Returns Lots Manually
1.6.5.4 Screen Variants for Processing Returns Lots
1.6.6 Entering and Posting Returns Automatically
1.6.6.1 Entering Parameters for Automatic Returns Transfers
1.6.6.2 Program Termination: Continue Returns Lot Transfer
1.6.7 Posting to Clarification Account
1.6.7.1 Postprocessing Returns Lots
1.6.8 Special Features in Processing Returns
1.6.8.1 Type of Posting
1.6.8.2 Charge Handling
1.6.9 Executing Returns Activities
1.6.9.1 Printing Returns Notices
1.6.10 Displaying the Returns History
1.6.11 Execution of Further Returns Activities
1.7 Deferrals and Installment Plans
1.8 Promise to Pay
1.9 Write-Offs
1.10 Submitting Receivables to Collection Agencies
1.11 Transferring Open Business Partner Items
1.12 Business Partner Duplicates
1.12.1 Import of Business Partner Duplicates
1.12.2 Processing of Business Partner Duplicates
1.12.3 Processing of Clarification Cases from Duplicate Processing
1.12.4 Display of Business Partner Duplicates
1.12.5 BP Duplicates in Account Balance Display and Account Maintenance
1.13 Policyholder Change
1.13.1 Deletion of Data on Policyholder Change
1.13.2 Example for Multiple Policyholder Changes
1.14 Provisional Premium Requests
1.14.1 Clearing of Provisional Premium Requests
1.14.1.1 Restriction on the Clearing of Provisional Premiums
1.14.1.2 Examples Showing the Clearing of Provisional Premium Requests
1.14.2 Processing of Clarificn Cases from Prov. Premium Req. Clearing
1.15 Deferred Revenue Postings
1.16 Revenue Distribution

PUBLIC Page 2 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1 Business Transactions

Use
You use this component to post and process your business transactions. The procedure is extensively automated.
You make the required definitions for controlling the procedures in Customizing, and normally assign these definitions at business partner/contract
account/insurance object level. However, you can also enter them in the line item if this particular line item is to be processed separately.

Features
The following functional areas are available:
Payment Plan
Payments
Coinsurance
Interest Calculation
Dunning
Returns
Deferral and Installment Plan
Promise to Pay
Write-Offs
Submitting Receivables to Collection Agencies
Transferring Open Business Partner Items
Business Partner Duplicates
Policyholder Change
Provisional Premium Receivables
Deferred Revenue Postings
Revenue Distribution

1.1 Payment Plan

Purpose
Payment plans and payment plan itemsenable the creation of documents that form the basis for the processes in the Collections/Disbursements system.
Payment plans are used to convert total amounts, which are valid for a specific period, into payment plan items at the level of the insurance object-partner
relationship. Collections/Disbursements can determine the amount and due date for the open items to be created, using the specifications from the payment plan
and the control parameters defined for the payment plan items.

Notes on Implementation
You define control information for payment plans in the Implementation Guide. Choose Collections/Disbursements Payment Plans .

Features
To create documents, set document-related data from an operational system in Collections/Disbursements .
Payment plan data is stored for the insurance relationship, and belongs to the master data ( Payment Plan tab page).
The payment plan data is enhanced by payment plan item data. This data, which can be about an amount, a validity period or account assignments, for
example, is used as the basis for the documents to be created. These are generated by the Execute Payment Plans mass activity.

1.2 Payments

Purpose
You use this component to create and process outgoing and incoming payments.

Features
The following detail components have been implemented:
Processing Incoming and Outgoing Payments

PUBLIC Page 3 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Creating Incoming and Outgoing Payments
Check Management
Receipt Management
Processing Credits

1.3 Coinsurance

Use
You require this component if you share risks with other insurance companies and realize coinsurance business as the lead insurer.

Features
The following functions and processes control coinsurance business in Collections/Disbursements :

Coinsurer Settings
The coinsurers exist as business partners with accounts and contracts in the system and are identified by the coinsurance keys. It is mandatory for a coinsurer to
have one contract for premium shares and one contract for claim shares. With costs that occur as a result of processing business transactions for the coinsurer,
you use one cost contract for premiums and one cost contract for claims, with the coinsurer as the business partner.

Posting Premiums, Claims and Costs

The system identifies the coinsurance sharesthanks to G/L items for a document. When posting a document, the system checks whether the G/L-side
specifications defined for the document match the coinsurer specifications. A G/L item is then identified as a coinsurance share if its characteristics match the
values defined for the coinsurance key.
Premiums and claims from policyholders are posted to the contracts for the policyholder. The amount for the document is distributed to the G/L items for the lead
insurer and the participating coinsurers, according to the agreed quotas.
Costs that occur for processing business transactions for the coinsurer are posted to the appropriate costs contracts for the coinsurer. The premium documents,
which are posted to the policyholder, and the associated costs or claims documents are linked by a reference number, the same due date, and other referenced
specifications in the costs document.

Monitoring Coinsurance-Relevant Documents

If coinsurance-relevant documents have been identified, the system monitors the clearing status of these documents, creates a flag for posting coinsurance shares
and defines the posting amounts the system is to create for the coinsurer.
Postings to the coinsurer are flagged when the premiums from policyholders have been (partially) cleared or the claims totals have been disbursed ( credit
procedure), or before clearing the coinsurance-relevant document ( debit procedure).
When reversing a coinsurance-relevant document, the system creates the appropriate offsetting postings for the contracts of the coinsurer, for the debit procedure
and the credit procedure. Clearing resetting is only taken into account in the actual procedure.
In the settings for posting and identification of coinsurance shares for each coinsurance key, you define which procedure is to be applied. You can define the
procedures for premiums and claims separately.

Posting of Coinsurance Shares

A mass activity performs the actual posting of coinsurance shares (summarized premium and claim shares, as well as costs) to the contracts for the coinsurer.
The system processes all posting flags that exist at this point.
When posting coinsurance shares to the coinsurer, the system creates correspondence (coinsurance notifications, correspondence type V035) to the coinsurer.

Processing Coinsurance-Relevant Statistical Items

Coinsurance History
The system stores all relevant data in a coinsurance history. You can archive coinsurance histories.

1.4 Interest Calculation

Purpose
You use the functions for interest calculation to determine and post interest receivables and interest payables.

Scope of Functions
Item interest calculation enables automatic interest calculation for debit and credit items.
You can use balance interest calculation for insurance objects to calculate interest calculation for premium deposits, using the combination of business partner-
insurance object-currency, for example.

1.5 Dunning
PUBLIC Page 4 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.5 Dunning

Use
With the Dunning component, you can create and send payment reminders or dunning letters to your business partners to remind them of overdue payables and
to request payment.
In Collections/Disbursements, you can map your dunning system using the following two concepts:
Dunning by Dunning Procedure for Insurance Companies
Collections Management
Compared to dunning by dunning procedure for insurance companies, dunning with collection management in Contract Accounts Receivable and Payable allows
you to use the Business Rule Framework to control follow-up steps, and to reverse the dunning procedure. It also enables capacity planning. In dunning by
dunning procedure for insurance companies, you can define the sequence of dunning levels on an ascending basis only. In Collections Management, you can set
a flexible sequence for the dunning levels.
However, dunning with Collections Management does not completely support dunning according to German, Austrian and Swiss insurance law, such as special
handling of single premiums, initial premiums and follow-up premiums. Also, dunning with Collections Management does not support dunning using brokers, the
dunning end run, a connection to the information container, or mapping benefit-free periods.
The dunning history can include dunning by collection strategy and dunning by dunning procedure for insurance companies.

Implementation Considerations
You use the company codes to control which concept you use to map your dunning system. You make the appropriate setting in Customizing for
Collections/Disbursements , under Organizational Units Set Up Company Codes for Contract Accounts Receivable and Payable . If you want to use
dunning with Collections Management, define the master data grouping level to be used to the corresponding company code.
If you are already using dunning by dunning procedure for insurance companies and now would like to use dunning by collection strategy, note that running
dunning procedures remain open and are not processed further.
Continue to schedule the dunning end run for your dunning procedures until no more of the documents are in dunning, which had already been dunned with
dunning by dunning procedure for insurance companies. Analyze which dunning end activities are not to run during the dunning end run.
Remove these dunning end activities from Customizing for your dunning procedure. You can find the corresponding IMG activity in Customizing for
Collections/Disbursements , under Business Transactions -> Dunning -> Dunning by Dunning Procedure -> Configure Dunning Procedure .
( )
Note that only the documentation for dunning with Collections Management contains information about the scope of functions of dunning by collection strategy;
functions that you are already familiar with from dunning by dunning procedure for insurance companies are only available for dunning by collection strategy if they
are also listed in the documentation for Collections Management.

1.6 Returns

Purpose
This component enables you to process bank returns that may occur as part of a debit memo or collection procedure, or with check deposits or outgoing
payments.

Features
In the first step, you have to enter the returns data in returns lots manually using returns notes or automatically using a transfer program and then post these lots.
The system then processes the returns automatically. First, the receivables or payables that were cleared on the basis of incoming or outgoing payments are
determined. Then the clearing is reset, which means that the original receivables or payables are open again, and a returns document is created with the
offsetting postings for the payment document items. The system also creates further postings that are necessary because of taxes or charges, and executes
follow-up activities such as adoption of incoming and outgoing payment methods. Bank charges, as well as any tax amounts contained therein, are determined
from the returns amount, if this is specified, and posted to the general ledger. You can pass on any bank charges to your business partners (without tax). By
specifying amount-specific scaled charges in Customizing for the returns reason, you can levy additional charges to your business partner. These returns charges
can be posted in the general ledger or statistically.
You can define the follow-up activities in the system dependent on the returns reason, the creditworthiness of the business partner, the tolerance group of the
contract account, and the number of returns that have occurred. Possible follow-up activities are:
Changes to the item
Setting a deferral date, a dunning block and/or a payment block for the reopened receivables
Changes to the contract account
Setting a dunning block, incoming payment block, outgoing payment block and/or changing the incoming payment method, from direct debiting to payment
on demand, for example.
You can also manually set a processing block with a certain time limit in order to prevent dunning notices and debit memos being generated for a contract
account.
In an industry solution or a customer project, you can also realize the following activities:
Connect processing to a workflow
Create and transfer information for the clerk responsible
Create correspondence for the business partner
The system records all data and activities in a returns history. Here, for example, you can see the number of returns for a business partner. The system uses the
returns history to determine the creditworthiness of a business partner

PUBLIC Page 5 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 You use predefined application forms in the Correspondence component to print paper records such as return notifications. You define application forms using the
Print Workbench .

1.6.1 Returns Lots

Definition
The returns lot is a central object in returns processing. It is essentially a grouping of documents that were sent back by the house bank and are settled with the
same bank clearing account. Data can be entered in the returns lot both automatically and manually.

Structure
A returns lot consists of a header that describes the lot. It contains administrative data and general specifications that the system uses to post the individual items
of the return.
You define the general specifications in Customizing. These include the document type, the clearing reason, the company code, the screen variant, and the
selection type. (In Customizing for Contract Accounts Receivable and Payable, choose Business Transactions Returns Determine Document Type and
Clearing Reason for Returns ). At the item level, you can manually change specifications such as the posting date and value date, as well as entries for taxes
and charges. However, you are not allowed to change the clearing reason and the currency.

1.6.2 Returns Category

Definition
Specifies the source of a return. The returns defined here are bank and check returns.

Use
Together with automatic account determination, the returns category identifies the G/L accounts for returns charges and the bank clearing account. By assigning
returns categories to Returns reasons , you ensure that different returns reasons can be used for different G/L accounts.

1.6.3 Returns Reason

Definition
A returns reason specifies the cause (from an internal business view) of a return. Examples of possible reasons include "insufficient funds" or "unknown account
number."

Use
The returns reason triggers a number of activities. The activities include charge handling, and setting dunning/payment locks and payment methods.
In Customizing you must assign the returns reasons given by banks to your own company-specific returns reasons. This allows you to treat different returns
reasons as defined by individual banks in a uniform way.

Structure
Using activity keys in Customizing, you can define multiple activities to be performed in the event of a return. The activity key is made up of the Company code ,
No. of returns , Creditworthiness , and Tolerance group fields.
For each returns reason, you can define lot charges based on currency and maximum permitted differences for the payment and return amount.

1.6.4 Creditworthiness

Use
The creditworthiness of a business partner provides information on the business partner’s payment history and influences the selection of activities for dunning
and/or returns and also the calculation of charges. Various different business transactions, such as returns, dunning notices, installment plans, and write-offs
update the creditworthiness in the system automatically. You can also transfer a creditworthiness record from external systems or manually. The current status of a
business partner’s creditworthiness is determined as a weighted total on the basis of the creditworthiness figures recorded over the last 48 months. You define the
monthly weightings in Customizing. A creditworthiness of zero means that the business partner has an excellent payment history. The maximum value is 9999.
The level of creditworthiness depends on:
Initialization in Customizing
The creditworthiness factor in percent
Manual creditworthiness

PUBLIC Page 6 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Number of dunning notices, returns, and write-offs
The creditworthiness figure is adjusted if a dunning notice or return is reversed.

Prerequisites
Time-dependent weighting
To determine the weighted total you have to make a time-dependent creditworthiness weighting in Customizing (see IMG structure Contract Accounts
Receivable and Payable Business Transactions Dunning and/or Returns Define Time-Dependent Creditworthiness Weightings).
Dunning
If you want to use creditworthiness determination, enter the dunning activities and/or dunning charges in conjunction with a creditworthiness figure. The dunning
activity run reads the current creditworthiness of a business partner and selects the dunning activity and dunning charge where the creditworthiness determined is
greater or the same as the creditworthiness value defined in Customizing.
You can define a creditworthiness weighting in the dunning levels of dunning procedures. Once dunning has taken place, the creditworthiness figure of the current
month is increased by this number.
You can define the creditworthiness figure in Customizing in each dunning procedure and dunning level (see IMG structure Contract Accounts Receivable and
Payable Business Transactions DunningNotices Configure Dunning Proce dure and Configure Charge Schedules for Dunning Procedure).
Returns
If you want to use creditworthiness determination, enter the returns activities in conjunction with a creditworthiness figure. During returns processing, the system
automatically determines the creditworthiness of a business partner, and, depending on this creditworthiness, the system selects the returns activity where the
creditworthiness value determined is greater or the same as the value defined in Customizing.
You can define a creditworthiness weighting in the returns reasons. Once returns processing has taken place, the creditworthiness figure of the current month is
increased by this figure.
You can define the creditworthiness weighting with the returns reason in Customizing (see IMG for Contract Accounts Receivable and Payable Business
Transactions Returns Configure Returns Reasons).
Write-offs
Write-offs can also have a negative effect on a customer's creditworthiness. If you want to use creditworthiness determination, enter the write-offs in conjunction
with a creditworthiness figure.
You can define the creditworthiness weighting with the write-off reasons in Customizing (see IMG for Contract Accounts Receivable and Payable Business
Transactions Write-Offs Configure Write-Off Reasons).
Installment Plan
In the Implementation Guide for Contract Accounts Receivable and Payable , under Business Transactions Deferral and Installment Plan , you can:
In the Define Categories for Installment Plan activity, define a creditworthiness number for each installment category. On the creation of an installment plan
it is assigned to the related business partner.
In the Define Deactivation Reasons for Installment Plan activity, for each deactivation reason, define whether a creditworthiness entry updated on creation
of the installment plan is to be reversed when the installment plan is deactivated.

Features
The system automatically determines the creditworthiness of a business partner in returns processing and in a dunning run. The creditworthiness influences the
activities and the charges levied, provided that you have defined the activities and charges dependent on creditworthiness in Customizing. There is a display and
change function for creditworthiness. The features are as follows:
You can display the automatically determined creditworthiness of every business partner in a creditworthiness history.Using the creditworthiness history you
can see an overview of when the creditworthiness of a business partner changed (SAP menu: Account More Information Creditworthiness ).
You can enter or change the creditworthiness manually. The manual creditworthiness is added to the value of the automatically determined creditworthiness,
and thus forms the overall creditworthiness of a customer.
You can enter a percentage creditworthiness factor for each business partner. You use this factor to weight the creditworthiness depending on the business
partner.
You can fix the current value of the automatically determined creditworthiness. The creditworthiness value can then only change for reasons relating to
creditworthiness, such as dunning or dunning notice reversal, but not for time-dependent reasons.
You can release this fixed value manually, so that the creditworthiness can change for time-dependent reasons.
You can enter or reverse a creditworthiness record manually or with a BAPI in the creditworthiness history. The system then determines the new
creditworthiness automatically.
For the creditworthiness of a business partner, SAP delivers the object type CA_CRDRTNG and the BAPIs contained therein.
Change documents record any entries or changes that you have made to the manual creditworthiness, as well as changes to the percentage creditworthiness
factor. If there is no data record for the current calendar year when you call the Change Creditworthiness function, the system automatically creates an initial
record. The initial record contains the current calendar year. All other values in the creditworthiness records are blank.

Activities
To display or change the creditworthiness of a business partner, choose one of the following paths:
Function
Business Partner Account Information(SAP_FI_CA_PARTNER_ACCOUNT_INFO) Display Business Partner Creditworthiness or Change
Business Partner Creditworthiness .
SAP Menu
Master Data Business Partner Display/Change Creditworthiness

1.6.5 Entering and Posting Returns Manually

PUBLIC Page 7 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Purpose
You must enter returns manually if for instance the bank reports returns in the form of return slips, checks come back uncashed or if payment could not be made
(also see Entering and Posting Returns Automatically ).

Procedure
You enter a new returns lot or change an existing returns lot (see Entering Returns Lots Manually ).

a. Specify data relevant to the returns lot in the header of the payment lot, and determine the Type of Posting . The system requires this data to clear charges
and taxes as well as to determine the bank clearing account to be used. You can also define the number of items as well as the amount of the credit or debit total
in the header of a returns lot. If you have chosen default values, the returns lot cannot be closed until the corresponding totals of the returns items entered match
the default values.
b. Depending on the screen variant you have chosen (see Screen Variants for Processing Returns Lots ), enter an item for every return, in which you enter the
amount, value date, returns reasons and payment document.
Once you have made all your entries, close the returns lot (see Closing a Returns Lot Manually .)
Post the returns lot (see Posting a Returns Lot Manually ).

When you post a return, a new open item is created. The use of this new item is dependent on the type of posting.
b. The activities defined in the system for a returns reason and other activities are carried out (see Executing Returns Activities ).
Edit any items shown to be incorrect during posting and post again (see Postprocessing a Returns Lot Manually ).
You can display returns lots that you have entered. In this display, the system also shows returns lots that have already been archived.

Result
Depending on the type of posting, the original receivables are re-opened, or new receivables are set. Different activities are executed depending on the system
settings.
Any necessary entries were added to the returns history (see Displaying the Returns History ).

1.6.5.1 Entering Returns Lots Manually

Procedure
To create a new returns lot manually or to supplement an already existing returns lot that has not been closed, proceed as follows .
1. Choose one of the following paths:
Roles
Returns Processing (SAP_FI_CA_RETURNS_PROCESSING) Process Returns Lot
SAP Menu
Payments Returns Returns Lot
The initial screen appears.
1. You can:
1. Choose a returns lot that already exists but has not yet been closed. To do this, specify the returns lot and select Edit Lot .
2. Create a new returns lot. To do this, enter a 12-character alphanumeric key and select Create Lot .
The screen for entering the return lot header data and the default values for individual items appears.

Note
To transfer the header data of an existing lot as the default for a new returns lot, choose Copy Reference on the header screen.

1. Enter the required data.

2. Select List or New items to reach the screen for entering individual items. Enter the required data or modify any existing values.

Note
You can define your own line layout via Extras - Screen Variant . This is useful if for example, you do not need the Value Date or Currency fields but still
want to see the Posting Date field (see Screen Variants for Processing Returns Lots ).

1. Return to the initial screen.

Result
Once you have made all your entries, you can close the returns lot (see Closing Returns Lots Manually ).

1.6.5.2 Closing Returns Lots Manually

PUBLIC Page 8 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.6.5.2 Closing Returns Lots Manually

Prerequisites
You have entered all the data for a returns lot (see Entering Returns Lots Manually ).

Caution
Once a returns lot has been closed, you can only change it if you have special authorization 012. (Exception when processing errors: See Postprocessing
Returns Lots Manually ).

Procedure
1. Choose one of the following paths:
Roles
Returns Processing (SAP_FI_CA_RETURNS_PROCESSING) Process Returns Lot
SAP Menu
Payments Returns Returns Lot
The initial screen appears.
1. Choose Close .

Result
The returns lot is now closed. This indicates that it is complete and ready to be posted.
You can now post the returns lot (see Posting Returns Lots Manually ).

1.6.5.3 Posting Returns Lots Manually

Prerequisites
You have entered the returns lot to be posted completely (see Entering Returns Lots Manually ) and have closed them (see Closing Returns Lots Manually ).

Procedure
1. Choose one of the following paths:
Role Returns Processing(SAP_FI_CA_RETURNS_PROCESSING) Process Returns Lot
SAP menu Payments Returns Returns Lot
2. Select the returns lot to be posted and choose Continue .
3. Choose Post .
A dialog box for scheduling the program run appears.
To display an online log after the posting run, choose Other Parameters and enter X in the Display Online Log field. Use the log file density to select how
comprehensive the log should be.
4. Choose Continue .
Enter the required data. If you want to execute the program immediately, set the Start Immediately indicator.

Result
The program run for posting the returns lot is scheduled. You can check the status of the lot at any time by entering the returns lot on the initial screen and
choosing ENTER . If any errors occurred during the posting procedure, you must postprocess the incorrect items in the returns lot manually (see Postprocessing
Returns Lots Manually ). Error messages for the corresponding items appear on the detail screen. If the posting transaction could not be executed because of
missing entries in the header of the returns lot, an error message appears on the tab page Clearing Account and Management. The job log provides you with full
details on how the posting took place, and you should be able to detect the reason for any errors that occurred. To view the job log, choose Job Overview in the
header and select the corresponding item by double-clicking on it . If you want to post a returns lot in the background and view a job log, select the
corresponding returns lot on the selection screen and choose Job Overview . Double-click on the corresponding item to view the job log.

1.6.5.4 Screen Variants for Processing Returns Lots

Use
You can use screen variants for processing items in returns lots. Using a screen variant, you can specify:
Which fields are displayed for processing
In what sequence and in which intervals the fields are displayed for processing
You can access this function on the screen for entering line items by choosing Extras Screen Variants in the menu (see Entering Returns Lots Manually ).

PUBLIC Page 9 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Activities
You specify which fields are displayed in the header in Customizing for Contract Accounts Receivable and Payables under Business Transactions Returns
Define Field Selection. .SAP provides the standard variant SAP01. You cannot modify this variant. However, when you create a new variant the system
copies the properties of this standard variant. You can then process these as you require.
In the next activity, Define Field Selection for Returns , you can specify which items appear in which order on the overview screen.
To create your own variant, copy the SAP standard variant and modify the attributes of the individual fields to meet your needs.

1.6.6 Entering and Posting Returns Automatically

Purpose
Returns are entered automatically if the bank sends a data medium with returns or if an external system provides a returns file (see also Entering and Posting
Returns Manually ).
Automatic posting of returns allows background processing (as batch sessions), which in turn results in higher data throughput.

Process Flow
1. Enter the program run parameters for automatic transfer of returns (see Entering Parameters for Automatic Returns Transfer ).
2. When the program is run, the data records from the application server file specified are read and checked. If the data records are correct, the system
generates one or more returns lots .
3. If you have set the appropriate indicators in the program run, the returns lots generated are closed and posted.
4. 1. When you post a return, a new open item is created. The use of this new item is dependent on the type of posting .
2. The activities defined in the system for a returns reason and other activities are carried out (see Executing Returns Activities ).
5. Edit any items shown to be incorrect during posting, and post them again (see Postprocessing Returns Lots Manually ).

Result
Depending on the type of posting, the original receivables are re-opened, or new receivables are set. Different activities are executed depending on the system
settings.
Any necessary entries were added to the returns history (see Displaying the Returns History ).

Note
If the program terminated during the automatic returns transfer, you can continue the transfer with a restart (see Program Termination: Continue Returns
Transfer ).

1.6.6.1 Entering Parameters for Automatic Returns Transfers

Prerequisites
The returns data provided by a bank or an external system must be converted to the format accepted by the program for transferring returns data and stored as a
file on an application server.

Procedure
1. Choose one of the following paths:
Roles
Transfer Bank Account Statement (SAP_FI_CA_BANK_ACC_STATMENT) Payment Lot Transfer
SAP Menu
Periodic Processing Transfer Data Returns Lot Transfer
1. The screen for entering returns transfer data appears.
2. Enter the required data. Change the default values on screen as necessary.
1. Enter a one to twelve character alphanumeric ID for the program run.
2. Choose Edit File as your processing mode. The program imports the file with the returns that is on the application server into the internal tables.
3. Specify the path as though you were going to work directly on the application server.
4. To close the lot, choose Close Returns Lot .
5. If you select Close Returns Lot , the returns lots created by the program run are closed directly. You can only change closed returns lots if you have
special authorization 012.
6. To post the lot, set the Post Returns Lot indicator in addition to selecting Close Returns Lot .
1. Choose Continue .

PUBLIC Page 10 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Result
If you have selected Close Returns Lot , the returns lots created by the program run are closed.
If you also selected Post Returns Lot , the returns lots generated by the program run are posted.
The job log provides you with full details on how the posting took place, and you should be able to detect the reason for an incorrect run. To view the job log,
choose Job Overview in the header and select the corresponding item by double-clicking on it . If you want to post a returns lot in the background and view a
job log, select the corresponding returns lot on the selection screen and choose Job Overview . Double-click on the corresponding item to view the job log.

1.6.6.2 Program Termination: Continue Returns Lot Transfer

Prerequisites
If the program terminated while the file was being processed on the application server, you can continue processing the file from the last item read.

Procedure
1. Choose one of the following paths:
Roles
Transfer Bank Account Statement (SAP_FI_CA_BANK_ACC_STATMENT) Returns Lot Transfer
SAP Menu
Periodic Processing Transfer Data Returns Lot Transfer
The screen for entering returns transfer data appears.
1. Enter the ID for the program run to be processed.
2. Choose Edit File after Termination as your processing mode.
3. Choose Execute .

Result
Processing is restarted from the last item read.

1.6.7 Posting to Clarification Account

Use
If, when you posted a returns lot, some of the items could not be cleared, you can post the returns to a clarification account to
Track items with a certain returns reason in clarification processing
Credit the returns clearing account

Activities
If you want a posting to a clarification account to take place for a certain returns reason, enter an account for the corresponding returns reason in Customizing (see
the Implementation Guide for Contract Accounts Receivable and Payable Business Transactions Returns Configure Returns Reasons ).
With report RFKKRLCL, you can display clarification items in a returns lot for a key date.

1.6.7.1 Postprocessing Returns Lots

Prerequisites
Incorrect or unassignable items arose when you posted a returns lot .

Procedure
1. Choose one of the following paths:
Role Returns Processing(SAP_FI_CA_RETURNS_PROCESSING) Clarification Processing: Returns
SAP Menu Payments Returns Clarification Cases The selection screen appears.
2. Make your selections.
3. Choose Continue .
The screen for postprocessing line items appears.
4. Edit the items. By double-clicking on individual items, you can display and correct them.
5. In the detail view, you can either post individual returns items directly, or change several items at once, thus allowing you to post the returns lot again.

Note
You can also transfer a returns lot that has not been completely posted to the general ledger. You have to create a new reconciliation key, so that the old

PUBLIC Page 11 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 reconciliation key can be closed and transferred to the general ledger. Use the new reconciliation key to carry out subsequent clarification.
When you reverse a return, the system opens the return in the returns lot. If the return can be reversed and Funds Management is not activated, the
system also opens the related returns lot.

Result
The incorrect returns lot items were corrected and posted.

1.6.8 Special Features in Processing Returns

For commercial reasons, the following special situations can arise when processing returns:

Special Case Activities

Payment cannot be canceled See Types of Posting

There are returns postings for documents from a legacy or operational system See Types of Posting

You have entered increased charges. See Charges Handling

1.6.8.1 Type of Posting

Use
The type of posting indicates how the returns document is posted.
For example, if a document has already been cleared by way of a cancellation or a final settlement, you must reverse this clearing before you can post the return.
The value selection offers a list of various types of posting that you can select, depending on the type of clearing.

Features

Type of Posting Procedure in the System

Cancel payment The system tries to cancel all clearings made by the payment document.

New receivables, if payment cannot be canceled The system tries to cancel the clearing. If this is not possible, it creates a new receivable
on the basis of the receivables document.
You can also use this method if the payment document has already been archived.

New receivables, derived from payment The system creates new receivables items without canceling the payment.
In this case, the data for the new items is derived from the items originally paid, and
enhanced by the Customizing settings.
In the case of a return for a collective bill, the system creates receivables in the individual
accounts and a new collective bill document for the total amount of the receivables. The
receivables are then visible in the individual account and in the collective account.
You can also use this method if the payment document has already been archived.

New receivables, acc. to explicit specification With this type of posting you can process documents from a legacy or operational system
for which there are no document numbers in the SAP system.
In this case, the system does not check the selection value you enter (such as the
document number of the operational system), but enters it as the reference value in the
posting to be created.
Switch to the Returns Details screen and enter the required posting data in the Manual
specifications tab card.

1.6.8.2 Charge Handling

Use
There are two types of charges for returns: those charged to your organization by your financial institution and the charges for which you make a business partner
liable.
Charges from a financial institution
The charges from a financial institution are
received automatically when a data medium from the bank is transferred (also see Entering and Posting Returns Automatically ).
The allocation of charges in a returns lot is automatic. How the charges are allocated depends on the form in which a financial institution provides data: integrated in
the returns amount, or as separate information on charges.
received when a returns lot is entered manually (also see Entering and Posting Returns Manually ).
If you activate the Amounts contain charges field, you define that the difference between the actual payment amount and the amount entered - within a specified
tolerance - is to be interpreted as a charge by the bank.
If you also activate the Charges contain taxes field, the system takes the bank charges as being gross charges. To identify which portion of the amount is for

PUBLIC Page 12 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 taxes, you must select a tax code. If you do not activate the Charges contain taxes field, the charges are taken as being net charges, and no calculation of tax
takes place. However, if you have set a tax code, the charge is calculated from the net amount.
If you activate the Accept charges field, the system accepts bank charges that are above the tolerance limit defined in Customizing.
In Customizing, you can decide whether or not to make a business partner liable for bank charges based on the returns reason, company code, creditworthiness,
and tolerance group.
Charges from your organization
The charges for which you make a business partner liable can be defined in Customizing on a scale according to amount limits in the returns reason. In this way,
you can decide which charges will be levied for which returns amount based on the returns reason, company code, creditworthiness, and tolerance group, and
whether these charges are to be posted statistically or to the general ledger.

1.6.9 Executing Returns Activities

Use
Various different activities may be required for returns:
No more collections are to be attempted from a bank account because the bank account no longer exists.
No more outgoing payments are to be made because the required incoming payments have not been received.
The responsible employee is to be informed via workflow.
Correspondence is to be created and subsequent activities requested (see also Printing Returns Notifications ).

Integration
Returns activities are based on the Returns Reason .

Features
In Customizing you can make the following settings for a returns reason based on company code, number of returns, creditworthiness, tolerance group, house
bankand so on (see the Implementation Guide for Contract Accounts Receivable and Payable Business Transactions Returns Configure Returns
Reasons) .
Activities for charge handling, such as making business partners liable for charges (see Charge Handling )
Set a dunning lock at contract account, item, or contract level
Set a payment lock at contract account, item, or contract level
Postpone a due date by defining deferral days
Scaled charges and amount differences
Delete the outgoing payment method in the contract account or contract in the event of credit memo returns
Delete the payment method in the item on which the return is based
Change the payment method in the item on which the return is based
In event 0292 you can set a new payment method in the item dependent on the existing payment method.
You can also define your own function modules for event 0295. These function modules execute other returns activities, or supplement existing activities. (See
also the documentation for the sample function module FKK_SAMPLE_0295)
In the different application areas (industry components), you can carry out further returns activities (see Executing further Returns Activities ).

Note
If you have defined returns activities dependent on the house bank in the system settings, you must specify the house bank in the returns header lot on the
tab page Clearing Account and Management .

Special Features for Check Returns

You can post outgoing checks that cannot be delivered or that have been returned as returns – instead of reversing the check payment in check management – if
additional activities, such as changing the payment method in the contract account are to follow automatically.

1.6.9.1 Printing Returns Notices

Use
When a returns lot is posted, the returns activities defined in the system are executed (also see Executing Returns Activities ).
One of the returns activities to be executed is the creation of paper records required for returns, such as a returns notification or a payment document.
The paper records are generated using functions in the Correspondence application component. You use the Print Workbench to define the application forms
required.

Prerequisites
The corresponding returns have been posted.You have already carried out the Customizing for correspondence (see the Implementation Guide for Contract
Accounts Receivable and Payable Basic Functions Correspondence). ).You have defined and assigned the necessary application forms (in the IMG, see
Contract Accounts Receivable and Payable Basic Functions Print Workbench DefineApplicationForms ).

PUBLIC Page 13 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Activities
If you have not already done so, post the returns lot manually (see Posting Returns Lots Manually ) or automatically (see Entering Parameters for Automatic
Returns Lot Transfer ).
When the returns lot is posted, the returns reasons defined in the contract account master record are used to determine the data related to correspondence (such
as business partner or contract account), which is then stored in the correspondence container (also see Creating Event-Driven Correspondence ).
Enter and schedule a correspondence printing run (see Printing Correspondence ).
In a correspondence printing run, the selected correspondence data is read from the correspondence container, supplemented with other data where necessary
and output in the printer spooler.
The correspondence data is available in the printer spooler either in raw data format or SAP script format.
You can view the job log for the correspondence printing run (see Displaying Job Logs for Correspondence Printing Run ).

1.6.10 Displaying the Returns History

Prerequisites
At least one returns lot was entered, closed, and posted successfully.

Procedure
1. Choose one of the following paths:
Roles
Business Partner Account Information (SAP_FI_CA_PARTNER_ACCOUNT_INFO) Returns History
SAP Menu
Account Other Information Returns History
The initial screen for entering selection conditions appears.
1. Enter the data required for selection.
Specify any display variants you wish to use.
You can structure the result list with predefined display variants (see below).
1. Choose Continue .
All those returns that match the criteria you entered are displayed.
You can adapt the current display variant to your needs.
1. Choose Settings Display Variant Define .
2. The dialog box for modifying the display variant appears.
3. Select the fields you require and confirm your selection.
To save the display variant, choose Settings Display Variant Save . A dialog box for saving the display variant appears.
1. Enter the required data and save.
The newly-defined display variant has been saved.

Result
The returns history is displayed.

1.6.11 Execution of Further Returns Activities

Use
In addition to the activities listed in Execution of Returns Activities , the system can also execute the following activities:

Resumption of a Dunning Procedure

If a running dunning procedure is ended by converting a payment method to automatic debit, and if the automatic debit actually leads to a return, the dunning
procedure is automatically returned at the same dunning levelat which it was ended.

1.7 Deferrals and Installment Plans

Purpose
This component enables you to defer payment or arrange payment by installments for business partners who cannot keep up their payment obligations. If a
deferral has been agreed, a deferral date is noted in the open item in addition to the due date. The deferral date has the effect that no dunning notices are sent and
no payments are collected during the agreed deferral period. Once the deferral date has passed without payment being made, the open item is dunned and bank
collection is executed again. If payment by installments has been agreed, you create an installment plan for the amount of the original receivable. The individual

PUBLIC Page 14 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 installments and their due dates are specified in the installment plan. You can levy charges for the facility of offering an installment plan. To avoid having due
dates fall at the weekend or on public holidays, you can refer to the factory calendar when determining these dates. The individual installment, rather than the
original receivable, is included in dunning and in the payment run.

Integration
If you are using the Item Interest Calculation component, you can calculate interest on the installment plan.

Features
You can delete installments that have not yet been paid, and change the amount of an installment (repayment and interest) or the due date. You can add
installments to an active installment plan. The sum of the installments in an installment plan must always be equal to the sum of the original receivables entered
in the installment plan. Provided the installment plan is active, in the account balance display and the installment plan, you can call up the receivables in an
installment. The document number of the installment plan is recorded in the original receivables, which ensures there is a link between original receivable and the
installment plan. When an installment is paid, the payment is automatically spread over the source receivables. When the final installment of an installment plan
is paid, both the installment plan and the original receivable are cleared by the payment program when the incoming payment is posted. Installments can be
partially paid. If the agreement for payment in installments is canceled, you can deactivate the installment plan manually. This means that the original receivable
becomes active again and the link between the original receivable and the installment plan is deleted. A deactivated installment plan cannot be reactivated, and
no further payments can be assigned to the installment plan.
With appropriate Customizing settings for the insallment plan categories, when you create an installment plan, you can update the creditworthiness of the
business partner concerned. With appropriate Customizing settings for the deactivation reasons, you can reverse the creditworthiness entries.

Industry ComponentUtilities(IS-U)
An installment plan can be deactivated automatically by the dunning run when a certain dunning level is reached. You define the forms for correspondence with
business partners who have arranged to pay in installments with the Print Workbench component.

1.8 Promise to Pay

Purpose
You use a promise to pay to record a business partner's agreement to pay receivables that are on his or her account.

Integration
For dialog processing, you can use a user interface in the Interaction Center Web Client .

Features
A promise to pay states which amounts are to be paid by what dates.

Example
A promise to pay can specify that the business partner payment is in the form of a debit memo or a direct debit.

Since the payment dates defined in the promise to pay are generally after the due dates of the items covered by it, you can (optionally) add charges and interest
on late payments as part of the promise to pay.
You can create , approve , withdraw , change and valuate promises to pay.
These activities are all performed online, with the exception of the valuation, which is a mass activity. Using the functions of valuation of promises to pay , you
can:
Close promises to pay.
For this you plan mass runs at periodic intervals.
Determine the extent to which promises to pay were kept.
If the promise was not kept, then the system can update the credit standing of the business partner.
The system puts currently running dunning procedures for the business partner on hold until the promise to pay is closed.
When you create a promise to pay for overdue items, the system does not open a new dunning procedure for these items – assuming you create the promise to
pay before the dunning run.

1.9 Write-Offs

Purpose
You use this component to charge off open receivables and credits of a business partner. You carry out write-offs if receivables are uncollectible or payables
cannot be disbursed, such as when the payee cannot be identified.

PUBLIC Page 15 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Features
You can write off open receivables completely, or, if you want to waive partial amounts of open receivables for your customers, you can also write off partial
amounts of open items. You are therefore free to specify the partial amount to be written off in the transaction Write Off Items . You have to allow partial write-offs
explicitly in Customizing. In this activity the written off line items are cleared and a write-off document is created. The system automatically makes a posting to the
expense or revenue accounts defined in Customizing. You can reverse write-off documents, meaning that the receivables or payables become open again.
In Customizing, you can define rules for adjusting the tax for a write-off. If the expense account posted to is relevant for tax, the system also corrects the tax posted
when you write off.
Using a function module, you can also specify check rules in Customizing that the system uses to decide whether and which open items of a business partner
can be written off. For example, you can specify that receivables can only be written off if there are no credit items on the contract account and the receivables are
more than six months overdue. If a user has the appropriate authorization, he can write off all open items. This means that the check rules are not applied. The
system always applies check rules at a check level (business partner, contract account, contract, document), groups the open items to be written off at check
level, and applies the check rules to each group.
You can update the creditworthiness of a customer for write-offs.

1.10 Submitting Receivables to Collection Agencies

Purpose
If a customer does not pay his receivables, and all measures have been taken to collect the receivables, many companies use collection agencies to prevent
losing the receivable.
In the case of receivables for which court cases have been initiated or where a court order has been issued for collection (legal dunning proceedings), these
receivables are managed in some instances using third-party applications.
Contract Accounts Receivable and Payable enables you to manage postings connected to submitting receivables to a collection agency and the exchange of
information with those collection agencies.
For managing receivables for which legal dunning proceedings have been initiated, it is necessary to set up collection agencies in Contract Accounts Receivable
and Payable for the third-party applications that are used.

1.11 Transferring Open Business Partner Items

Purpose
Transferring receivables or credits is necessary if a business partner assumes the rights and obligations of another business partner, such as in the case of
inheritance or taking on liabilities. From time to time it might also be necessary to transfer receivables or credits within different contracts or contract accounts of
the same business partner. This is the case, for example, if a customer terminates a contract, but the remaining receivables are to be collected together with the
receivables for the new contract.

Features
During the transfer, the system clears the selected items and posts them to the target account. Most of the posting information is transferred. 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 maintain transactions for the transferred items in Customizing for Contract Accounts Receivable and Payable under Business
Transactions → Transfers → Define Transactions for Transferring Items . During the transfer, the system does not perform account determination again for the
new items. However, this makes it easier to read the account balance display, since you can recognize the transferred items directly from the transaction and
transaction text. In event 5110, you can define whether existing payment and dunning locks are retained. If the target account for the transfer posting is a contract
account that belongs to a collective bill account, the collective bill is updated automatically.
You can transfer:
Individual items – receivables and credits (see also the explanations for transfer postings in Clarifying Credits )
All items of a business partner
All items of a contract account
All items of a contract
Items from an installment plan In this case, existing installment plans are deactivated automatically and a new installment plan is created for the amount of the
remaining open, original receivables.
Items that belong to a collective bill The collective bill is updated automatically.
You can also reverse the transfer document.
For more information about transferring, see SAP Note 616098.

Constraints
You can only transfer open receivables or credits. When the transfer is made, the system does not determine any new G/L accounts for the posting. This means
that no new postings are made to receivables and revenue accounts. If the original contract account also contains items assigned to contracts, you have to enter a
target contract for each of the contracts determined by the transaction. You can only carry out the transfer without specifying a target contract if the target contract
account is not based on contracts. If the original contract account has postings that are only assigned to contract accounts, then the system also posts them in this
way in the transfer document. In this case, specifying a target contract is irrelevant.
In event 5100 you can override the stipulation that you have to enter a target contract for items that were originally posted to a contract.

1.12 Business Partner Duplicates

PUBLIC Page 16 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.12 Business Partner Duplicates

Use
This component allows you to import business partner duplicates into the Collections/Disbursements (FS-CD) system from operational systems, and to process
them with follow-up activities. For example, you can transfer the open items for a source business partner to a target business partner, or adjust open payment
plan items for the source business partner.

( )
Note that the functions for duplicate processing are only available with Support Package 9 for the SAP ECC Industry Extension Insurance 6.0 release.

Integration
Collections/Disbursements assumes that the operational system for the source business partner identified when importing the business partner duplicate does not
deliver new posting data, so that the existing posting documents and associated histories can be retained and then archived after a certain period of time.

Features
The processing of business partner duplicates includes the following functions:
Import Business Partner Duplicates
Processing of Business Partner Duplicates
Processing of Clarification Cases from Duplicate Processing
Display of Business Partner Duplicates

Constraints
Collections/Disbursements does not perform merging or cleanup of the business partner duplicates (master data duplicate cleanup), but only processes
the delivered information about duplicates and derives follow-up activities for the posting functions in Collections/Disbursements.
Also take note of the following information:
The SAP Business Partner component offers a specific data cleanup function for this component in the standard software.
The function in the SAP Business Partner is not released for Collections/Disbursements (FS-CD).
( )
We recommend that you clean up the master data for the duplicates in the operational systems.
When processing business partner duplicates, no open items are transfer posted for deposit contracts. If deposit contracts are to be processed, the system
generates a clarification case. You can transfer post the appropriate open items with Processing Insurance Objects with Balance Interest Calculation .

1.12.1 Import of Business Partner Duplicates

Use
You can use this function to import delivered business partner duplicates from operational systems to Collections/Disbursements (FS-CD).
You can perform the import of business partner duplicates manually, or as a mass activity with the RFC-ready interface FKK_BPCL_IMPORT ( Import Business
Partner Duplicates ).

Integration
After importing the duplicates, you can execute the following functions:
Processing of Business Partner Duplicates
Processing of Clarification Cases from Duplicate Processing

Activities
To import business partner duplicates, on the SAP Easy Access screen choose Collections/Disbursements Master Data Business Transactions
Duplicate Processing Import Business Partner Duplicates .
The system displays the Import Business Partner Duplicates screen (for the report RFKK_BPCL_IMPORT ( Import Business Partner Duplicates )).
Enter the number of the source business partner to be replaced and the number of the new target business partner.
If you want to reverse a business partner duplicate and the associated processing activities (because you have determined that the business partner pair in the
operational system is not a duplicate, for example), set the Reversal flag. For business partner duplicates delivered as reversals, the system automatically
generates a clarification case, which you must process manually with the Process Clarification Cases from Duplicate Processing function.

1.12.2 Processing of Business Partner Duplicates

Use

PUBLIC Page 17 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 You can use this function to process follow-up activities for business partner duplicates delivered from operational systems.
The operational system uses the Import of Business Partner Duplicates function to deliver information about the existence of a business partner duplicate to the
Collections/Disbursements system.
Collections/Disbursements determines the existing target and source master data combinations for the business partner to be replaced, and triggers the activities
defined in Customizing for processing each combination.
In the standard software, Collections/Disbursements delivers the following activities for processing the business partner duplicates:
Transfer posting of associated open items (activity 010)
Adjustment of open payment plan items (activity V01)
Another customer-defined activity could be setting posting locks for the "old" contract account, for example.
For the Transfer Posting Associated Open Items activity, you can define that the dunning level for the open item is also transferred. You can define the
appropriate setting for the transfer reason in Customizing for Collections/Disbursements , under Business Transactions Transfers Define Specifications
Dependent on Transfer Reason .

( )
During this import of business partner duplicates, if information about a business partner pair no longer being a duplicate is delivered (delivery of a reversal), note
that the system does not automatically reset processing activities for the reversal, but that you must manually set these activities to Complete , by using the
Processing of Clarification Cases from Duplicate Processing function.

Prerequisites
The source and target master data combinations are derived directly from the insurance object for the source business partner. This means that you have
created an insurance object-business partner relationship for all insurance objects for the source business partner, for the target business partner.
You have entered the Customizing settings for the clean-up of duplicates, under Collections/Disbursements Business Transactions Duplicate
Processing Define Activity for Duplicate Processing, Define Order of Activities and Define Specifications for Transfer Posting Open Items .
Collections/Disbursements has received the information from the operational system (using the Import of Business Partner Duplicates function) that it is to
process a business partner duplicate.

Activities
To allow you to perform follow-up activities for business partner duplicates, on the SAP Easy Access screen choose Collections/Disbursements Master
Data Business Transactions Duplicate ProcessingProcess Business Partner Duplicates .
You are now on the Process Business Partner Duplicates screen (for the report RFKK_BPCL_PROCESS ( Process Business Partner Duplicates )).
Enter the business partner pair (source and target business partner) that you have recognized in your operational system as business partner duplicates and
define the posting date and document date from which the documents for the source business partner to be replaced are to be taken into account.
You can execute processing for business partner duplicates in two steps:
1. If you set the flag under Determine Activities , the Collections/Disbursements system determines the activities to be executed and creates the processing
case.
In the background, the system executes the function module FKK_BPCL_CREATE ( Create Processing Case for Business Partner Duplicates ):
This determines the valid source and target master data combinations for the business partner duplicate. The Collections/Disbursements system
makes this determination in the application-specific event 7510. The result of the event is compared with the delivered master data combinations for
the imported function module.
This determines the activities that are to be executed for the identified master data combinations.
2. If you set the indicator under Execute Activities, the system processes the duplicates.
In the background, the system executes the function module FKK_BPCL_PROCESS ( Execute Activities for Business Partner Duplicates ). The system
executes the activities defined in Customizing for the identified master data combinations, in the sequence set. Each activity is executed in an LUW. All
messages for the activities are written to an application log for each data processing case, regardless of the time of execution.
If a processing step fails (if the system cannot execute an activity for a master data combination, for example), the system also writes the error to the application
log. The system creates a clarification case for these business partner duplicates.
You can find more information about processing the clarification case and displaying the application log under Process Clarification Cases from Duplicate Clean
Up .

Result
You have transfer posted existing open items for the source business partner to the target business partner, and adjusted open payment plan items for the
business partner duplicates.
You can also display the business partner duplicates with Display Business Partner Duplicates .

( )
When processing business partner duplicates, no open items are transfer posted for deposit contracts. If deposit contracts are to be processed, the system
cancels the action, outputs a message and generates a clarification case. You can transfer post the appropriate open items with Processing Insurance Objects
with Balance Interest Calculation .

Example
The operational system informs the Collections/Disbursements system that two business partners with the name Adam Smith and the business partner
numbers 4711 and 6510 are business partner duplicates. The business partner with number 4711 is the source business partner and is to be replaced by the
subsequent business partner 6510. The business partner 6510 and the insurance contract CUST01 have also already been created in the
Collections/Disbursements system. The function for duplicate clean up finds the following source and target master data combination for this business partner
duplicate: Business partner 4711 has insurance contract CUST01 with account 4567, business partner 6510 has insurance contract CUST6 with account 3645.

PUBLIC Page 18 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 The system creates a uniquely identifiable processing case for this business partner pair and transfer posts open items from insurance contract CUST01 to
insurance contract CUST06.

1.12.3 Processing of Clarification Cases from Duplicate

Processing

Use
If an error occurs when the system is processing business partner duplicates , or if the operational system sends the reversal of a business partner duplicate,
the system automatically creates a clarification case.
You can use this function to set the status for the processing case to Complete , or to execute the activities for processing the delivered business partner
duplicates again.
For delivered reversals, you can manually set the activities that are no longer to be executed to Complete , to reset them in this way.

Prerequisites
You have informed Collections/Disbursements (FS-CD) about the business partner duplicate, using the Import Business Partner Duplicates function, and you
have started the processing of business partner duplicates . This writes errors or reversals to the application log for the processing case.

Activities
To process clarification cases from processing of business partner duplicates in Collections/Disbursements, choose Master Data Business Transactions
Process Clarification Cases from Duplicate Processing from the SAP Easy Access screen for Collections/Disbursements .
You are now on the Selection Screen: Clarification of Duplicates .
You can restrict the selection of clarification cases to be processed by entering the specified selection criteria.
After selection, choose the clarification case to be processed from the worklist, and choose Clarify .
The system shows you the processing status for the business partner duplicate.
When processing the clarification case, you can choose the following steps:
You can display the Application Log
You can execute failed activities again ( Execute Activities )
You can use Activate Status to set the status for open activities to Manually Processed .
You can use Complete to set the status of the processing case to "Completed"

1.12.4 Display of Business Partner Duplicates

Use
You can use this function to display business partner duplicates, using various selection criteria.
The display for business partner duplicates includes the following data:
Client
Source business partner number
Source business partner contract
Source business partner account
Subapplication in Contract Accounts Receivable and Payable
Target business partner number
Target business partner contract
Target business partner account
Status of duplicate processing case
Name of the processor who processed the business partner duplicate
Date of last change
Time of last change
GUID for duplicate clean-up case
From a technical point of view, the system displays the contents of the DFKKBPCL ( Business Partner Duplicates: Predecessor-Successor ).

Activities
To display business partner duplicates, on the SAP Easy Access screen choose Collections/Disbursements Master Data Business Transactions
Duplicate Processing Display Business Partner Duplicates .
You are now on the Display Business Partner Duplicates screen.
You can restrict the display of business partner duplicates, using the following selection criteria:
Number, contract and account for the source business partner
Number, contract and account for the target business partner

1.12.5 BP Duplicates in Account Balance Display and Account

PUBLIC Page 19 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.12.5 BP Duplicates in Account Balance Display and Account
Maintenance

Use
You can also process open items from business partner duplicates in the account balance display and in account maintenance.

Prerequisites
Identified business partner duplicates exist for the business partner to be processed in account maintenance, or for which the system is to display the account
balance, and these were processed with the Processing Business Partner Duplicates function.

Activities
You are now on the Account Maintenance: Process Open Items screen, or Account Balance: Basic Maintenance .
( SAP Easy Access screen under Collections/Disbursements Account Maintain and Collections/Disbursements Account Account Balance
)
Choose ( ) with the quick info Predecessor/Successor .

( )
The Predecessor/Successor function is only provided if business partner duplicates actually exist for the selected business partner.
The system shows you which business partner duplicate is the predecessor or successor for the selected business partner.
If you choose Display All Data , the system selects all items for all business partner duplicates and displays them in the Account Balance Display or in
Account Maintenance .

( )
Account Maintenance , the system only takes the numbers for the BP duplicates into account, and no other selection criteria such as Contract Account,
Contract, Currency or Net Due Date .
In the Account Balance Display , the system only takes the numbers for the BP duplicates, the list category and the posting date into account, and no other
selection criteria such as Contract Account and Contract .
If you choose Cancel , you return to the Account Balance Display or Account Maintenance for the selected business partner and the system only displays the
items for the selected business partner.

( )
The Predecessor/Successor function is not available in the Account Balance Display in the following cases:
You have selected the option All Items for Business Partner .
You have selected the Account Balance: Basic List with a specific account balance role

Example
Three processed business partner duplicates exist in the system for business partner Adams. The duplicates are managed in the system with the business
partner numbers BPCL1, BPCL2 and BPCL3. In the Processing Business Partner Duplicates function, you have made settings for business partner BPCL2 to
replace business partner BPCL1, and then for business partner BPCL3 to replace business partner BPCL2.
You display the account balance for business partner BPCL2.
If you choose Predecessor/Successor , the system display the existing business partner duplicates BPCL1 and BPCL3 as the predecessor or the successor.
If you then select Display All Data , the system also displays the open items for business partner duplicates BPCL1 and BPCL2 in the account balance for
business partner BPCL2.

1.13 Policyholder Change

Use
( )
Note that the functions for policyholder change are only available with Support Package 9 for the SAP ECC Industry Extension Insurance 6.0 release.
You can use Collections/Disbursements (FS-CD) to process information about policyholder changes delivered by operational systems. In the
Collections/Disbursements system, you can execute the following processing steps:
Adjust open payment plan items so that the debit entry takes place on the new policyholder. The date of change can also be in the past. If open items have
already been produced, these are transfer posted (if required).
Transfer post open items to a new policyholder (optional)
You can use event V810 ( FS-CD: Additional Activities for Policyholder Change ) to integrate customer-specific activities within the policyholder change
The adjustment of the open payment plan items and the transfer posting of open items takes place on the due date, if no settlement period is filled
(ABRZU/ABRZO fields in the table DFKKOP Items for Contract Accounting Document are empty) in the associated document.
The adjustment of open payment plan items and the transfer posting of open items takes place in the associated document, if the settlement period is filled and
the lower limit for the settlement period (ABRZU field) is later than the date of change.

( )

PUBLIC Page 20 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 A customer has agreed a contract with monthly installment payments. This includes installments for the settlement period 01/03-31/03 and for the settlement
period 01/04-30/04. The policyholder change takes place on 15/03 and the settlement period is defined in the document. The adjustment of open payment plan
items takes place from the settlement period 01/04-30/04.
It is possible to change policyholder assignment more than once for an insurance object-business partner relationship. It is only possible to set more policyholder
changes for the current policyholder. The business partner most recently set for a policyholder change is regarded as the current policyholder. You can find more
information under Example for Multiple Policyholder Changes .
You can also change the validity date for a policyholder change that had already been created.
You can make the policyholder change from the SAP Easy Access menu or with the RFC-ready function module FSCD_CPH_PROCESS ( Execute Policyholder
Change ). This function module allows the operational system to provide Collections/Disbursements with information that a policyholder change is to be
processed.

Integration
After associated insurance object-business partner relationships have been archived or deleted, you can also delete data that is no longer required for
policyholder changes. You can find more information under Deletion of Data for Policyholder Change .

Prerequisites
You have adjusted the master data for the policyholder change in the operational system, and created the new policyholder and the insurance object-
business partner relationship.
If you also want to transfer post open items to the new policyholder, you have defined the document type for the transfer posting document and the transfer
posting reason in Customizing for Collections/Disbursements , under Business Transactions Policyholder Change Specifications for Posting Open
Items (transaction VCPH3).

Activities
To change the policyholder, choose Collections/Disbursements Master Data Business Transactions Perform Policyholder Change in the SAP Easy
Access menu.
You are now on the Perform Policyholder Change screen (transaction VCPH1 Policyholder Change ).
Enter the following selection criteria:
Insurance Object
Policyholder to be replaced ( Policyholder; Previous )
New policyholder ( Policyholder; Next )
Validity date for the policyholder change ( Date of Policyholder Change )
You can also execute the report in simulation mode and use the Transfer Open Items option to define that the open items for the policyholder are to be transfer
posted to the new policyholder from the date of change.

( )
You cannot set a policyholder change for deposit contracts. To transfer post deposit contracts, use Process Insurance Objects with Balance Interest Calculation .

Example
The Collections/Disbursements system receives the information that business partner 4711 Adam Smith will become the new policyholder for insurance contract
7894 on 01/06/2007, replacing business partner 5461 Fred Smith as policyholder. You can use this report to set the debit entry for open payment plan items to
the new policyholder, and also to make any other changes. If a debit entry is executed after the date for the policyholder change and the execution of the
policyholder change, corresponding documents occur for the new policyholder Adam Smith .

1.13.1 Deletion of Data on Policyholder Change

Use
You can use this function to delete data that is no longer required for policyholder changes.

Prerequisites
You have performed policyholder changes that are no longer up-to-date.
You have archived or deleted the associated insurance object-business partner relationship.

Activities
To delete data that is no longer required for policyholder changes, on the SAP Easy Access screen under Collections/Disbursements choose Periodic
Processing Delete Data Policyholder Change .
You are now on the Deletion of Data for Policyholder Change screen (transaction VCPH2).
As the selection criterion, enter the date before which the entries are to be deleted.
You can also execute the report in simulation mode and define the block size to be processed.

PUBLIC Page 21 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.13.2 Example for Multiple Policyholder Changes
Three policyholder changes take place for insurance object 4711. The policyholder assignment switches from business partner 1 to business partner 2, from
business partner 2 to business partner 3, and from business partner 3 back to business partner 1.
The policyholder changes take place at the following change times: Business partner 1 is policyholder until 31/12. Business partner 2 is policyholder from 01/01-
30/06, business partner 3 is policyholder from 01/07-31/07. From 01/08, business partner 1 becomes the policyholder again. This illustration shows these
changes over time:

The policyholder changes can be processed by the system in the sequence described above.

( )
If you wanted to make a policyholder change from business partner 1 to business partner 3 on 30/01, the system would reject this change as business partner 2
is the active policyholder at this point in time.
If you would like to make a policyholder change from business partner 1 to business partner 3 on 05/08, the system would do this as business partner 1 is the
active policyholder at this point in time.

1.14 Provisional Premium Requests

Use
When insurance contracts are concluded, there may be a time delay between the conclusion of the contract and the calculation of the exact amount that is to be
paid as the premium.
Since insurance companies do not want to delay collections until the final calculation is available, it is possible to create provisional estimates for premiums and
import them into Collections/Disbursements (FS-CD) as estimated items.
These are referred to as provisional premium requests, and are treated by the system as statistical down payment requests that are not relevant for the general
ledger. Instead, they can be used to initiate provisional payments from customers and correspondence.
At a later date the exact final premium is calculated by the insurance company and transferred to Collections/Disbursements. Then the provisional premium
requests are cleared, and the payments received from customers ( down payments on premium requests) are cleared against the premiums.
It is also possible to transfer more accurate estimates as they become available to Collections/Disbursements before the final exact premium has been
calculated. In this case, the previous provisional premium requests are cleared, and the down payments received from the customer for the premium requests are
cleared against the more accurate estimate (the current provisional premium request).

Features
Clearing of Provisional Premium Requests
Processing of Clarification Cases from Provisional Premium Request Clearing

1.14.1 Clearing of Provisional Premium Requests

Use
You can use this function to clear provisional premium requests, premiums and down paymentsmade by the customer against provisional premium requests.
For more information about the business scenario upon which this function is based, see provisional premium requests .

Prerequisites

PUBLIC Page 22 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Provisional premium requests are derived from the main transactions and subtransactions that you define in Customizing. When you entered the parameters
for the main and subtransactions, you flagged provisional premium requests as statistical down payment requests and set the Item Is a Provisional
Premium Request Suitable for Clearing indicator. You can find these settings in Customizing for Collections/Disbursements under BasicFunctions
Postings and Documents Document Maintain Document Assignments Edit Transactions forSAP Insurance (FS-CD) Define and Parameterize
External Transactions.
In order to allow clearing of provisional premium receivables, define the document type to be used in Customizing for Collections/Disbursements , under
Business Transactions Provisional Premium Receivables Define Specifications for Clearing .
In each document for a provisional premium request or premium you need to have specified a settlement period (fields ABRZU/ABRZO in table DFKKOP
Items in contract account document ).
If a document has more than one item, they must all have the same settlement period. You need to specify the settlement period for each document so that
the system can determine which document is current in a given settlement period.

Features
The first step in the settlement process is the import into Collections/Disbursements of the first provisional premium request that can be cleared.
Once this has been imported, other items required for the clearing process can then be imported into Collections/Disbursements.
New provisional premium requests (value is the best estimate) that can be cleared
Final premium amount
Customer down payments on provisional premium requests
So that these imported items are processed only when provisional premium requests are cleared, when they are posted they are assigned a clearing restriction to
prevent them from being included in other processes.

( )
For more information about how clearing restrictions affect items that are to be cleared, see Restrictions on the Clearing of Provisional Premium Requests .
As soon as there is a more accurate estimate than the existing provisional premium request, or if the final premium for a contract account is imported, the system
automatically does the following in the clearing run:
1. The system clarifies which items (provisional premium requests, premiums, and down payments on premium requests) can be grouped together in one
clearing group. It groups the items of a contract account by the following criteria:
Insurance Object
Contract Account
Business Partner
Currency
Settlement Period
2. The system identifies the most recent item for clearing (premium or provisional premium request) within a settlement period. As soon as the system
identifies a premium for the settlement period, this is then the most recent item for clearing. If the system does not find a premium, it then takes the most
recent provisional premium request for clearing.
( )
If debit items are selected, the system takes the creation date of the corresponding payment plan item. For all other documents the system uses the CPU
date of the document.
The next steps depend on the type of the most recent item that is relevant for clearing:

The most recent item relevant for clearing is a premium

1. The clearing restriction is deleted from the premium and from all provisional premium requests.
2. All the provisional premium requests found for the settlement period in question are cleared.
3. The clearing restrictions on down payments on premium requests are deleted, since these no longer have to be reserved for the provisional premium
requests.
4. Any down payments that were made for premium requests are cleared against the premium.

The most recent item relevant for clearing is a provisional premium request
1. The clearing restrictions are deleted for provisional premium requests that are out-of-date.
2. Any provisional premium requests that are out-of-date are cleared.
3. The clearing restriction on the current premium request is deleted.
4. Down payments received for premium requests are cleared against the most recent provisional premium request.
5. The contract account is included in the next settlement runs until a premium is posted and cleared for the settlement period in question.
If the clearing run cannot process an account automatically, the system creates a clarification case.

( )
Note that not all steps are mandatory. For example, it may be the case that a premium replaces a provisional premium request, yet the customer has not made a
down payment on the provisional premium request. In this instance only the provisional premium request is cleared.

( )
Payments on accountare not included in the clearing of provisional premium requests.

Activities
You can clear provisional premium requests as follows:
On the SAP Easy Access screen, choose Collections/Disbursements Periodic Processing For Contract Accounts and Insurance Objects Clear
Provisional Premium Requests and start the processing for mass data. You can add the mass activity to a job chain that could also include the debit
entry, for instance.
On the SAP Easy Access screen, choose Collections/Disbursements Account Provisional Premium Requests Clear Provisional Premium
Requests . Before you start the clearing process, select the requests by specifying the business partner, contract account, and insurance object.

PUBLIC Page 23 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 If the system is unable to clear a contract account, it creates a clarification case. You can process the resulting clarification cases in the Process Clarification
Cases from Clearing function (see also Processing of Clarification Cases from Provisional Premium Request Clearing ).

Result
For a contract account, you have cleared provisional premium requests against different combinations of provisional premium requests, premiums, and down
payments on premium requests.
The completion of the clearing run results in the following situation:
If a premium was posted, once the contract account has been cleared the system no longer contains any provisional premium requests because these
have all been cleared.
If no premium was posted, after the contract account has been cleared there can be only one current provisional premium request per settlement period. All
the older provisional premium requests were cleared.
You can check that the clearing process was successful by displaying the account balance (see also Account Balance Display ).

Example
Examples Showing the Clearing of Provisional Premium Requests

1.14.1.1 Restriction on the Clearing of Provisional Premiums

Premiums and down payments on premiumsare posted when they are imported into Collections/Disbursements (for example, using the debit entry function). The
items are cleared in the Clear Provisional Premium Request function. Until the items are cleared, the system has to prevent the imported items from being
processed further, such as in a payment run, for instance. This is to ensure that the items are not debited twice.
This is done by entering clearing restriction F ( Automatic Clearing of Provisional Premium Requests (FS-CD) ). The following rules apply for the use of the
clearing restriction for items:
Each provisional premium requestthat can be cleared is posted with the clearing restriction.
If provisional premium requests have already been posting for the settlement period, incoming premiums are also posted with the clearing restriction. This is
necessary because existing provisional premium requests have to be posted first in the clearing process. The clearing restriction remains in place for the
premium until it is settled when provisional premium requests are cleared.
This is necessary because the clearing run must clear these against the most recent provisional premium request so that the open amount is displayed
correctly in the contract account.
Once a premium has been cleared, there are no clearing restrictions for subsequent premiums.
( )
If you want to lock down payments on premium requests so that they are not handled in subsequent processes, in Customizing you can enter clearing
restriction F for the relevant main transactions and subtransactions. You enter this setting in Customizing for Collections/Disbursements under Basic
Functions Postings and Documents Document Define Account Assignments for Automatic Postings Define Account Assignments for Down
Payments and Charges . If you enter clearing restriction F for the relevant main transactions and subtransactions, down payments for provisional
premium requests are also posted with the clearing restriction. In this IMG activity, you can also enter a payment lock reason for down payments.
The clearing run deletes the clearing restriction for down payments for provisional premium requests only if a premium is imported into
Collections/Disbursements and the down payment can be cleared against the premium.
( )
In the account maintenance function, you cannot process open items that are assigned clearing restriction F ( automatic clearing of provisional premium
requests (FS-CD) ). If you want to process the open items, you can delete the clearing restriction manually by choosing Collection Disbursements
Document Changeor MassChangeon the SAP Easy Accessscreen.

Requirements for Using the Clearing Restriction and Clarification Case Processing
In Customizing under Collections/Disbursements Basic Functions Open Item Management Define Modifiable Clearing Restrictions you have entered
clearing restriction F ( automatic clearing of provisional premium requests (FS-CD) ). You need to have entered this setting so that you can remove clearing
restrictions on the SAP Easy Access screen under Collections/Disbursements Document ChangeorMass Change.

1.14.1.2 Examples Showing the Clearing of Provisional Premium

Requests
Example 1: Clearing of down payments against provisional premium requests
Posting data entered in the system

Document number Type of Posting Amount Settlement period

4711 Provisional Premium Requests 100 January 2006

5812 Down payment on provisional premium 80 January 2006

request

4712 Provisional Premium Requests 100 February 2006

5813 Down payment on provisional premium 80 February 2006

request

In this example data, the down payments of 80 can partially clear the provisional premium requests so that an amount of 20 remains open in each settlement
period
Open items resulting from clearing: January 2006

PUBLIC Page 24 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Document number Type of Posting Amount Settlement period

4711 Open provisional premium request 20 January 2006

Open items resulting from clearing: February 2006

Document number Type of Posting Amount Settlement Period

4712 Open provisional premium request 20 February 2006

Example 2: Clearing of down payments against final premiums

Posting data entered in the system

Document number Type of Posting Amount Settlement Period

4711 Provisional Premium Requests 100 January 2006

5812 Down payment on provisional premium 80 January 2006

request

4712 Provisional Premium Requests 100 February 2006

5813 Down payment on provisional premium 80 February 2006

request

6010 Premium 120 January 2006

6011 Premium 120 February 2006

The system determines whether the imported posting data, such as that for clearing groups, can be aggregated. In this example, the system groups the data as
follows: in each clearing group it identifies a premium as the open item that is to be cleared, and clears all the provisional premium requests. No provisional
premium requests are left open.
In our example, the following items remain uncleared:
Clearing group: January 2006

Document number Type of Posting Amount Settlement Period

5812 Down payment on provisional premium 80 January 2006*

request

6010 Premium 120 January 2006

Clearing group: February 2006

Document number Type of Posting Amount Settlement Period

5813 Down payment on provisional premium 80 February 2006*

request

6011 Premium 120 February 2006

( )
Since the system has identified only premiums as relevant for clearing, the postings are not cleared in groups, but only for all the posting data. In this process, the
clearing algorithm clears older documents first. In our example posting data, the premium in clearing group January 2006 is cleared completely with the down
payments from January (80) and February (40). The premium in clearing group February 2006 is cleared partly with 40. This means that in clearing group
February 2006 an amount of 80 remains open for payment
Open items resulting from clearing: February 2006

Document number Type of Posting Amount Settlement Period

6011 Premium 80 February 2006

Note: the system can also determine the settlement period for down payments on premium requests

Example 3: Clearing of down payments against provisional premium requests and subsequent
clearing against premium
Posting data entered in the system

Document number Type of Posting Amount Settlement Period

4711 1. Provisional Premium Requests 100 January 2008

5812 Down payment on provisional premium 80 January 2008

request

5689 2. Provisional Premium Requests 110 January 2008

4712 3. Provisional Premium Requests 100 February 2008

5813 Down payment on provisional premium 80 February 2008

request

PUBLIC Page 25 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 5690 4. Provisional Premium Requests 110 February 2008

Clearing run

6010 Premium 120 January 2008

6011 Premium 120 February 2008

Clearing run

In this example, the first clearing run takes place after two estimates for the respective settlement periods (a prior estimate of 100 and a recent one of 110) and a
down payment of 80 have been made.
After this the actual premium comes in and a second clearing run is started.
Clearing run
The system determines whether the imported posting data, such as that for clearing groups, can be aggregated. In this step, the system groups the data as
follows: in each clearing group it identifies the provisional premium request as the open item that is to be cleared, and writes-off all the older provisional premium
requests.
In our example, the following items remain uncleared:
Clearing Group January 2008, 1st Run

Document number Type of Posting Amount Settlement Period

5812 Down payment on provisional premium 80 January 2008

request

5689 2. Provisional Premium Requests 110 January 2008

Clearing Group February 2008, 1st Run

Document number Type of Posting Amount Settlement Period

5813 Down payment on provisional premium 80 February 2008

request

5690 4. Provisional Premium Requests 110 February 2008

In this first run example, the down payments of 80 can partially clear the provisional premium requests so that an amount of 30 remains open in each settlement
period
Open items resulting from the first clearing run: January 2008

Document number Type of Posting Amount SettlementPeriod

5689 Open provisional premium request 30 January 2008

Open items resulting from the first clearing run: February 2008

Document number Type of Posting Amount Settlement Period

5690 Open provisional premium request 30 February 2008

Clearing run
The second clearing run now takes place. It takes its own premiums into consideration. The system determines how the incoming posting data can be grouped.
In this example, the system groups the data as follows: it identifies the new premium as the open item that is to be cleared, and clears all the provisional
premium requests that are still open. No provisional premium requests are left open.
In our example, the following items remain uncleared:
Clearing Group January 2008, 2nd Run

Document number Type of Posting Amount Settlement Period

5812 Down payment on provisional premium 80 January 2008

request

6010 Premium 120 January 2008

Clearing Group February 2008, 2nd Run

Document number Type of Posting Amount Settlement Period

5813 Down payment on provisional premium 80 February 2008

request

6011 Premium 120 February 2008

Since the system has identified only premiums as relevant for clearing, the postings are not cleared in groups, but only for all the posting data. In this process, the
clearing algorithm clears older documents first. In our example posting data, the premium in clearing group January 2008 is cleared completely with the down
payments from January (80) and February (40). The premium in clearing group February 2008 is cleared partly with the remaining 40. This means that in
clearing group February 2006 an amount of 80 remains open for payment
Open items resulting from the 2nd clearing run: February 2008

Document number Type of Posting Amount Settlement Period

6011 Premium 80 February 2008

PUBLIC Page 26 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 ( )
This example proves that if you replace a provisional premium request that has been cleared against a down payment with a new provisional premium request or
with a new premium, the old provisional premium request is written off and the new provisional premium request is cleared against the down payment

1.14.2 Processing of Clarificn Cases from Prov. Premium Req.

Clearing

Use
When you clear provisional premium requests it may be the case that open items on a particular account cannot be cleared automatically. When this happens a
clarification case is created.
It may not be possible to clear open items automatically because a document (either the provisional premium requestor the premium) contains line items that
have different settlement periods, or the system could not find the clearing documents because some Customizing settings are missing.

Prerequisites
To be able to remove clearing restrictions in account maintenance, you need to have defined that clearing restriction F ( automatic clearing of provisional
premium requests (FS-CD) ) for document processing can be changed manually. You enter this setting in Customizing for Collections/Disbursements
under Basic Functions Open Item Management Define Modifiable Clearing Restrictions . For more information about clearing restrictions see
Restrictions on the Clearing of Provisional Premium Requests .
You have cleared provisional premium requests, and a clarification case was created for a contract account that cannot be cleared.

Activities
To process the clarification case, on the SAP Easy Access screen choose Collections/Disbursements (FS-CD) Account Temporary Premium
Receivables Process Clarification Cases from Clearing.
In clarification case processing, the system displays the message from the last clearing process that created the clarification case.
You can process the clarification case in the following steps:
You can restart the clearing of provisional premium requests by choosing Execute Clearing . The system creates a log of this process.
You can branch to the functions for processing accounts and documents in order to correct manually the errors recorded in the clarification case log.
You can branch to the account balance display .
You can branch to account maintenance .
You can branch the function for making mass changes to documents .
In the function for making mass changes to documents, you can remove the clearing restriction, which prevents the documents from being processed
in account maintenance. You can then carry out the activities for clearing manually. You can clear old provisional premium requests and the down
payments that were received.
You can set the clarification case to resubmission .
You can choose Complete to set the clarification manually to completed.

1.15 Deferred Revenue Postings

Purpose
When a receivables document is posted, the system automatically posts revenues. These revenues become effective in the posting period in which they are
actually posted. This means that these revenues are assigned to the posting period in which they were posted.
The regulations in some countries require that revenue accruals/deferrals have to be entered in the general ledger for revenues that do not become effective until
some date in the future. Revenues become effective in the future, if the service upon which the revenue is based is actually performed in the future. Recognition of
revenues is therefore independent of invoicing. Revenues and accrued/deferred revenues must be posted to separate general ledger accounts. Accrual/deferral is
performed using deferred revenue accounts.
There are three types of revenue recognition:
Standard revenue recognition
Time-based revenue recognition
Event-based (service-oriented) revenue recognition
In the case of standard revenue recognition , posting to the revenue account takes place at the same time the receivable document is posted.
In the case of time-based revenue recognition , when the receivable document is posted, the dates on which the corresponding partial revenues are to be
transferred from the deferred revenue account to the revenue account are already set.
In contrast to this procedure, in the case of event-based revenue recognition , it is the rendering of the actual service that leads to recognition of the partial
revenues.
The following example serves to clarify the difference between time-based and event-based revenue recognition:

( ) On 12/31/08 a business partner signs a maintenance contract amounting to 2,400. The machine is to be serviced regularly on the 15 th of every month
during the year 2009. The business partner receives the invoice on 12/31/08.
In the case of time-based revenue recognition , the partial amounts become revenue-effective on the following dates:
1/15 revenue-effective 200
2/15 revenue-effective 200

PUBLIC Page 27 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 :::
12/15 revenue-effective 200
In the case of event-based revenue recognition , revenue recognition is determined by the service being provided. If the service engineer services the machine
on 02/01 instead of on 01/15, in the case of event-based revenue recognition, revenue would not become effective until 02/01. This means that the partial revenue
of 200.-- would not be transferred from the deferred revenue account to the revenue account until 02/01/09.

1.16 Revenue Distribution

Purpose
In addition to managing your own receivables, you can use the FI-CA component Revenue Distribution to manage receivables for third parties. There are two
variants for revenue distribution in Contract Accounts Receivable and Payable:
Classic revenue distribution
Enhanced revenue distribution

Features
Some examples of situations in which you collect and forward revenues for third parties include:
Under the auspices of cooperation between government agencies
Within the deregulated telephone market
For premium-rate telephone numbers and similar services
When contracted by other companies or government authorities
Revenue distribution ensures that the amounts received are forwarded to the final recipients for whom they are intended.
Documents that contain receivables for third parties are designated as original documents. Revenue distribution posts distribution documents that show the
corresponding amounts for the final recipient.
Classic revenue distribution can be used solely to distribute incoming payments that clear a receivable for a third party. When you post a receivables item of this
kind, you have to specify the contract account of the final recipient to which the payment is to be distributed. This means that, in the standard system, exactly one
final recipient receives the payments assigned to a receivables item. (However, you can split the amount among several final recipients using event 5400.)
In the standard system, with enhanced revenue distribution , you distribute assigned payments (receivables items cleared by payment). However, it is also
possible for you to distribute unassigned payments (payments on account with a subtransaction designated as relevant for payment) and expected revenues
(items that are still open, however no unassigned payments).
For expected revenues and unassigned payments, the system runs an estimated distribution. You have to estimate the distribution ratios of the final recipients in
advance.
In contrast, the system always distributes assigned payments as final, since you can determine the distribution ratios uniquely in advance.

Note
You can use enhanced revenue distribution in parallel with classic revenue distribution. However, a given original line item can only be distributed in one way
– either with classic revenue distribution or enhanced revenue distribution. If data is defined for both classic and enhanced revenue distribution for a one
original line item, classic revenue distribution overrides enhanced revenue distribution. Therefore, make sure that in classic revenue distribution, you do not
automatically derive the final recipient for the line items that you want to distribute with enhanced revenue distribution.

PUBLIC Page 28 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.