Credit or Risk Management.doc

Embed Size (px)

Text of Credit or Risk Management.doc

  • 7/28/2019 Credit or Risk Management.doc



    SAP AG 1999

    Section: Credit/Risk Management

    (C) SAP AG TASD41 7-1

  • 7/28/2019 Credit or Risk Management.doc



    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



    SAP AG 1999

    Payment Differences - Disputed Items


    CCA data CCA data

    Incoming payments TILIA Corp.Incoming payments TILIA Corp.

    Open itemsOpen items

    Incoming paymentsIncoming payments




    $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



    SAP AG 1999

    Payment Differences - Undisputed Items


    CCA data CCA data

    Incoming payments TILIA Corp.Incoming payments TILIA Corp.

    Open itemsOpen items

    Incoming paymentsIncoming paymentsDifferenceDifference


    $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


    (C) SAP AG TASD41 7-4

  • 7/28/2019 Credit or Risk Management.doc



    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



    SAP AG 1999

    Process Chain for Payment Card Processing










    Check validityof authorizationAuthorization


    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


    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



    SAP AG 1999

    Payment Card Authorization with an ExternalSystem









    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



    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


    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



    SAP AG 1999

    Data Transfer to the Clearing House








    SAP standard interface



    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



    SAP AG 1999


    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


    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


    The authorizations in the order are used in billing. A status in the order displays which authorizations

    have already been used.


    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



    SAP AG 1999

    Customer5875958759Invoice #900001

    Customer: 5875958759


    Order value $50

    Invoice #900105

    Customer: 9877598775


    Order value $100

    VISA 4200000000000000

    Clearing house

    Sales revenue

    50 50


    100 100

    Automatic offsetting entryto the customer account

    Debiting of clearing houseaccount and posting of salesrevenue





    VISA 4100000000000001


    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



    SAP AG 1999

    Postings to the clearinghouse account are cumulatedand credited

    Settlement triggered viainterim account




    50 150

    Interim bank account


    The cumulative value isposted to thecorresponding interim bankaccount

    Clearing house

    Clearing house

    Interim bank accountBEFORE



    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