IUT240 Contract Accounts Receivables and Payables Short
April 19, 2017 | Author: Kev Vo | Category: N/A
Short Description
Download IUT240 Contract Accounts Receivables and Payables Short...
Description
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
View more...
Comments
