Hierarchy
SAP_APPL (Software Component) Logistics and Accounting⤷
CA-GTF (Application Component) General Application Functions⤷
BAM (Package) Technical Application Analysis
Basic Data
| Data Element | NODE71000 |
| Short Description | Documentation for credit management node |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CHAR1 | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | 1 |
| Medium | 15 | 1 |
| Long | 20 | 1 |
| Heading | 1 | 1 |
Documentation
Description
Theses key figures refer to the core areas of credit management within SAP Sales and Distribution processing.
The main focus of the examination are the account determination keys, which carry out accesses to automatically determine the value of documents or items and check this against the existing credit framework. This does not concern checking rules, for which no assignment is shown between the credit control area, risk categories and customer master record.
Credit management can however lead to a bottle-neck situation, because it takes place within the document. It is normally implemented during creation of documents or items, or during changes to item data such as amounts, values, deadlines or other special fields, which have been defined as check relevant.
Carrying out a credit check within a process chain is not always a good idea as it can affect the running time of a process and should therefore always be questioned first.
Along with other less technical optimization measures, modelling determines the later use of system resources during credit management.
Focus points
The parts of the function with high resource requirements are taken into consideration.
According to experience these are
the use of statistical and dynamic test procedures,
checking rules for automatic credit controls, particularly for dynamic test procedures, for example the
check at item level, which should not necessarily be used for all items in a document,
checking horizon, which has an indirect influence on the number of items to be checked,
frequency with which checks are repeated, which may be influenced by the following checking rules :
for documents already released,
the number of days until the next check, consideration of financial data such as
open items and their maximum age,
the reminder level to be checked,
check at the level of the business partner "Payer", the use of credit groups and risk categories,
and the frequency of use, frequency of repeats and characteristics of the "worklists" for the release of blocked documents.
Example 1:
An order may have items with high values (e.g. machines) and items with low values (e.g. spare parts). All items at the moment use the same item type. They must all therefore undergo the same credit check, although from a specialist area viewpoint this would only be required for high value parts.
This type of check can lead to increases in running time, particularly for large documents, i.e. those with lots of items.
Example 2:
Deliveries generally require three days before goods issue for picking, packing and loading. Any change to the delivery document currently requires a renewed check of the credit situation, which is not a good idea, and by using the number of days can be used for further checks.
Example 3:
Due to restrictive set checking rules, almost half of the daily incoming sales orders are blocked.
The release is carried out via the "worklists" and is carried out as often as is needed to get the number of documents required for outbound delivery. Such "sharp" checks were originally only planned at the beginning for the first start-up of a credit check but inbetween times this has changed.
Changes to the test procedures or restructuring of the organization flow could improve this situation and lead to a reduction in the load on the system.
Due to potentially high resource requirements, the use and specification of credit management should always be questioned first.
Since credit management is influenced by other system functions such as pricing, partner determination and output determination or is based on these, these functions and their potential for bottleneck situations must be taken into consideration.
Definition and changes to the models in credit management requires comprehensive handling with regard to business and technical system connectivities.
Particularly when different company areas are involved.
They should not be tackled without support from experienced and specially trained personnel.
Structured test scenarios as well as comprehensive function and performance tests are essential.
In addition other system parts (e.g. User-Exits) which are normally the object of individual procedures and extensions as part of the SAP introduction must be taken into consideration.
References
Please see the relevant publications in SAP TechNet.
History
| Last changed by/on | SAP | 19990223 |
| SAP Release Created in |
