Professional Documents
Culture Documents
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.
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.
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.
o o
V_VBUK_FRE 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 o o
requirements for creating a delivery due index from the sales order requirements for picking from the delivery 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 o o
You can define requirements for creating a purchase requisition from an order. The R/3 system does not yet support tying transfer of requirements to requirements. 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 o
maintain output determination procedures for sales documents 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 o o o
credit representative group risk class partner function (KB or KM) do not enter output partners
o o o o
output medium ("7") time of output processing ("4") language 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.
Maintain Authorizations
In this step, you make settings for authorization checks in Credit Management.
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
Documentary payment guarantees Payment cards Export credit insurance (external link).
Payment cards Export credit insurance (external link to Open FI) Documentary payment guarantees (for more information, see Documentary payment guarantees in the IMG.
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.
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)
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:
o o o o o o o o o o
Pricing ( pricing procedure) Partner determination ( partner determination procedure for sales and delivery header) Output determination (output determination procedure for sales documents and delivery) Reports (display of lists) Authorization maintenance Subsequent functions in shipping (delivery due index, picking, goods issue) Subsequent functions for availability check and transfer of requirements Update in Logistics Controlling Update of credit control areas Allocation of the credit control areas to company codes
Settings in the Customizing for sales and distribution in the step " Credit management":
o o o o o
Define credit groups Set sales documents and delivery documents for credit management Set sales and distribution document items for credit management Define type and scope of the credit checks Specify document value classes and credit control areas for the authorization check and assign them to each other
o o o o
Note
Define groups for each credit control area Define risk classes Define credit representative groups Define credit representative
Please refer to the section "Credit management" of the FI Implementation Guide for further details of the settings which
Actions
01 = credit group for sales order 02 = credit group for delivery 03 = credit group for goods issue
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.
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.
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
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)
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.
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.