1. Positioning the credit control area.
2. Distributed credit management.
3. Payment guarantee management.
1. Positioning the credit control area.
The credit control area is no longer a combination of company codes, but can be entered in the line item or determined in an order from order data, customer data, or a user exit. This means that the control area can be used flexibly as an internal control instrument, and data that needs to be posted in the same company code for accounting reasons need no longer be managed in the same control area.
The control area additionally allocated to the company code is only a default and is used, for example, for crediting commitments for those incoming payments to the customer that cannot be allocated. Otherwise, the credit amount is deducted in the control area in which it was also added. As before, this is the case for every payment.
There is an additional check table of the control areas that are permitted for each company code.
For all item-related checks that take place at control area level, only data which has been posted to this control area will be included.
Data from all the company codes which are allowed in the relevant control area is used for all evaluations that take place at company code level (e.g. payment history, dunning data).
2. Distributed credit management
A scenario is supported which allows several decentralized SD systems to operate active credit management against a central FI system.
An A/R summary is created in the FI system for this purpose. This contains all the information on a credit management account (in a control area) that is necessary for the credit check in SD. This information is in compressed form.
A program which should be run periodically creates this A/R summary and sends it to the decentralized SD systems via the ALE customer distribution model. Methods from the Business Object Repository are used to do this. The data is received by the decentralized SD systems and stored in the database. The locally called checks are not then run against the database, which is only a reflection of local activities, but against the A/R summary and therefore against all the open items. If the A/R summary is out of date, you can use the Remote Function Call to update the data in the FI system.
Even in a non-distributed system, it may be beneficial to run the SD credit check against this A/R summary. The repeated reading of open items is then exchanged for the repeated reading of the results of one of these inquiries.
The data determined in this way from the A/R summary can be integrated in the credit overview in line layout variants. This makes it possible to identify those credit management accounts for which the credit check will report an error when the next incoming orders are made.
3. Payment guarantee management
As well as the total of open receivables (= not guaranteed for payment, therefore at your own risk), a second total of receivables guaranteed for payment is recorded in credit management.
Items can be guaranteed for payment in different ways and are then no longer at your own risk:
The payment guarantee amount is produced from a payment guarantee procedure defined in SD. It can include a percentage of the invoice amount.
For example, an amount of 600 USD can be guaranteed for a receivable of 800 USD using a letter of credit. This has the following effect in credit management:
The amount of a receivable guaranteed for payment is, like the credit amount of a receivable, in the line item and can therefore be displayed in the document display, the line item display, and the credit overview (with line layout variants).
For further information on Customizing for Credit Management,
see the Implementation Guide for Financial Accounting under
Accounts Receivable and Accounts Payable -> Credit
Management -> Credit Control Account . See the
"Allocate permitted credit control areas to company code" and
"Make basic settings for credit management" .
The field Payment guarantee amount (field name ABSBT) can be included in line layout variants.
For further information on the ALE scenario "Distributed credit management", see the activity "Distributed credit management" in the Implementation Guide.
See also the release notes on credit management/risk management in SD: