7/28/2019 Credit or Risk Management.doc

1/12

0

SAP AG 1999

Section: Credit/Risk Management

(C) SAP AG TASD41 7-1

7/28/2019 Credit or Risk Management.doc

2/12

0.2

SAP AG 1999

Payment Differences and Special Commitments:Business Scenario

Sometimes there are deviations between theamount of the incoming payments and the existingreceivables. When posting the residual items, youremployees enter a difference code. Here, disputedresidual items should not influence thecommitments in credit management.

Some customers make payments for orders. Theseincoming amounts should reduce the amount of

credit limit used.

(C) SAP AG TASD41 7-2

7/28/2019 Credit or Risk Management.doc

3/12

0.3

SAP AG 1999

Payment Differences - Disputed Items

Incomingpayments

CCA data CCA data

Incoming payments TILIA Corp.Incoming payments TILIA Corp.

Open itemsOpen items

Incoming paymentsIncoming payments

DifferenceDifference

$12,000$12,000

$11,000$11,000

$1,000$1,000 Reason 01Reason 01

Customizing: Financial Accounting - Incoming paymentsCustomizing: Financial Accounting - Incoming payments

Difference reasonDifference reason DisputedDisputed

0101 YesYes

0202 NoNo

Tilia Corp.Tilia Corp.

Receivables: $12,000Receivables: $12,000

Tilia Corp.Tilia Corp.

Receivables: 0Receivables: 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 onAutomatic Credit Control.

(C) SAP AG TASD41 7-3

7/28/2019 Credit or Risk Management.doc

4/12

0.4

SAP AG 1999

Payment Differences - Undisputed Items

Incomingpayments

CCA data CCA data

Incoming payments TILIA Corp.Incoming payments TILIA Corp.

Open itemsOpen items

Incoming paymentsIncoming paymentsDifferenceDifference

$12,000$12,000

$11,000$11,000$1,000$1,000 Reason 02Reason 02

Customizing: Financial Accounting - Incoming paymentsCustomizing: Financial Accounting - Incoming payments

Difference reasonDifference reason DisputedDisputed

0101 YesYes

0202 NoNo

Tilia Corp.Tilia Corp.

Receivables: $12,000Receivables: $12,000

Tilia Corp.Tilia Corp.

Receivables: $1,000Receivables: $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

7/28/2019 Credit or Risk Management.doc

5/12

0.5

SAP AG 1999

Receivables from Special G/L Transactions

CCA data

Customizing: Financial Accounting - Incoming paymentsCustomizing: Financial Accounting - Incoming payments

Account type: D = CustomerAccount type: D = Customer

Special general ledger indicator: A = PaymentSpecial general ledger indicator: A = Payment

Credit limit relevance: xCredit limit relevance: x

Tilia Corp.Tilia Corp.

Payment : $2,000Payment : $2,000

Tilia Corp.Tilia Corp.

Total commitments $10,000Total commitments $10,000

Receivables: $12,000Receivables: $12,000

Special commitments: $- 2,000Special commitments: $- 2,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

7/28/2019 Credit or Risk Management.doc

6/12

0.6

SAP AG 1999

Process Chain for Payment Card Processing

Authorization

Clearinghouse

Settlement

Order

Cardinfo

Outbounddelivery

Billingdocument

Cardinfo

Cardinfo

Check validityof authorizationAuthorization

Authorizationinformation

Acc. doc.

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

7/28/2019 Credit or Risk Management.doc

7/12

0.7

SAP AG 1999

Payment Card Authorization with an ExternalSystem

Authorization

Billingdocument

Cardinfo

Cardinfo

Authorizationinformation

Clearinghouse

Settlement

POS

Acc. doc.

This form of processing takes place in Retail. ThePoint-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 usingPoint-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

7/28/2019 Credit or Risk Management.doc

8/12

0.8

SAP AG 1999

Payment Card Data in the Customer Master record

VISA 4100000000000001 X 01.01.1997 31.12.2002

MC 5100000000000008 01.01.1996 31.12.2001

Best BankBest Bank VISAVISA

4100 0000 0000 00014100 0000 0000 0001

Valid from 01/97 to 12/2002Valid from 01/97 to 12/2002K. KingK. King

Euro Bank MCEuro Bank MC

5100 0000 0000 00085100 0000 0000 0008

Valid from 01/96 to 12/2001Valid from 01/96 to 12/2001K. KingK. King

Card type Card number Default Block reason Valid from Valid to

Payment card data can be stored in the payer master record via thePayment transactions screen

(Payment cardsbutton).

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

7/28/2019 Credit or Risk Management.doc

9/12

0.9

SAP AG 1999

Data Transfer to the Clearing House

Converter1

Clearinghouse

2

Converter2

Clearinghouse

3

Converter3

SAP standard interface

Clearinghouse

1

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

7/28/2019 Credit or Risk Management.doc

10/12

0.10

SAP AG 1999

Authorization

0 1 2 3 4

One day before delivery creationValid for 14 days

Authorization horizon

Validity period (14 days)

Next material availability dateby schedule line

Order entry

Days

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 tocheck the correctness of the card data.

(C) SAP AG TASD41 7-10

7/28/2019 Credit or Risk Management.doc

11/12

0.11

SAP AG 1999

Customer5875958759Invoice #900001

Customer: 5875958759

KingKing

Order value $50

Invoice #900105

Customer: 9877598775

KaiserKaiser

Order value $100

VISA 4200000000000000

Clearing house

Sales revenue

50 50

Customer9877598775

100 100

Automatic offsetting entryto the customer account

Debiting of clearing houseaccount and posting of salesrevenue

50

100

100

50

VISA 4100000000000001

Settlement(1)

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 tothe 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

7/28/2019 Credit or Risk Management.doc

12/12

0.12

SAP AG 1999

Postings to the clearinghouse account are cumulatedand credited

Settlement triggered viainterim account

100

50

100

50 150

Interim bank account

150

The cumulative value isposted to thecorresponding interim bankaccount

Clearing house

Clearing house

Interim bank accountBEFORE

AFTER

Backgroundprocessing#5584

Settlement (2)

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