IUT240 Contract Accounts Receivables and Payables Short

Introduction: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

2-3

Introduction: Business Scenario

Your company has just implemented FI-CA as the subledger accounting. As accounts receivable agent, you have to get to know the master data and its controlling characteristics as well as understand the basics of the new tool.

 SAP AG 2003

© SAP AG

IUT240

2-4

The Life Cycle of an Open Item (9)

-

OI (due)

Several OIs

interest

Charges

New due date

Source open item/charges

OI (not due)

- Item (cleared)

Source open item

Invoicing

Account display

inst. plan

Time

General Ledger

Payment (Cash or Direct Debit)

Doubtful flags Indiv. value adj. Write off

Interest calculation Submit to coll. agency

Dunning

Archiving

Deferral Returns  SAP AG 2003

„

Items can be submitted to external collection agencies.

© SAP AG

IUT240

2-13

Central Objects z Business partner

Account

Electricity

„

Contains central data such as names, addresses, communication data and bank details

„

A natural person or legal entity with which your company has a business relationship

z Contract account „

Contains control data such as payment methods, payment conditions, and dunning procedures

„

Object for open-item accounting in contract accounts receivable and payable

„

Is usually a group of contracts (division)

z Contract (division-specific) z Document (items)

BP Account

FI-CA Account

Contract Contract Contract

IS-U  SAP AG 2003

© SAP AG

IUT240

2-16

Elements of the Customer Profile

Payment terms Creditworthiness

Clearing category

(automatic/manual)

Interest key

Dunning procedure Account class

Account determination ID

Tolerance group

 SAP AG 2003

„ „ „ „ „ „ „ „

The business partner's payment patterns are reflected in his/her creditworthiness. The dunning procedure is stored at contract account level. The payment term determines the due date. This includes the due date for the cash discount. The clearing category controls payment allocation and the clearing of credit notes and receivables. The interest key is used to determine individual conditions for interest calculation. The account determination ID is used for determining general ledger accounts. The account class is not used by SAP programs and can, therefore, be used freely. The tolerance group defines limits for payment differences in the incoming payment.

© SAP AG

IUT240

2-17

Creditworthiness 1

Dunning notices

Write offs

[ ∑ (Dunning * Weighting) + ∑ (Returns * Weighting) + ∑ (Write-offs * Weighting) + ∑ (Manual entry * Weighting) + ∑ Device locks IS-U] * credit worthiness factor / business partner

Manual points

Dunning activities

+ =

Automatic Creditworthiness

Returns activities

Device locks IS-U Returns

Manual entries

Influencing factors

Effects

 SAP AG 2003

The business partner's payment patterns are reflected in his/her creditworthiness. You can override automatic determination of creditworthiness by entering a percentage-based weighting and creditworthiness data manually. „ Creditworthiness is stored in the business partner's master data record. Creditworthiness can be updated manually or in the dunning run. „ You can also enter creditworthiness data manually. This means that business transactions such as a customer complaint over unjustified returns (creditworthiness improvement) or 'black lists' from external credit evaluators (worsening creditworthiness) can also influence a business partner's creditworthiness. Manual creditworthiness entries influence a business partner's creditworthiness the same as the entries created by the system. They can contain positive (worsening creditworthiness) and negative (improved credit worthiness) values. They can also be reversed. „ „

© SAP AG

IUT240

2-20

Creditworthiness 2 Creditworthiness

Edit

Goto

Business Partner Man. Creditworthiness Creditw.Factor Creditworthiness Date

Extras

Display Business Partner's Creditworthiness System Help

4711 Fixed Creditworthiness Date of Fixing Release Date

100 75 04.01.2003

Creditworthiness records

Year JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC 2003 2002 .....

0 0

5 0

15 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

Creditworthiness history

Year

Number

2003 2003 2003 .....

2 1 1

Origin Reminder Reminder Ret. paym.

Date 03/17/03 03/03/03 02/17/03

Creditw 10 5 5

Cont. acct.

Revers.

1000045 1000045 1000044

 SAP AG 2003

„

Dynamic calculation of current creditworthiness: Table of creditworthiness weighting TFK046A: 1 month - factor 4 2 months - factor 3 The following formula is used for the runtime 01/04/2003: 5 creditworthiness points (February) * 3 + 15 creditworthiness points (March) * 4 = 75 creditworthiness number

© SAP AG

IUT240

2-21

Lock Concept

Account

Calendar

Posting lock

Account

Calendar

OI

Dunning

Account

Calendar

OI

Interest Calculation

Account

Calendar

OI

Payment run

 SAP AG 2003

„

„ „ „ „

Postings to a contract account can be prevented by a central posting block. This prevents postings, clearing, reversal, and the cancellation of clearing for the involved account. In addition, the open items in this account are not dunned. During online clearing processing, open items of blocked contract accounts are flagged with an appropriate icon. It is not possible to activate these items. Individual business processes can also be prevented by blocks. You can set these locks for all items at contract account level, or at the level of an individual item. Lock reasons can be defined in Customizing. All locks can be given a time limit. Once this limit has expired, the locks are deactivated. You can generate a list of business locks in the SAP application menu under Utilities Industry -> Contract Accounts Receivable and Payable -> For Contract Accounts -> Evaluation of Business Blocks. When you do this, you can select lock entries according to business partner, contract account, lock category, process and lock reason. The entries are output as a report list or ALV list and can be sorted according to business partner or contract account.

© SAP AG

IUT240

2-22

Technology: Event Concept (1) FI-CA program (Event)

CustomerSpecific

Allows flexibility without modifying SAP programs Yes

No Industryspecific

Yes

No Standard program

IS program

Customer program

FI-CA program (Continuation)  SAP AG 2003

© SAP AG

IUT240

2-24

Technology: Event Concept (2) SAPxxxxx program. ... event 2000 ... ... event 0350 ... ... event 0260 ... ... ...

TFKFBM Standard functionality Event

Text

ABAP/4 modules

2000 Interest key determ. FKK_SAMPLE_2000 ... ... ... TFKFBS Industry...functionality ... ... ... Event ... Text ... ABAP/4 modules ... ... ... 0350 Dunning Activities ISU_0350 ... ... ... TFKFBC functionality ... Customer ... ... ... ... Event ... Text ABAP/4 modules ... ... ... ... ... ... ... ... ... 0260 Return charges FCS_0260 ... ... ... ... ... ...

 SAP AG 2003

„

Events can be managed using transaction FQEVENTS.

© SAP AG

IUT240

2-25

Technology: Splitting-Up Processes

End of runtime Not in parallel

Job 1

Business Business partner: partner: From From 100,000 100,000 to to 699,999 699,999

Job 1

Parallel runs

Business Business partner: partner: From From 100,000 100,000 to to 349,999 349,999

Job 1-3 end at nearly the same time

Job 2

Business Business partner: partner: From From 350,000 350,000 to to 401,000 401,000

Job 3

Interval separation is supported by the system

Business Business partner: partner: From From 400,001 400,001 to to 699,999 699,999

Runtime Runtime  SAP AG 2003

© SAP AG

IUT240

2-27

Introduction: Summary z Contract accounts receivable and payable is a subledger accounting component that manages mass data. z It is used for processing open items. z The business partner and the contract account are the required master data. z Open items are managed as documents. z Contracts are realized in industry solutions. z Event management enables you to integrate customer-specific requirements into the SAP System without modifying SAP programs. z Parallel processes drastically reduce the runtimes of mass runs such as payment or dunning processing.  SAP AG 2003

© SAP AG

IUT240

2-31

Documents: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

3-4

Documents: Business Scenario

Documents are usually created automatically in sub-ledger accounting. FI-CA documents can also be entered manually in special cases. After extensive telephone consultation, you post a receivable to your business partner's contract account. The totals records entered in FI-CA are transferred to G/L accounting during the day-end closing.

 SAP AG 2003

© SAP AG

IUT240

3-5

Document Types for Single Processing

Document types Description

NR

B1

Receivable

01

Z2

Incoming payment

20

V3

Consumption billing 31

Z4

Payment

66

R5

Repayment

76

...

...

Number range

Ext.

010000000000 - 019999999999 200000000000 - 209999999999 310000000000 - 399999999999 660000000000 - 699999999999 760000000000 - 769999999999

. . .

 SAP AG 2003

Each document type is identified by a two-digit abbreviation in connection with a description. The document type classifies the document (for example, payment document). You can define for each document type whether it can be used for manual postings or as a document type for a payment or returns lot. Each document type is allocated to a number range. Document number intervals are specified for the corresponding document type using the number range. The number range also determines whether document numbers are assigned internally or externally. Document number ranges are specified depending on the volume of the business processes.

© SAP AG

IUT240

3-7

Structure of a FI-CA Document (1) Document header Doc. number: 010023459101 Posting date: 02/22/2003 Doc. type: F1 Currency: USD Reconciliation key: 03032701/SK1

1 : n

010023459101

1 : n

General ledger items

Business partner items

BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 0100-0011 232.00 010023459101

Item 0001

CCODE U100 U100

G/L Acc. BA Cost Cent. Amount 800000 200.00 175000 32.00

010023459101

 SAP AG 2003

The document header contains general data for the accounts receivable/payable document such as: the document number, document category, document date, posting date, currency, and reconciliation key. Data on the person making entries and on the origin are stored in the administrative data of the document header. Data relevant to posting is stored in the business partner items: Data on the partner/contract, general ledger data (receivables account), data on the receivables amount, specifications on the due date, dunning and clearing data, cash management and forecast data, and other data. Information on offsetting posting is stored in the offsetting item. This normally means the line items for revenue posting(s) and the tax posting line items. Offsetting items and tax lines are created automatically, so only the business partner items must be created.

© SAP AG

IUT240

3-10

Structure of a Payment Document Source receivable Doc. number: Posting date: Doc. type: F1 Reconciliation key:

Payment Doc.number: Posting date: Doc. type: Z2 Reconcil. key:

010023459101 02/22/2003 Currency: USD 03032701/SK1

012204445552 03/05/03 Currency: USD ZE0503200302

012204445552 010023459101

Business partner item BPART CCODE DueDate Trans. Amount 4711 U100 02/22/03 0100-0011 232.00

010023459101

Item 0001

012204445552

Bank offsetting item

General ledger item CCODE U100 U100

G/L Acc. BA Cost Cent. Amount 800000 200.00 175000 32.00

CCODE U100

G/L Acc. BA Cost Cent. Amount 113100 232.00

012204445552

010023459101

Item 0001

 SAP AG 2003

The clearing document that can be posted, for example, during incoming payment, only consists of a document header and the offsetting item(s). The following information is stored in the offsetting items: the payment amount, the corresponding general ledger account, and information on the cleared document. The document number of the clearing document, the clearing date, and the clearing amount are stored in the business partner items of the cleared document. This means that both documents are linked as long as the clearing exists. The payment document does not maintain a business partner item since all information on the business partner item can be viewed in the linked, cleared receivables document. If clearing is reversed, the connection between the clearing document and the receivable is deleted, and the payment document is given a new business partner item with all posting information. The clearing information is stored in the clearing history, even if clearing is reversed.

© SAP AG

IUT240

3-12

Structure of a Statistical Document

Statistical receivable Doc.number: Posting date: Doc. type: F1 Reconciliation key:

010000234001 02/22/2003 Currency: USD 03032702/SK1

Only business partner items exist

010000234001

Statistical business partner item BPART CCODE Due Date Trans. Amount 4711 U100 02/22/03 0100-0011 10.00

010000234001

Item 0001

 SAP AG 2003

Statistical documents only consist of a document header and business partner items. These documents are not forwarded to the general ledger. Statistical postings make it easier to deal with uncertain receivables, since these postings are not transferred to the general ledger and, as a result, are easier to reverse if they are not paid. A typical example of this are budget billing receivables in IS-U. This is because budget billing amounts are not normally backed up by a bill and, if they are not paid, are more difficult to collect than amounts based on a bill. Furthermore, in the case of budget billing requests, value-added tax is only due when the budget billing amount is paid and the receivable is posted in the general ledger. Dunning charges are also another example of amounts that are often not paid, or documents from an installment plan since the underlying source receivables have already been posted in the general ledger.

© SAP AG

IUT240

3-14

Documents:Posting documents

Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing  SAP AG 2003

© SAP AG

IUT240

3-16

Post Document: Entry Point

Posting date: 02/23/2003 Document type: 01 Currency: USD Document date: 02/23/03 Reconciliation key: 03033101/SK1 Screen Variant RECHNUNG Company code U100 Line layout: Business partner item: General ledger item: Tax: Manual entry Calculate automatically

SAP SAP Jurisdiction code Net receivables

Calculate automatically: Taxes are determined from the business partner item

Items

 SAP AG 2003

You can use the screen variants defined in Customizing to design the screens to execute the functions for the business transactions mentioned above (for example, creating a manual bill). You can select the fields you want hidden when the functions for posting, changing or creating a document are executed. For example, it makes sense to hide the fields containing information on the dunning procedure from the document entry. Users can store their preferred screen variants in the central user-specific settings in Customizing. This setting can be changed in the initial screen and during document entry. In addition, certain fields can be hidden (client-dependent) by Customizing as long as they are not needed in business transaction. In the initial screen for document entry, the company code is used as the default value for the line items. You can overwrite it there. When posting with tax, you can select whether the tax rate is entered manually or automatically determined and calculated from the business partner item. The net receivables field specifies that the amount entered is treated as a net amount; otherwise the amount entered forms the basis of tax calculation as a gross amount.

© SAP AG

IUT240

3-18

List Entry: Business Partner Items

Header data Document date: 02/23/03 Posting date: 02/23/03

Document type: Currency:

01 USD

Business partner items BPART CCODE Net due date CACCT Mtrans 1740

U100

03/23/03

634

6000

STrans Amount Contract 0020

232.00

531

...

Line layout o SAP Standard o ZAP line layout with text  SAP AG 2003

You can select various freely definable line layout variants in the list for entering business partner items. Fields included in a variant cannot be longer than 250 characters. Screen variants are specified in the customizing of the documents. Release 4.71 has been converted to table control. As a result, variants that existed previously, are no longer valid. However, they can be migrated using the report RFKK_VAR_MIGRATE_DOCUMENT. If you want to process a document but no current variables exist at this time, the system automatically generates the SAP variant. You can use this to process the document items. The previous SPA/GPA parameters 802 and 803 have been replaced by the new parameters 802TC and 803TC. In the initial screen of the Post Document transaction, you can enter the two line layout variants in the line layout for list entry group box. When you choose the Display/Change Settings function, the system displays a dialog box. You can select and save the variants in this dialog box using the input help. The variants are saved in the user parameters. You can branch to the detail view of document entry by double-clicking on a line. The detail view contains all document fields that can be maintained.. One or more items can be posted for one business partner. You can also enter items for different business partners within the same document. These items are posted in one document number.

© SAP AG

IUT240

3-19

Clearing: Generation of Line Items

Charges receivable Clearing statistical charges Minor differences Write-off

Cash Discount Expense/Revenue

Tax after cash discount

clearing document

Exchange rate difference Foreign currencies

Down payment

 SAP AG 2003

Various new line items can be generated by allocating clearing amounts to open items. Differences in exchange rates must be posted during the clearing of foreign currency documents. If a cash discount is granted and deducted, you must post the cash discount paid. Minor differences that do not exceed tolerance limits are posted as paid or received. A real charges receivable is posted and cleared during clearing of a statistical charges. A down payment must be posted for the clearing of a down payment request. Cash discount postings or revenue from charges can be subject to tax. The tax amount is automatically calculated and posted.

© SAP AG

IUT240

3-25

Documents: Integration with General Ledger Accounting

Document Types and Number Ranges Document Structures Posting Documents Clearing Documents Integration with General Ledger Accounting Customizing  SAP AG 2003

© SAP AG

IUT240

3-28

Integration with FI General Ledger: Definitions Reconciliation key Key under which summary records are recorded for transferring FI-CA documents to the general ledger Automatic determination in the case of mass postings (such as payment runs) Manual entry in the case of single postings (when posting a document for example) Default values for individual postings

Summary Records "Transfer unit" for postings from sub-ledger to general ledger accounting The documents from sub-ledger accounting are consolidated into summary records Summarization criteria include: Posting date Account assignment data (G/L account, cost center ...)  SAP AG 2003

Other summarization criteria include: - Company code - Business area - G/L account - Currency - Additional account assignments of controlling such as cost center, order or profit center. You can prevent summarization with other document items by using the Single document indicator. If you set this indicator, normal summarization of items in the summaries record will not take place. If this indicator is set for a document, a separate document item is created in the transfer document for general ledger accounting.

© SAP AG

IUT240

3-29

FI-CA Document - Summary Record - FI Document

FI-CA Documents Reconciliation key 03040101/SK1 Doc. 12 Amount 116.00 Doc. 13 Amount 232.00

Post document

FI documents Reference key 03040101/SK1* Reference transaction FKKSU

Summary Records Reconciliation key 03040101/SK1 140000

D

348

800000 175000

C C

300 48

Transfer Reconciliation key

40

140000

348.00

50

800000

300.00

50

175000

48.00

 SAP AG 2003

Requirement for transferring a summary record: reconciliation key with "closed" status Display transferred totals records in FI: Transaction FB03 (Document Display) Document list and enter reference transaction FKKSU and the reference key reconciliation key +* in the selection parameters. Reference in FI document header: Reference key = reconciliation key + sequential transfer number set during the transfer Checking/correcting summary records Reasons: - due to reconciliation differences between sub-ledger and general ledger - due to technical problems (such as database problems, termination of a payment run) Procedure: - Checking summary records (RFKKABS1/RFKKGL20) - Correcting summary records (RFKKABS2) - Transferring summary records to the general ledger in correction mode (RFKKGL00) (provided that the summary record has been transferred already)

© SAP AG

IUT240

3-32

Documents: Summary (1)

Documents are usually generated automatically in contract accounts receivable and payable: From incoming payment postings, reversals From the dunning process, interest calculation From invoicing processes (IS-U, IS-M-SD, external billing systems)

Documents can also be entered manually in special cases Contract accounts receivable and payable has its own document structure.

 SAP AG 2003

© SAP AG

IUT240

3-40

Documents: Summary (2)

Individual FI-CA postings are cumulated into summary records by specifying reconciliation keys. Regular transfer of the summary records (for example, on a daily basis) generates postings in general ledger accounting. Reconciliation reports support you when you check and reconcile the FI-CA subledger with the general ledger.

 SAP AG 2003

© SAP AG

IUT240

3-41

Account Balance Display: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

4-4

Account Balance Display: Business Scenario

z A business partner calls to inquire about their account balance. The partner's account is analyzed using the account display. After the analysis, you determine: The customer has paid only some of his payment obligations. A deferral or installment plan was arranged for other receivables.

 SAP AG 2003

© SAP AG

IUT240

4-5

Account Balance Display: Entry Business partner

Account balance role

Contract account Contract Company code Further Details Inst. plan

All items Open items Cleared items

Collective bill Reference

Statistical items (all/budget billing plan/charges/ ...)

List Type User-specific selection With archive Only due/partially paid budget billing amounts Line layout Sort Variant Initial screen  SAP AG 2003

When the account balance display is called, the level of detail specifies the items that are displayed. Frequently used list types can be preconfigured in Customizing and temporarily modified if you enter via the detail selection. You can use the settings to save a list type as a default value in the user parameters. „ You can also further limit the selection by entering user-specific selection conditions based on certain item characteristics, such as due date, transaction or clearing reason. These user-specific limitations can be saved and are available to the user who specified them the next time he/she calls the account balance display. „ Account balance roles are an enhancement of the master data restriction. The account balance role 'consolidation parent' can be defined for an installation. If this is the case, the account balance role must have a function module, which determines all the subsidiaries. If you enter the business partner in the initial screen of the account balance and leave the field account balance role empty, the system displays all items for this business partner. However, if you enter a business partner and the account balance role 'consolidation parent' in the initial screen of the account balance, the system displays all items for this business partner and all items for the subsidiaries. „ Line layout, sorting and initial screen define in which form the selected documents are displayed, and which fields of the selected documents are displayed. This can be changed later in account balance display. If you want other items to be selected straight away, you must return to the initial screen, „

© SAP AG

IUT240

4-8

Account Balance Display - Example Account Status

Edit

0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101

Goto

Account Status: Basic List Extras Environment System

001 Down paym.

**** Contr. acc.

Doc. no.

Total

Payment list

Transaction

Chronology

Due date

Amount 100.00

1000000

100001673

Incom. payment

04/28/03

1000000 100001673

100001671

Other receiv.

04/24/03

1000000

Receivables

Help

ISU Account Balance Display: Standard Display

Variants Receivables

Settings

100001671

Other receiv.

04/24/03

USD

Still open

DL Clearing doc 100001673

100.00 50.00

50.00

50.00

50.00

 SAP AG 2003

Example: There is a due receivable to the amount of 150.00 USD with document number 100001671. This amount has been partially cleared by payment document 100001673 and an amount of 100.00 USD „ If field Double-click field-sensitive is set in the user settings, then the detailed information for the respective field is displayed depending on the cursor position. If the double-click is not field-sensitive, the detailed view of the respective document is called. „ If you double-click on the traffic light symbol, the respective line is displayed inversely. „ In contrast to the previous list, you can now choose the display as an ALV grid list. The standard tab pages (for example, receivables, down payments) are still displayed. To access the detailed view of a payment (previously on the Payment List tab page), you must now double click on the payment. The document display with the clearing document items and the cleared items is called. The functions in the list and the menu functions correspond to the functions in the standard list. „

© SAP AG

IUT240

4-17

Account Balance Display - Example Account Status

Edit

0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101

Goto

Account Status: Basic List Extras Environment System

Help

ISU Account Balance Display: Standard Display

Variants Receivables

Settings

001 Down paym.

Totals

Payment list

Chronology

Business partner 000004711 Contract account 000001000000 USD

Total

Due

Receivables BB plan Down pay. req. CSD request Charges/inter. Quotations PoA/credit Payment req.

50.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

50.00

Inst. plan items Total

1237.47 1237.47

237.47 237.47

Down paym. CSD payment

0.00 0.00

 SAP AG 2003

Totals: Totals of items in categories such as open receivables, payments on account, down payments, and total of the selected items. „ The totals display can be used as an aid to navigation. The totals display is cursor-sensitive. When you double click on the display, the corresponding documents are displayed. „

© SAP AG

IUT240

4-18

Account Balance Display: Payment 1 Account Status

Edit

0000004711 / U300 Claire Clemens 123 Main Street New York, NY 10101

Goto

Account Status: Basic List Extras Environment System

Help

ISU Account Balance Display: Standard Display

Variants Receivables

Settings

001 Down paym.

Compressed

Total

Payment list

Chronology

Detailed

10000167324.10.00 man. check payment

100.00 USD

Cleared items (according to selection) 1000000

100001671

Other receiv.

04/24/03

100.00

100001673

General ledger items $ 100

U300 113100

Bank1 (check rec.)

100.00 USD

 SAP AG 2003

The payment list displays an overview of all incoming payments with the clearing information. If you want the payment list to be displayed, the payment document must contain a general ledger item for a general ledger account that is relevant to the cash flow. You must, therefore, make sure that the general ledger accounts are flagged as relevant to cash flow. „ Example: There is a due receivable to the amount of 150.00 USD with document number 100001671. This amount has been partially cleared by payment document 100001673 with an amount of 100.00 USD „

© SAP AG

IUT240

4-19

Transaction and Account Determination: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

5-3

Transaction and Account Determination: Business Scenario

As an agent in financial accounting, you are involved setting-up automatic account determination during the implementation project. You have to find out about the concept of account determination and sales/purchase tax in contract accounts receivable and payable.

 SAP AG 2003

© SAP AG

IUT240

5-4

Transactions and Account Determination: Structure and Conception of Transactions

Structure and Concept of Transactions Account Determination

Tax Determination

USA: Jurisdiction Code

Customizing

 SAP AG 2003

© SAP AG

IUT240

5-5

Transactions

Main transactions

ƒ Allocation to internal transactions

SAP

Internal Main transactions

Allocation SAP

Subtransactions ƒ Account Determination ƒ Tax determination ƒ Additional account assignment

Transactions ƒ Attributes - Debit/credit - Interest key - Statistical/non-statistical

Internal Subtransactions ƒ Default setting by SAP

Transactions describe the business transaction upon which the posting of a document line item is based  SAP AG 2003

„ „ „ „ „

„

„

A transaction is a combination of main and sub-transactions. The texts allocated to the main and sub-transactions explain the corresponding business transaction and are available in the correspondence. The main transaction controls the determination of receivables and payables accounts. The sub-transaction controls revenue account determination, determination of the tax determination code, and of information about any additional accounts (business area, CO account assignment data). FI-CA and the industry specific applications (such as, IS-U, IS-M or IS-T) use internal main and subtransactions. These are assigned during the various business processes and control these processes. These internal transactions are to be assigned to installation-specific, defined transactions. If all FI-CA functions or industry solutions are used, internal transactions represent the minimum of transactions. In addition to this, for manual posting, you can define any transaction that does not correspond to an internal transaction. Transactions in IS-U must be specified by characteristics such as debit/credit indicator, interest key, statistic indicator, etc. These characteristics are automatically transferred to the document during posting.

© SAP AG

IUT240

5-6

Transactions and Account Determination: Account Determination

Structure and Concept of Transactions Account Determination

Tax Determination

USA: Jurisdiction Code

Customizing

 SAP AG 2003

© SAP AG

IUT240

5-14

Account Determination: Receivables Account Receivables account

Business transaction For example, interest:

Balance account

Main transaction 0040

Contract account/ Contract Company code U100 Division Account determination ID 01

140580

(Receivables)

Account Determination

Define account assignment data relevant for main transactions Posting area R000 / T000 / M000  SAP AG 2003

„ „ „

„

„

The system determines the main transaction during business partner processing based on the internal transaction and its allocation to a defined transaction. The account determination ID is determined from the contract account for cross-contract business transactions, or from the contract for business transactions relating to contracts. The account determination ID controls determination of the receivables account in FI-CA (together with the main transaction that resulted from the business transaction). The company code and, potentially, the division are further criteria. The same receivables account is determined when identical business transactions occur for contract accounts that have the same account determination IDs, for example residential customers or affiliated companies. You can use different account determination IDs to access different receivables accounts in general ledger accounting.

© SAP AG

IUT240

5-15

Account Determination: Revenue Account Business transaction For example, interest: Main transaction 0040 Subtransaction 0020

Transaction determination

Profit/Loss account 800520

Transaction Contract account/ Contract Company code U100 Division Account determination ID 01

Sales revenue account

(Revenues)

0040/0020

Account Determination

Define account assignment data relevant for transactions Posting area R001 / T001 / M001  SAP AG 2003

„ „ „

„

„

The account determination ID is determined from the contract account for cross-contract business transactions, or from the contract for contract-related business transactions. The subtransaction is also required for the revenue account determination This enables you to allocate different revenue accounts to one business transaction (main transaction) by defining special subtransactions. It is also possible to allocate different revenue accounts for each company code and division. The business area and sales/purchase tax code are defined in revenue account determination. Further account assignment characteristics (such as cost and profit centers) can be saved there using the CO account assignment key. In IS-U, you can override the auxiliary account assignments from cost accounting using a contractdependent CO account assignment key that is defined in the IS-U contract.

© SAP AG

IUT240

5-16

Transactions and Account Determination: Tax determination

Structure and Concept of Transactions Account Determination

Tax Determination

USA: Jurisdiction Code

Customizing

 SAP AG 2003

© SAP AG

IUT240

5-17

Tax: Tax Code Determination Business transaction For example, interest: Main transaction 0040 Subtransaction 0020

Transaction determination

Transaction Contract account/ Contract Company code U300 Division Account determination ID 01

Sales revenue account Profit/loss account 800520 Tax determination E1

0040/0020

Tax determination Account Determination

Define sales/purchase tax determination Accounts for sales/purchase tax 0010

Tax determination E1 From-date 04/01/1998 Sales/pur.tax cde (FI) A3

Tax determ. FI S/P tax code Tax rate

A3 16 %

 SAP AG 2003

The determination of the indicator for posting sales tax is connected with the determination of the revenue account for a business transaction. „ In the table TE011, the valid sales tax code for general ledger accounting is determined historically (that is, the periods for which a tax code is valid are defined), based on the tax determination code determined in revenue account determination. „ The tax accounts to be posted are defined in the posting area 0010 depending on company code, sales tax code and tax transaction. „

© SAP AG

IUT240

5-18

Transactions and Account Determination: USA Jurisdiction Code

Structure and Concept of Transactions Account Determination

Tax Determination

USA: Jurisdiction Code

Customizing

 SAP AG 2003

© SAP AG

IUT240

5-22

Tax Determination with Jurisdiction Code Business Transaction

e.g. Interest: MainTransaction 0040 SubTransaction 0020

Finding Transaction

Transaction Contract Account/ Contract

0040/0020

Company Code U300 Division Account Determination ID 01 JD Code 101110001

Account

Revenue Account P&L Account Tax Determination

800520 E1

Sales/Purchase Tax determination Determination

Tax Determination E1 From 04/01/1998 S/P key (FI) O1

Tax Determ. FI S/P key JD code S/P rate

01 101110001 8%, 3%, 1%

 SAP AG 2003

„ „ „ „

In Customizing, you define the tax determination code in IS-U that links to the tax code in FI. The tax account is determined during revenue account determination. The tax code and the jurisdiction code determine the tax rates to be charged. External tax packages may be used in conjunction with FI-CA for tax rate determination.

© SAP AG

IUT240

5-27

Transactions and Account Determination: Summary (2)

z The receivables account that is relevant to a specific accounting transaction is determined by the main transaction. z The transaction, which is made up of a main transaction and a sub-transaction, helps to determine the revenue account and the tax determination ID.

 SAP AG 2003

© SAP AG

IUT240

5-31

Payment: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

6-4

Payment: Business Scenario

z During invoicing, receivables were posted to a business partner's contract account. Billing also created credit for several business partners. z The receivables are posted using the debit memo procedure and the credits are refunded during payment processing.

 SAP AG 2003

© SAP AG

IUT240

6-5

Payment Program: Master Record z Business partner „

Bank data

„

Payment card data

„

Address

z Contract Account Account

„

Responsible company code

„

Link to business partner's bank details (if necessary, alternative payer)

„

Payment methods

„

Payment block

„

Contract account or business partner used for clearing purposes in payment transactions (payer)

 SAP AG 2003

The business partner's address and bank data are used. The bank details defined in the contract account refer to the business partner's bank data. „ The function of the responsible company code is the same as the paying company code in General Ledger Accounting. „ If you specify another business partner and/or contract account to be used for clearing, the items from the contract accounts are paid together for this business partner. The system determines the payment method, bank details, and locks using this clearing contract account. „ You define the additional details which are relevant to payment separately for outgoing and incoming payments: • You can specify a business partner's bank details (or any alternative business partner's bank details) in each case. • You can override the payment methods entered by specifying a different payment method in the document. • You can block the contract account for outgoing or for incoming payments. You can also prevent bank collection after failed debit memos being carried out until a processing block date. „

© SAP AG

IUT240

6-7

Payment: Posting 1 Contract Acct [1]

300.00 300.00

FI-CA

[2]

Receivables account [1]

300.00

300.00

Revenue account 261.00

[2]

[1]

Bank clearing

Bank [2]

300.00

Tax account 39.00

[1]

FI  SAP AG 2003

„ „

[1] Debit position of a receivable [2] Payment in FI-CA by the payment run.

© SAP AG

IUT240

6-8

Payment: Posting 2 Contract Acct [1]

300.00 300.00

FI-CA

[2]

Receivables account [1]

300.00

300.00

Revenue account 261,--

[2]

Bank clearing

Bank [3]

300.00

[1]

[2]

300.00 300.00

[3]

Tax account 39.00

[1]

FI  SAP AG 2003

„

[3] Incoming payments in General Ledger Accounting (posting the account statement).

© SAP AG

IUT240

6-9

Payment Program: Payment Methods 1

Contract account 4712

Contract account 5421

Bank trans.ref. - pymnt meth. 01 Bank no.: 10010000 - acct: 541237 Bank dir. debit - pymnt meth. 02 Bank no.: 10010000 - acct: 541237

DME

DME

Contract account 4711 123.45

Outg. check - pymnt meth. 03 69190 Walldorf, Astor Street 12

 SAP AG 2003

The payment method determines the way in which a business partner pays his/her receivables or how credit is paid out. „ Payment methods are defined for a country. They are allocated for paying company codes and specified in more detail. „ The format determines the technical attributes of the payment medium. This way you determine whether the payment medium is created with a document (on paper) or using without (DME or EDI). „ If there is a credit memo and an open receivable in a contract account, then the credit memo is cleared against the receivable and the remaining balance is either collected or refunded. If, however, the credit is marked with a refund payment method, the refund still takes place and the payment for the full amount of the receivable is also posted. „

© SAP AG

IUT240

6-15

Payment Program: Payment Methods 2

Doc. 1230067 Doc. type 05

Direct debit- pymnt meth. 01 Bank no.: 10010000 - acct: 541237 Inc.pymnt method .....X Bank details................X

Format

Outg. check - pymnt meth. 03 69190 Walldorf, Astor Street 12

Doc. 600999 Doc. type 08

Create check…...........X Street. P.O. box...........X

Format

 SAP AG 2003

„

The payment method defines the way in which payment transactions are carried out in a country. You define rules within a payment method that have to be met for that individual payment method: For example, you have to define bank details in the business partner's master record for a payment method that is classified as a debit memo procedure and reference these from the contract account. To create an outgoing check, however, you have to know the business partner's address.

© SAP AG

IUT240

6-16

Cross-Business Partner Payments Business partner Father

Cont. acct: Father Bank details Payment method .... CA document

2 2

CA daughter pays via BP + CA father:

2

Payment Business partner Daughter

Cont. acct: Daughter Bank details Payment method Payer: BP father Paid by: CA father CA document CA document

1 1 ... 1 3

Bank details Payment method .... CA document CA document CA document Total

2 2 1 2 3

1,2,3

 SAP AG 2003

„ „

„

„

„

If you specify a different business partner and his or her contract account, the open items from all contract accounts that have the same payer are paid together. The details needed for payment or collection (such as payment method, bank details, payment block reason, or alternative payer) are only determined from the contract account of the paying business partner. Blocks in the paying contract account therefore also prevent the addition of items from the account to be paid. On the other hand, blocks on the account to be paid only prevent the addition of items to this account, not the items in the paying account. The contract accounts are cleared when the payment program is run. Clearing is only executed when the paying business partner is also selected in the payment run parameters. Joint payment is only possible when the business partner is the parallel processing object. In contrast to the payer, receivables for different contract partners are paid separately, not together, when you define an alternative payer.

© SAP AG

IUT240

6-19

Returns Processing: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

7-4

Returns Processing: Business Scenario

z As the result of a payment run, an amount has been debited from the bank account of a business partner. However, this direct debit was not successful. The payment document has to be reversed, company and bank charges have to be passed on to the business partner, and the incoming payment method has to be locked for a few days.

 SAP AG 2003

© SAP AG

IUT240

7-5

Returns: Activities 1

Reverse OI clearing or post new receivable

Which items were paid?

Does the return include charges?

Trigger posting of charges

Pass on charges?

Own charges?

 SAP AG 2003

„

Questions regarding processing: - Can I reverse the clearing of paid items or post new (receivables) items? - Return for check payment or payment settlement? - Credit institute charges? - Pass on bank charges to business partner? - Debit own charges?

© SAP AG

IUT240

7-7

Returns Lot: Processing Steps

New lot

Create

Close

Enter items

Post

Lot completed

Postprocessing

 SAP AG 2003

Processing steps: 1. Create: A lot can be created interactively or by a program (for example a returns lot for account statement returns). 2. Change: If a lot is not closed, items can be deleted or added. You can correct any data for items that have already been entered. 3. Close: When a lot is closed, the header data and individual items can no longer be changed. However, a lot can be opened again for processing. Once a lot has been closed, postings can be initiated. 4. Post: Once the lot has been closed, returns posting is carried out with the processing step Post. 5. Postprocessing: Postprocessing is necessary if the returns postings could not be performed. You can use reports to process returns lots. These reports transfer data directly from either an application server file, the bank data storage for electronic account statements, or from a MultiCash file. They use this information to create one or more returns lots and enable users to process errors. „ The application server file must have the format specified by SAP - that is, it may not contain any country-specific formats of electronic account statements. „

© SAP AG

IUT240

7-9

Returns: Returns History

12/15/2002 1234 01/01/2003 3678 01/15/2003 4112 01/30/2003 4711 Returns document Payment document Amount Bank charge 1 Bank charge 2 .... Returns charge ....

4711 56789 3,507.50 7.50 0.00

Every return has an entry in the returns history

0.00

 SAP AG 2003

Updating the returns history: y Commercially applicable data - Amounts - Document numbers y Activities may be dependent on previous returns - The period under consideration - Number „ Returns history is taken into account during the dynamic calculation of creditworthiness, whereby return reasons, number of returns, and chronological order are evaluated. „

© SAP AG

IUT240

7-10

Posting: With Bank Charges 6 Contract account [1] 100.- 100.- [2]

FI-CA

[5] 100.[7,8] 17.Bank clearing [2] 100.-

100.- [3]

Receivables return

Bank [3] 100.-

[7] 10.-

110.- [4]

[8] 7.Expense [6] 10.-

Receivables [1] 100.-

100.- [2]

10.-

[7]

Returns Clearing account [4] 110.- 100.- [5]

7.-

[8]

10.- [6]

Revenue from returns

Revenue 100.- [1]

[5] 100.-

FI  SAP AG 2003

„ „ „ „ „ „ „ „ „ „ „ „

[1] Debit entry from invoicing (tax not shown) [2] Payment settlement by bank collection [3] Incoming payment (account statement) [4] Returns (account statement) [5] Reverse clearing (return in subledger account) [6] Post expense from bank charges [7] Pass on bank charges to business partner [8] Raise and debit charges Step [7] does not take place if bank charges cannot be passed on to the business partner. Step [8] does not take place if you choose not to levy your own charges on the business partner. Levying your own charges for processing returns is optional. In the R/3 System, postings [5] to [8] are made in the course of one processing activity.

© SAP AG

IUT240

7-18

Incoming Payments: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

8-3

Incoming Payments / Clarification Processing: Business Scenario

You have to enter the payments of your business partners on a daily basis. Your business partners pay their open bills by bank transfer or in cash. z You enter the incoming bank transfers in a payment lot. z You post cash payments in the cash journal. z You use a clarification worklist to manage payments that you cannot allocate.

 SAP AG 2003

© SAP AG

IUT240

8-4

Incoming Payments: Functions Payment Lot 123.13 USD 43.45 USD 345.36 USD Payment card lot 85.00 USD 123.45 USD Check lot 345.34 USD 230.00 USD Payment order lot

Karl Einstein

Bank transfer

Date

9.500

34.00 USD 210.46 USD  SAP AG 2003

A payment lot, credit card or check lot can be entered online. The payment lot can also be created using a program (lot of incoming bank transfers, for example). Report RKFFZE00 transfers payment data and creates one or more lots for payments, payment orders, credit card payments or checks. To do this, the report executes the following steps: 1. It reads the application server file that has been entered and checks the data it contains 2. If these data records are correct, the report creates one or more lots. 3. If the corresponding indicators have been set, it closes and posts the lots. Incorrect data records are saved separately and can be used once they have been corrected. You can find out more about the prerequisites and characteristics of the report by reading the report documentation. „ Cash, check and credit card payments can be entered in the cash desk, or by using the cash desk in the active cash journal. „ If you use a payment order instead of a payment posting the payment program does not post a payment document and the paid items are not cleared. Instead, the system generates and saves a payment order. The payment is posted later based on the bank statement, the selection of accompanying open items using the payment order. The paid items are locked for other clearing transactions and other payment runs until the payment is posted. „

© SAP AG

IUT240

8-5

Generate Payment Lot

DME

FF.5

DME

Read elec. bank statement

Bank data memory

FPB7

Transfer data from electronic bank statement

Display/change incorrect data records

FPB17 Transfer data from MultiCash

Display/change incorrect data records

123.13 USD 43.45 USD 345.36 USD

Doc. 123 123.13 USD

120.00 USD 349.90 USD

Doc. 126 120.00 USD

1250.45 USD 456.90 USD

Doc. 128 1250.45 USD

 SAP AG 2003

The bank transfers from an account statement are stored in a payment lot. Payments are assigned when the payment lot is processed. „ Interfaces: y Data Transfer from Account Statement to Payment/Returns Lot RFKKKA00 (transaction FPB7): The report selects payments, returns and payment orders that are imported into the bank data memory during the processing of electronic bank statements for the component Cash Management (TR-CM). If necessary,the FI-CA data can be transferred directly to a payment lot, payment order lot or returns lot. Alternatively, you can output selected data from the bank data memory in a file. You can then import the files created to payment lots, payment order lots or return lots in a later step. You can do this using the FI-CA transfer programs RFKKZE00 (payments, payment orders) and RFKKRL00 (returns). The system uses the business transaction and the amount +/- sign to decide the lot type a payment position is transferred to. y Data transfer from MultiCash files to payment, payment order and returns lots RFKKKA00 (transaction FPB17): If you convert country-specific bank formats into MultiCash format, you can use this report to transfer data from the MultiCash statement file and line item file to payment and returns lots in FI-CA. However, in order to be able to process MultiCash files, you must make the system settings described in the 'Prerequisites' section of the report documentation. „ The files can also be generated using neutral interfaces. However, these must have the SAP format which means they must not contain any country-specific formats from the electronic bank statements. „

© SAP AG

IUT240

8-9

Payment Advice 1

2

Payment advice: 1004711 Customer: 10000815 Max Donaldson Corp. Bill no. Amount 2001234 120.45 3003461 349.90 ∑ 470.35

3 Max Donaldson Corp. Acct.: 0815

Lot 1 470.35 USD Z: 1004711

Doc.

Amount Open

2001234 120.45 120.45 3003461 700.35 349.90 4001234 600.87 600.87

Selection type: Payment advice

Payment Doc. 126 120.45 USD

Payment doc. 127 349.90 USD

1

Copy payment advice

2

Additional selection through payment advice

3

Payment allocation according to payment advice criteria (under/overpayment possible)

 SAP AG 2003

You can use payment advice notes to enter details on announced payments. You can use the key created during the generation of a payment advice note as selection criteria for open items. „ In addition to the business partner or the contract account, you can also use the payment advice note number as selection criteria when entering a payment lot. When the payment is posted, the system selects the open items of the business partner in the payment advice note. The system uses the entries in the payment advice note items to allocate clearing amounts to the selected items. Any amount differences that occur if the amount from the payment advice cannot be completely distributed (that is, if the open item amount is smaller) are combined into a posting on account. „ Report RFKKAV00 also transfers payment advice notes from a sequential file: The report uses the data to generate one or more payment advice notes. It carries out the following activities: • Reads the application server file specified and checks the data contained therein • Creates one or more payment advice notes provided the data records are correct • Closes the payment advice notes provided the corresponding indicator is set. • Defective data records are saved separately and can be transferred once you have corrected them. „

© SAP AG

IUT240

8-14

Incoming Payment: Payment Allocation

Open items

Incoming payment ƒ Clearing Control ƒ Individual criteria ƒ Manual allocation

Payment form no. Business partner Document no. Contract account Contract Gross amount

Payment posting  SAP AG 2003

Selection criteria for open items in incoming payment: „ Amount (allocation if amount is equal) „ Number of the business partner/contract account/contract „ Document number of the open item „ Payment form number: This number encompasses several open items. All items included in one bill or one dunning can be summarized and paid using one number. The items summarized in this way are stored in the transparent table DFKKZR and can be displayed using the transaction FPZP. „ You define codes for selection criteria of payment lot items in Customizing.

© SAP AG

IUT240

8-17

Incoming Payment: Tolerance Limits

Tolerance limit 3.50 USD

Receivable 273.50 USD

Receivable 273.50 USD Cleared Spec. difference acct: Posting 3.50 USD

Incoming payment 270 USD Tolerance limit < 3.50 USD

Receivable 270 USD Cleared Outstanding receivable 3.50 USD

 SAP AG 2003

Using the tolerance groups entered in the contract account, you can define and use tolerance limits for incoming payments. „ If the tolerance limit of the incoming payment is not exceeded, a tolerance account (set up in customizing) is used to post the difference between the open receivable and the payment. The receivable is then cleared in full. In order to do this, the clearing control must be set to allow tolerances to be posted. „ If the difference between the open receivable and the incoming payment exceeds the tolerance limit defined for the incoming payment, the open item is partially cleared and the difference stays in the contract account as an outstanding receivable. „

© SAP AG

IUT240

8-18

Payment Lot: Clarification Worklist

DME

Doc. 126 120.00 USD

1

Lot 1

Doc. 127 456.90 USD

120.00 USD 349.90 USD

2 1

Lot 2 interface Transfer

Clarification worklist

250.45 USD 456.90 USD

2

1 2

250.45 USD 349.90 USD

3

Doc. 198 349.90 USD 3

3

Doc. 199 250.45 USD

Payment Allocation No payment allocation possible

 SAP AG 2003

Central clarification processing is provided to clarify payments that cannot be assigned. The clarification cases for all payment lots are stored in a separate clarification worklist. „ The list of clarification cases to be displayed can be restricted in the selection screen for the clarification worklist using selection criteria. The clarification cases to be displayed can be further restricted with organization units of an organization structure. „ The clarification cases can be processed in parallel by more than one clerk. To do this, clarification cases can be reserved for processing. These clarification cases cannot be processed by other users. Cases that are reserved but not clarified can be released so that they can be accessed again by other clerks. „

© SAP AG

IUT240

8-19

Accounting Clerk Assignment

Payment lot

Total list of administrator

Doc. 4712 Not SB1, but SB2!!!

Clarif. Worklist Payment Lot

Accounting clerk determ.

Doc. 4711 Doc. 4712 Doc. 4713 Doc. 4811 Doc. 4812 ...

Clarif. Worklist Payment run

Payment run

SB1 List - Payment lot Doc. 4711 Doc. 4712 Doc. 4713 ...

SB2 List - Payment lot Doc. 4811 Doc. 4812

Doc. 4712 ...

 SAP AG 2003

„

The clarification worklist can be included in a worklist. SAP supplies the following two sample workflows for this. They can be used to create individual workflows: y Standard workflow A workflow must be allocated to a clerk before it can be sent to a workflow inbox. Agent assignment and agent restriction ensure that clarification cases are only assigned to an agent once. This means that if an agent cannot process and complete a clarification case, the case is sent automatically to another agent. y Ad hoc workflow - WS21000077 No agent allocations or restrictions have to be made for this workflow. If an agent cannot clarify a case, he or she determines the next agent and forwards the case to them. For this workflow, make the setting for a workflow with direct advance in the general workflow settings so that the next processor query appears immediately after processing.

© SAP AG

IUT240

8-20

Repayment Request

Repayment flag / payment method

Payment lot

Postprocessing

Clarif. worklist

Clarification

Repayment request

Repayment active

Payment run Payment method

Payment document

 SAP AG 2003

If allocation of an incoming payment is not possible, you can trigger a repayment by setting the "Repayment" indicator in the item of the incoming lot. „ The bank details from the bank transfer information are used for the refund. „ The repayment itself is performed by the payment run. The “Repayments" indicator must be set in the payment run parameters. „

© SAP AG

IUT240

8-24

Clearing Control: Overview Diagram Course Overview

Clearing Control

Introduction

Dunning and Collections

Documents

Interest Calculation

Account Balance Display

Deferral/Installment Plan

Transactions and Account Determination

Other Business Transactions

Payment

Security Deposits

Returns Processing

Integration

Incoming Payments / Clarification Processing  SAP AG 2003

© SAP AG

IUT240

9-4

Clearing Control: Business Scenario

Example from the Utilities Industry: One of your business partners pays his/her annual consumption bill, this includes billing for the electricity, gas and water divisions. Since this is a partial payment, the open items of the water division must be cleared first. The remaining amount must then be cleared proportionately against the open items of the remaining divisions.

 SAP AG 2003

© SAP AG

IUT240

9-5

Clearing Control: Orientation Every open item, that is every open receivable or payable, must be cleared at some point. There are different procedures that enable you to clear an item. The most frequent are: Externally initiated payment: The customer clears their receivable by paying Clearing: Receivables and credit for a contract account or business partner are cleared against each other in account maintenance

Since these clearing processes are normally mass processes, the system must be able to automatically determine the payment usage or automatically create the clearing proposal based on predefined rules.  SAP AG 2003

© SAP AG

IUT240

9-7

Clearing Control: Definition FI-CA clearing control is a tool for configuring a company's clearing strategy. It contains rules for an automatic clearing proposal or automatic payment assignment By splitting up the clearing algorithm into several work steps and combining a few basic rules, clearing control allows you to configure clearing scenarios flexibly and based on tables.

 SAP AG 2003

© SAP AG

IUT240

9-8

Clearing Control: Overview 1 DFKKOP

DFKKOP

Open items

Incoming payment Selection 1n

cl ea rin g

Business transaction Clearing type 05

st ep s

Clearing category

Contract account

Clearing entry  SAP AG 2003

© SAP AG

IUT240

9-9

Example 1 - Payment Contract account 500.- 01/01/2003 600.- 02/01/2003 1000.- 03/01/2003

Payment 600.-

Clearing type Grouping

Clearing category

Due date clearing

Clearing exact amounts

Contract account 500.600.1000.- 600.-

01/01/2003 02/01/2003 03/01/2003 03/14/2003

 SAP AG 2003

One of your business partners makes a payment to his/her contract account without specifying the payment use in more detail. Payment must be assigned automatically according to a strategy set up in the system. The system checks the due date of an item or an item group. It also has to check whether the paid amount corresponds exactly to a receivable. Only then can the payment be assigned.

© SAP AG

IUT240

9-10

Example 2 - Account Maintenance Contract account 500.600.1000.- 300.-

Clearing type Grouping

01/01/2003 02/01/2003 03/01/2003 03/14/2003

01 01 03 01

Clearing category

Due date clearing

Clearing exact amounts

Contract account 300.200.600.1000.- 300.-

01/01/2003 01/01/2003 02/01/2003 03/01/2003 03/14/2003

01 01 01 03 01

 SAP AG 2003

A contract account contains open receivables and credit that were posted with reference to a certain division. In account maintenance, the system has to clear items for the same division against each other, taking into consideration the due date. The item amounting to 500.00 with the due date 01/01/03 and division 01 qualifies as the item with the highest that has to be cleared against the credit of 300.00 and division 01. In order to do this, the item is split into a sub item of 300.00, which is cleared by the credit, and a sub item of 200.00, which remains open.

© SAP AG

IUT240

9-11

Determination of Clearing Variants Clearing variants are determined depending on the clearing type of the underlying processes and, optionally, on the clearing category of the contract account. Business transaction Clearing type Payment lot 05 Cash desk 19 Automatic clearing 04

Clearing variant 05 19

0815

04 ⇒ AM1 04 + SAM ⇒ AM2

Contract account Clearing category Private C&I Collector

⇒ PY1 ⇒ PY1

STD SON SAM

Optional

 SAP AG 2003

Clearing rules are defined depending on the clearing type. They can also be made dependent on the clearing category (optional). The clearing type represents the business transaction. For example, payment lot (05), cash desk (19), manual account maintenance (03) With the exception of a few examples, it corresponds to the source used in the underlying process (HERKF_KK) The clearing category represents the reference to the contract account. It is stored in the contract account. In this way, different customer groups can have their own clearing categories. For example, private, commercial and industrial, collectors The user can freely assign the category Clearing variants can be assigned in Customizing under Define Defaults for Incoming Payments, Account Maintenance, Invoicing..... (structured according to areas of implementation).

© SAP AG

IUT240

9-12

Clearing Control: Clearing Types Overview of clearing types used in the standard processes (FI-CA) (Table TFK110, level 4.71) Clear Type

(*)

Description

Use

Inc_ Pymt X

01

Manual posting

1

03

Manual account maintenance

2

Use = Implementation area 1. incoming payment 2 Account maintenance 3 Distribute clearing amount amongst dependent items

04

Automatic account maintenance

2

05

Payment lot

1

06

Payment run

4

19

Cash desk: Payment

1

X

20

Cash Desk: Payment by Card

1

X

21

Cash Desk: Payment by Check

1

X

22

Cash Desk: Postal Order

1

X

25

Check Lot

1

X

45

Payment Order Lot

1

X

47

Electronic Bill Presentment and Payment

1

X

55

Credit Card Lot

1

X

20R

Distribute Payment to Installment Plan

3

X

20S

Distribute Payment to Collective Bill

3

X

30G

Distribute Payment to Summarization

3

X

4 Payment run X

Inc_Pymt: Assignment of available amount, for example,payment

(*) used in the configuration of enhanced grouping (event 0600)  SAP AG 2003

© SAP AG

IUT240

9-13

Clearing Control: Summary (1)

You use clearing control to model your company's automatic assignment and clearing strategy (at several levels if necessary). Clearing control uses clearing variants to map your clearing strategy, so that incoming payments can be assigned to open items. Clearing control is used in account maintenance and the additional account maintenance function in IS-U invoicing to clear open items against credit and payments on account.

 SAP AG 2003

© SAP AG

IUT240

9-29

Clearing Control: Summary (2)

Clearing variants are determined using contract account information and the accounting transaction (such as payment at cash desk or automatic clearing). The selected items are grouped and sorted for clearing using characteristics.

 SAP AG 2003

© SAP AG

IUT240

9-30