Credit Management

Credit Management/Risk Management The payment guarantee for the value to be billed plays a central role within Sales. Credit management effectively allows you to minimise the credit risk. Risk management for receivables is another useful tool for setting a payment guarantee to cover the credit risk. Note The functionality of the simple credit limit check is covered fully by credit management which is available from Release 2.2. In the simple credit check you can only set one system reaction (warning, error, delivery block) when the credit limit is exceeded. Other functions in credit management are not available. It is planned that credit management should be used exclusively at a later date.

Enter Settings Credit management is directly related to functions in Sales and Distribution and requires certain settings (for example, in partner determination, output determination). This section describes how to set defaults for Customizing functions related to Credit Management.



Pricing Enter the subtotal "A" to specify the credit value in the pricing procedure which you use in pricing during credit processing (Pricing procedure detail screen, 2nd view). With this, the system calculates subtotals for the credit price during pricing and stores them in a certain field (KOMP-CMPRE = credit price of the item). The calculated subtotals are used in credit functions.



Sending Mails in credit processing You can define credit representatives in Customizing for FI. They must also be assigned to an HR human resources master. Credit representatives can be copied into the partner function during sales order and delivery processing. Internal mails concerning credit processing are directed to these representatives, that is once you have maintained the the mailing address in the human resources master.

o

Partner determination The standard system contains the partner functions credit representative (KB) and credit manager (KM) for credit processing. Both partner functions are allocated to partner type "PE". The credit manager is one level higher than the credit representative. Enter these partner functions in the partner determination procedures of the sales document header and the delivery header so that the partners involved in credit processing (for example, for forwarding mail messages) can be allocated and identified. Assign value "A" to the partner functions in the Access field.

o

Output determination For the condition types for output determination, the output condition type KRML is set up. To create and use corresponding condition records for credit management, maintain the output determination procedures for sales documents and deliverie concerning condition type KRML.



Reports

Define the list layout of work lists for Credit Management. The section "Work lists" in IMG describes how to proceed.



Authorizations Two authorization objects were created for Credit Management:

o

V_VBUK_FRE

o

V_KNKK_FRE

Authorization objects are included in the standard SAP profiles. If you want to use the authorization objects in a different way than in the standard version, you must adapt them using authorization maintenance and enter them in individual user profiles if necessary.



Subsequent functions in Shipping The result of credit checks can influence the shipping due date, picking and goods issue of sales orders or individual items. This is why you must take the subsequent requirements for Shipping into account when configuring credit processing. Take the following three requirements into account for Shipping:

o

requirements for creating a delivery due index from the sales order

o

requirements for picking from the delivery

o

requirements for goods issue from the delivery

Note that you can change the copying routines in the "Requirement" field, or create your own FORM routines using requirement maintenance. You cannot change the specifications in the field "System requirement". The section "Routines" in the IMG describes how to create copying routines. If you create your own requirements, you have to take into account the name range that SAP reserves for customer enhancements. The same applies to the subsequent functions for the availability check and transfer of requirements explained below.



Subsequent functions for availability checks and transfer of requirements As a result of credit checks, the system may block or release sales orders or individual items. For this reason, take into account subsequent requirements for the availability check and for transfer of requirements when configuring credit processing. Consider the following for the availability check and transfer of requirements:



o

You can define requirements for creating a purchase requisition from an order.

o

The R/3 system does not yet support tying transfer of requirements to requirements.

o

You can tie the creation of a confirmed quantity to requirements for the availability check.

Logistics Controlling update Maintain the SD update in Logistics Controlling. In the standard R/3 System, the information structure "S066" is set for monthly update of outstanding order values in Credit Management. You can change the parameters of the information structure and change the period type from monthly to daily update, for example.



Updating credit control areas To update credit control areas, define for each credit control area the range of the credit update in the organizational structure (Customizing -> Configuration -> Org.structure -> Setup -> Accounting -> Financial accounting -> Credit control area). Keep in mind that the system determines the next higher credit update if a transaction cannot be processed with the required credit update. For example, update "18" is carried out in the planned range if "12" is not possible.



Assigning credit control areas to company codes In the organizational structure (Customizing -> Configuration -> Org. structure -> Mappings -> Accounting -> Financial accounting -> Comp.code - cred.cont.area) you have to assign the credit control areas to company codes.

Actions 1. Enter subtotal "A" for the credit value in the detail screen of the pricing procedure. 2. Maintain the partner determination procedures of the sales document and delivery header by entering the partner functions KB (credit representative) and KM (credit manager). 3. Maintain the output determination procedures for sales documents and deliveries concerning the condition type KRML. Make sure that the output condition records contain all necessary specifications for Credit Management (see note below).

o

maintain output determination procedures for sales documents

o

maintain output determination procedures for deliveries

4. Define the display variants for Credit Management. 5. Enter the authorization objects in the composite profiles or into the user-specific profiles. If necessary, change the standard values of the activities for each authorization object according to individual points of view. 6. Define the condition for creating a delivery due index from the sales order. 7. Specify the condition for goods issue from the delivery. 8. Specify the condition for picking from the delivery. 9. Specify the condition for creating a purchase requisition from the sales order. 10. Specify the condition for creating requirements for the availability check from the sales order. 11. If necessary, change the parameters of the information structure in Logistics Controlling when configuring the update for sales and distribution "S066". 12. Define the type and scope of the update for each credit control area by choosing an update that meets your requirements from the updates contained in the standard system. 13. Allocate allowed company codes to the credit control areas. Note on condition records Output condition records which you create using the application menu for credit management must be allocated to the condition type KRML. Make sure that the condition records contain all necessary data:

o

credit representative group

o

risk class

o

partner function (KB or KM)

o

do not enter output partners

o

output medium ("7")

o

time of output processing ("4")

o

language

o

Maintain the following entries in the message processing area on the communication screen: Transaction code Parameter ID Sales order: VKM3 VBAK-VBELN AUN Delivery: VKM5 LIKP-VBELN VL

Transport Initiate transport for partner functions and authorizations using the menu in the initial screen.

Determine Active Receivables Per Item Category In this menu option, you specify for each item category whether an item of the respective item category is to be included in the credit functions (check and update of open credit values). The system proposes all valid item categories for the corresponding selection. Actions Select the "Active receivable/credit relevant" field for each item category which is to be taken into account for the credit check.

Maintain Authorizations In this step, you make settings for authorization checks in Credit Management.

Define Document Value Classes Document value classes provide a means of assigning sales order and sales and distribution documents depending on their document value. Using the document value classes, credit representatives, for example, can be given different authorizations for credit allocations depending on the document value. A credit representative, for example, can edit all transactions involving credit up to the value of $1000.-, another representative can edit transactions involving credit over $1000.-. Actions 1. Create document value classes according to your requirements by entering a three-character alphanumeric key and a textual description. 2. Make sure that the credit representatives are allocated to the document value classes.

Assign Document Value Classes In this IMG activity, you assign document value classes to the credit control areas. Actions

1. Enter a credit control area and allocate a credit value to it in a relevant currency. 2. Allocate a document value class. 3. Make sure that the credit control area was entered in the corresponding customer master records.

Maintain Authorizations In this step, the system proposes SD authorization objects for Credit Management. The objects V_KNKK_FRE and V_VBUK_FRE are available in the standard system. Note There are three FI authorization objects for maintaining a customer's credit data. F_KNKA_KKB F_KNKA_MAN F_KNKA_AEN

Receivables Risk Management Payment guarantees of values to be billed play an important, central role when selling goods. Alongside credit management, risk management for receivables provides another efficient tool for guaranteeing against credit risks. The following payment guarantee procedures are available in risk management:



Documentary payment guarantees



Payment cards



Export credit insurance (external link).

Define Forms Of Payment Guarantee In this IMG activity you define the form of payment guarantee. The form of payment guarantee controls how an item in a sales document is guaranteed (e.g. personal guarantee, payment card, unconfirmed letter of credit, export credit insurance (external link), confirmed letter of credit). The following forms of payment guarantee are available:



Payment cards



Export credit insurance (external link to Open FI)



Documentary payment guarantees (for more information, see Documentary payment guarantees in the IMG.

Activities 1. Define forms of payment guarantee. Further notes

The following rules determine how the system accesses forms of payment guarantee, according to the category of payment guarantee:



Payment cards are first activated, if a payment card has been entered in the document.



Documentary payment guarantees are activated immediately.



Export credit insurance is activated if a valid contract exists.

Define and Assign Payment Guarantee Schemas In this IMG activity you define payment guarantee procedures. You can also assign payment guarantee procedures to transactions by defining the following dependencies:



to the customer



to sales document type.

The form of payment guarantee controls how an item in a sales document is guaranteed (e.g. personal guarantee, payment cards, export credit insurance, confirmed and unconfirmed letters of credit). The payment guarantee procedure contains the permitted forms of payment guarantee for payer and document type. It also controls the sequence in which the the system assigns sales document items to payment guarantee procedures. The payment guarantee procedure is determined according to the following factors:



Customer payment guarantee procedure This determines which payment guarantee procedure the system automatically uses if you enter a sales document for the customer.



Document payment guarantee procedure This determines which payment guarantee procedure the system automatically uses for a sales document type.

To determine the procedure, you assign the customer and document procedures to the payment guarantee procedure. In Risk Management for Receivables, the system determines the payment guarantee procedure using procedure keys. It uses the document payment guarantee procedure key in the header for the sales document type, and the customer payment guarantee procedure key in the customer master. You can use requirements to control when there should be no payment guarantee in risk management for the specified form of payment guarantee (e.g. item values under $10, a certain product hierarchy, or product group do not need any payment guarantees). Activities 1. Create your payment guarantee procedures. 2. Define your customer determination procedure for determining the payment guarantee procedure. 3. Define your document pricing procedures for determining the payment guarantee procedure. 4. Assign the document procedure to the order types. 5. Assign the document pricing and customer determination procedures to the payment guarantee procedure.

Credit Management

Credit management enables you to monitor, evaluate and control credit situations and credit allocations. The integration of current information from FI and the simultaneous access to the credit and sales information system provide a broad information basis for evaluating critical credit situations and credit allocation. Credit management includes the following functions:



Carrying out credit checks according to different criteria and at different points in time



Automatic notification of the responsible employees in critical credit situations by means of an interface to the mail system and therefore rapid processing of urgent credit problems



Support in critical credit situations concerning credit allocation by means of an interface to the Sales Information System and FI



Allocation of different authorizations to credit representatives according to certain criteria (for example, authorizations according to the level of the credit limit used or according to document value classes)



Monitoring credit allocation (for example, by creating overview lists)

Carrying out a credit check is controlled by several settings:



The credit group determines the group of transactions for which a credit check is carried out.



The type and the scope of the credit check can be defined at the level of the sales document types (with separate control of the delivery types at the time of delivery and goods issue).



You specify at item level for each individual item category whether or not the item category is included in the credit functions.

To configure credit management according to your requirements, you must edit the following points:



Defaults in various Customizing menus:

o

Pricing ( pricing procedure)

o

Partner determination ( partner determination procedure for sales and delivery header)

o

Output determination (output determination procedure for sales documents and delivery)

o

Reports (display of lists)

o

Authorization maintenance

o

Subsequent functions in shipping (delivery due index, picking, goods issue)

o

Subsequent functions for availability check and transfer of requirements

o

Update in Logistics Controlling

o

Update of credit control areas

o

Allocation of the credit control areas to company codes





Settings in the Customizing for sales and distribution in the step "Credit management":

o

Define credit groups

o

Set sales documents and delivery documents for credit management

o

Set sales and distribution document items for credit management

o

Define type and scope of the credit checks

o

Specify document value classes and credit control areas for the authorization check and assign them to each other

Setting in credit management for Financial Accounting:

o

Define groups for each credit control area

o

Define risk classes

o

Define credit representative groups

o

Define credit representative

Note Please refer to the section "Credit management" of the FI Implementation Guide for further details of the settings which

Define Credit Groups The credit group groups together different business transactions which should be dealt with in the same manner with regard to the credit check. You enter the credit groups when you configure the sales document types for credit management and define the automatic credit check. Default settings The following credit groups are contained in the standard SAP R/3 System:



01 = credit group for sales order



02 = credit group for delivery



03 = credit group for goods issue

Actions 1. Check whether you can use the credit groups in the standard system. 2. If you need to create new credit groups, enter an alphanumeric key with two characters and a descripion for the credit group.

Assign Sales Documents and Delivery Documents Credit checks can run at different times during order processing. For delivery creation, you can additionally specify whether the automatic credit check occurs at the time of delivery creation and/or goods issue. In this menu option, you specify the sales document types for which a credit check should be carried out. Here, delivery types can be controlled separately and specifically at the time of goods issue. At the same time, you specify the system responses if credit checks are set. The system can respond in the following ways:



Warning message The document can be saved.



Error message The document cannot be saved.



Setting a delivery block (credit status) The document can be saved. However a block is automatically set in the credit status.

Actions 1. Define for each sales document type whether a credit check should be carried out. Enter "D" if an automatic check should be carried out. 2. Specify a credit group. 3. Specify a credit group for the delivery type for which you want to carry out a credit check. 4. Specify a goods issue credit group for the delivery type for which a credit check is to be carried out for goods issue.

Define Automatic Credit Control The automatic credit check can target certain aspects during a check and run at different times during order processing. In this activity, you can define your own credit checks to correspond to your requirements in the area of Credit Management. You can determine an automatic credit check for any combination of the following:



Credit control area



Risk class (classifying attribute for your customers from the viewpoint of credit risk which is maintained in FI Customizing)



Credit group Example You can define a credit check for a certain credit control area and for all sales orders in which the customer has risk class 2 (RK2).

It is possible to define a system response for each credit check (for example, warning message). In the case of a warning message, a block can be set in the credit status of a document. When you define automatic credit checks, you can also freely define requirements which cause a document or the forwarding of the material requirements to MRP to be blocked. This is described in the IMG section "Make default settings for Credit Management". If you define your own credit checks, proceed as follows:



specify type of check



specify scope of check



specify system response to check



allocate credit control areas



define and allocate risk classes if necessary



allocate credit group



assign description to the credit check

Types of credit check in integration with SAP Credit Management If you have activated integration with SAP Credit Management in Financial Supply Chain Management (FSCM), you can perform the following credit checks in this activity:



Credit check on basis of maximum document values The order or delivery value must not exceed a value defined in the credit check. The value is saved in the currency of the credit control area. This check is very useful for new customers for whom no credit limit has yet been defined. This check can be controlled by a risk class that is reserved for new customers.



Credit check for changes to critical fields The credit check is triggered by changes to credit-relevant document fields compared to the default values from the customer master record (payment conditions, value date days, fixed value date).



SAP Credit Management If you select this field, you can perform your own credit checks in an implementation of BAdI Connecting to SAP Credit Management (BADI_SD_CM)

Types of credit check when SAP Credit Management is not activated If you just have SD/FI credit management, that is, do not have Integration with SAP Credit Management (FSCM) activated, you can execute the following types of credit checks:



Static credit limit check Credit allocation depends on the total value of open orders, deliveries, billing documents and open items.



Dynamic credit limit check The dynamic check includes both a static part which checks all open items, deliveries and billing documents and a dynamic part which checks all outstanding order values, that is, all orders not yet delivered or partially delivered. The value resulting from the checks is accumulated up to the shipping date in the information structure "S066" in freely definable time units or periods (day, week, month). This information structure is entered in Logistics Controlling and described in the section "Carry out default settings for credit management" under Basic functions. To define the credit check, you specify a certain number of relevant periods from which a date in the future can be calculated (for example, 10 days or 2 months depending on the selected period). This ensures that sales orders which lie further in the future are not used to determine the credit exposure. The total of the static and dynamic part of the check must not exceed the granted credit limit.



Credit check on the basis of the maximum document value The sales order value or the value of goods to be delivered must not exceed a certain value defined for the credit check. The value is stored in the currency of the credit control area. In particular, this check is useful if the credit limit of new customers has not yet been specified. This check can be accessed explicitly by a risk class reserved for new customers.



Credit check when changing critical fields The credit check is started when changes are made to credit-relevant document fields so that they differ from the default values proposed from the customer master record (terms of payment, value days and fixed value date).



Credit check at the time of the next internal check The credit check is started automatically on a certain date. All sales orders entered up to this time are regarded as not critical.



Credit check on the basis of overdue open items The ratio between open items, which are overdue by more than a certain number of days, and the customer balance must not exceed a certain percentage.



Credit check on the basis of the oldest open items The oldest open item may only be a certain number of days overdue.



Credit check against maximum allowed dunning levels The dunning level of the customer may only assume a certain maximum value.



Customer-specific credit checks If you require further checks to those defined in the standard system, you can define them in the corresponding user exits (LVKMPTZZ and LVKMPFZ1).

Requirements In the No Check field, you can enter the number of a requirement with which you can control when credit checks are not carried out. You can deactivate some or all checks. This allows fine tuning on an individual basis for defining credit-relevant transactions and when credit checks do not need to be carried out. For example, you could deactivate the credit check for the following sets of circumstances:



As long as a document contains no items, no check will be carried out.



No check will be carried out during order creation, but rather 14 days before delivery using a background program.



A check should be made to see whether the payment guarantee form has changed (letter of credit, payment card). If the payment guarantee form has not changed and if the old net value does not exceed the new net value, then no credit check is carried out.

You can also reset the credit document status. The following example demonstrates when this is necessary: You are working with risk management and have specified payment card as the payment guarantee form in the payment guarantee procedure. You create a sales order but do not enter a payment card and the credit check is carried out. You then change the sales order and enter a credit card. Since the credit card is a secure means of payment usually for an unlimited amount, you do not want to carry out another check. You can now use a requirement to have the system bypass all checks and reset the status. Requirements are stored as routines. For further information on routines, see the IMG of SD under Routines. The two following example routines are supplied in the standard system. You can display and edit them using transaction VOFM:



1 Order



2 Delivery

You can copy and change these routines according to your own requirements. The routines contain different example scenarios in which credit checks would not be carried out. Caution: Make sure that the coding in your routines is consistent with the coding in risk management and the import and export parameters for the example routines supplied with the standard system.

Check financial accounting/old A/R summary In distributed systems (central financial accounting, decentral sales and distribution), the FI data from the central system is needed for the credit check (see also: Release note Credit management in distributed systems). At the payer level or credit account level, for example, the following data would be needed for a check: Total of open items, detail information on open items (i.e. oldest open item), maximum dunning level, etc. Using the A/R summary, the FI data in the central system can be collected and then transmitted to the decentral SD system using the distribution function. The data is then evaluated in the SD system. The A/R summary represents compressed FI information for the credit check. In check financial accounting/ old A/R summary, you can specify the allowed change rate for the A/R summary using allowed days and allowed hours. This is where you define how old the A/R summary can be for a check to be carried out. If the age rate for the A/R summary is exceeded during a credit check, the document is blocked. Tip: If you have set up credit management so that credit checks are only carried out for certain, comparatively rare orders, then you can enter an age rate of 0. You should also activate RFC in FI Customizing for credit management (preparatory configurations). This ensures that the A/R summary is always determined if a credit check is to be

carried out. Because credit checks are carried out relatively rarely in this case, system performance will not be significantly influenced. Note: Fields allowed days and allowed hours are only available for entry if you have entered an X in field Read A/R summary in FI Customizing. The path is:Accounts Receivable and Accounts > Credit Management > Credit Control Account > Make basic settings for credit management. Actions 1. Enter a combination of credit control area, risk class and credit group as well as a description for the credit check you want to define. 2. On the detail screen of credit control, specify the type of checks required (for example, static, dynamic), the scope of the check as well as the system response according to your requirements. 3. If necessary, enter the general data for the credit check.

Simple Credit Limit Check Note Credit management, available as of Release 2.2., contains all credit limit check functions. During the simple credit limit check, you can only configure one system reaction ('A' warning, 'B' error, 'C' delivery block) when the credit limit is exceeded. You cannot use the remaining credit management functions. It is planned to implement only credit management in a later release. Simple credit limit check A credit limit check can be carried out when sales documents are created or changed. The check is carried out within one credit control area. When changing a document, the check is repeated if changes regarding quantity or value are made. A credit control area consists of one or more company codes. A sales document belongs to one credit control area depending on the allocation of the sales organization to a company code. The SAP System checks the credit limit which was granted to the customer in this credit control area. The credit control areas and the credit limit of a customer are defined in financial accounting and entered in the customer master record. During the check, the SAP System totals the receivables, the open items from special G/L transactions and the net value of the sales order for every item of a sales document. The open items take into account obligations bound by contract which are not recorded for accounting purposes but which involve expenses through diverse business transactions. The total is compared with the credit limit. If the limit is exceeded, the system responds in the way defined by you in the configuration menu. Requirements The sales document types must already be defined. The SAP System automatically proposes the defined sales document types for maintaining the credit limit check. Actions Define whether a credit limit check should be carried out for the individual sales document types. Also define how the system should respond if the limit is exceeded. The following system responses are possible:



Warning



Warning and delivery block

The document can be saved but is automatically blocked for delivery.



Error message The document cannot be saved.