0

Section: Credit/Risk Management

SAP AG 1999

(C) SAP AG

TASD41

7-1

0.2
Payment Differences and Special Commitments: Business Scenario

Sometimes there are deviations between the amount of the incoming payments and the existing receivables. When posting the residual items, your employees enter a difference code. Here, disputed residual items should not influence the commitments in credit management. Some customers make payments for orders. These incoming amounts should reduce the amount of credit limit used.

SAP AG 1999

(C) SAP AG

TASD41

7-2

0.3
Payment Differences - Disputed Items
Customizing: Financial Accounting - Incoming payments Difference reason 01 02 Disputed Yes No

Incoming payments TILIA Corp. Open items $12,000

Incoming payments $11,000 Difference

CCA data

$1,000

Reason 01
CCA data

Tilia Corp. Receivables: $12,000

SAP AG 1999

Incoming payments

Tilia Corp. Receivables: 0

For each company code, difference reasons are determined to manage payment differences. Difference reasons are used, for example, when the cash discount period has been exceeded, when an unauthorized cash discount is claimed, or if the customer has simply made an error in calculation. You indicate for each difference reason whether payment differences should result in disputed items. Disputed items do not raise the total receivables within credit management due from a customer. When you carry out a credit check against the oldest open items and the percentage of open items with a certain number of days in arrears, the system does not take disputed items into account. For more information see the chapter on Automatic Credit Control.

(C) SAP AG

TASD41

7-3

0.4
Payment Differences - Undisputed Items
Customizing: Financial Accounting - Incoming payments Difference reason 01 02 Disputed Yes No

Incoming payments TILIA Corp. Open items $12,000

Incoming payments $11,000 Difference

CCA data

$1,000

Reason 02
CCA data

Tilia Corp. Receivables: $12,000

SAP AG 1999

Incoming payments

Tilia Corp. Receivables: $1,000

In this example, the receivable in credit management remains at the level of the outstanding receivable because the difference reason is not disputed (for example, an error in calculation by the customer).

(C) SAP AG

TASD41

7-4

0.5
Receivables from Special G/L Transactions
Customizing: Financial Accounting - Incoming payments Account type: D = Customer Special general ledger indicator: A = Payment Credit limit relevance: x

Tilia Corp. Payment : $2,000

CCA data

Tilia Corp. Receivables: Special commitments: Total commitments

SAP AG 1999

$12,000 $- 2,000 $10,000

Special general ledger transactions represent special transactions in accounts receivable and accounts payable, which cannot be shown in the usual way in the sub-ledger account. Examples include down payments and bill of exchange posting. The Credit limit relevance indicator ensures that the system takes posting into account when the credit limit check is carried out for special general ledger transactions (in other words, this value is included in total commitments).

(C) SAP AG

TASD41

7-5

0.6
Process Chain for Payment Card Processing

Order

Authorization
Card info

Clearing house

Outbound delivery

Check validity of authorization Authorization

Settlement

Billing document
Card info
SAP AG 1999

Authorization information

Acc. doc.
Card info

Payment card processing supports the following functions: A payment card plan is assigned to the sales order at header level. This plan contains information such as the card number, the card type and the authorization data. When the delivery is created, a validity check is carried out for the authorization. If the authorization is no longer valid, or if an increase in quantity requires an increase in value, then the user is required to carry out authorization again in the sales order. The payment card data is copied to the billing document from the order. The payment card data and authorization data are forwarded when the billing document is transferred to Financial Accounting. In Customizing, you can configure the system so that additional data needed for settlement is transferred from SD to FI when procurement cards are involved. Transactions with payment cards can be posted to deviating accounts (see the field Account determination for payment cards when controlling the billing types). The final settlement process is carried out via the clearing house on the basis of this information.

(C) SAP AG

TASD41

7-6

0.7
Payment Card Authorization with an External System

Authorization

Clearing house

POS

Settlement

Billing document
Card info

Acc. doc.

Authorization information

Card info

SAP AG 1999

This form of processing takes place in Retail. The Point-of-Sale (POS) is the point at which the goods are paid for (usually the cash register). No sales or shipping documents are created. When using Point-of-Sale systems, authorization is carried out in an external system. The relevant data is imported to the R/3 System. The billing document is created in the R/3 System.

(C) SAP AG

TASD41

7-7

0.8
Payment Card Data in the Customer Master record

Card type VISA MC

Card number 4100000000000001 5100000000000008

Default Block reason Valid from Valid to X 01.01.1997 31.12.2002 01.01.1996 31.12.2001

Best Bank

VISA

4100 0000 0000 0001 Valid from 01/97 to 12/2002 K. King Euro Bank MC

5100 0000 0000 0008 Valid from 01/96 to 12/2001 K. King

SAP AG 1999

Payment card data can be stored in the payer master record via the Payment transactions screen (Payment cards button). Here, you specify the payment card type (for example, VISA), the payment card number, and the validity periods for this card. A card can also be entered as a default card. This will then appear in the F4 Help for order processing. If a card is blocked, the blocking reason can also be entered for the corresponding payment card (purely for information purposes, has no effect on the block in the order). When you enter payment cards in the customer master, the following checks are carried out: The system checks the validity of the card number, provided the corresponding check routines are maintained in Customizing for that card type. The system also checks whether this card has already been entered in a different customer master record. An identical card cannot be entered for more than one customer.

(C) SAP AG

TASD41

7-8

0.9
Data Transfer to the Clearing House

SAP standard interface

Converter 1

Converter 2

Converter 3

Clearing house 1
SAP AG 1999

Clearing house 2

Clearing house 3

Clearing houses issue authorizations for orders and are also responsible for settlement. A transparent interface to external systems allows the merchant to transfer and receive data. In the standard R/3 System, function CCARD_AUTH_SIMULATION is provided as a template for creating user-specific authorization functions. The standard system also contains function CCARD_SETTLEMENT_SIMULATION, for creation of user-specific settlement functions.

(C) SAP AG

TASD41

7-9

0.10
Authorization

One day before delivery creation Valid for 14 days Order entry Next material availability date by schedule line

Days

Authorization horizon

Validity period (14 days)

SAP AG 1999

Authorization is usually carried out in the order at header level. In other words, new authorizations must always be created through the order. Using checking groups, you can set requirements in Customizing, that control under what circumstances authorization is to be determined. You can then set the system so that authorizations are carried out only for complete orders. Depending on the checking group, you can also specify the authorization horizon (in other words, when authorization is to be determined). If you use authorization requirement 1 provided in the standard system, authorization is triggered when you save the order. Authorization requirement 2 is provided for background processing. The checking groups must be assigned to the sales document types. In the example above, an order has been entered today and is to be paid for using a VISA card. Authorization is to be carried out one day before delivery creation and will be valid for 14 days. The next material availability date according to the schedule line is in three days. This means that the authorization process must be carried out in two days time, according to the authorization horizon specified. The authorizations in the order are used in billing. A status in the order displays which authorizations have already been used. Note: You can use the checking groups in Customizing to control whether preliminary authorizations (value 0, if the current date is outside the authorization horizon) are to be carried out in order to check the correctness of the card data.

(C) SAP AG

TASD41

7-10

0.11
Settlement(1)

Invoice #900001
Customer: 58759 King VISA 4100000000000001 Order value $50

Customer 58759
50 50

Sales revenue
50 100

Invoice #900105
Customer: 98775 Kaiser VISA 4200000000000000 Order value
SAP AG 1999

Automatic offsetting entry to the customer account

Debiting of clearing house account and posting of sales revenue

Customer 98775
100 100

Clearing house
50 100

$100

When accounting documents are being created from transferred billing documents that include payment card data, the following postings are made: Debit and credit postings to the customer account Posting of the sales revenue Posting of receivables to the interim account of the clearing house This posting process can be explained in that the authorization guarantees the receivable and the clearing house represents the relevant partner for payment. An interim account should be created for every clearing house so that the condition technique can be used to carry out posting to the relevant account (all receivables paid with VISA and MC posted to the interim account of the GZS; all receivables paid with AMEX posted to the interim account for the AMEX clearing house, and so on).

(C) SAP AG

TASD41

7-11

0.12
Settlement (2)

B E F O R E

Clearing house
50 100

Interim bank account

Postings to the clearing house account are cumulated and credited A F T E R

The cumulative value is posted to the corresponding interim bank account

Background processing #5584

Clearing house
50 100 150

Interim bank account

150

Settlement triggered via interim account

SAP AG 1999

At regular intervals, the individual postings can be cumulated in the interim account for the clearing house and posted as a full value to the corresponding interim bank account. Settlement with the clearing house is triggered via this interim bank account. This account now contains the receivables from the clearing house for which payment is now expected. The receivables were transmitted via a settlement run. The background processing number can be used for assignment purposes during incoming payments. The interim bank account is cleared upon payment of the receivables by the clearing house.

(C) SAP AG

TASD41

7-12