SAP Credit Management

Configuration Guide

for SAP ERP 6.0

Contents:

1. SAP Credit Management – Overview 3

2. Credit Master Data 6

3. Customizing Organizational elements in FSCM – Credit Management 9

4. Process Integration 18

5. Maintaining Business Partner Master Data and Data Replication 25

6. XI Choreography in SAP Credit Management 30

 1. SAP Credit Management – Overview

Credit Management is used for managing the creditworthiness and payment behavior of
our customers/business partners which will have an immediate effect on the business
results of our company.

Purpose:

 Evaluating the creditworthiness of customers using internal rating policies and

external credit data thus enabling fast and consistent credit decisions.
 Organizations can use SAP Credit Management to reduce their delays in
payments, non-payments, and process costs, as well as to improve relations with
their top customers.
 Better credit control.
 Optimized terms and conditions for customers.
 Fewer doubtful or irrecoverable receivables

Why SAP Credit Management 6.0 when there is R/3 Credit Management?

R/3 Credit Management SAP Credit Management

Master Data FI-AR Account SAP Business Partner
FI Data Only FI-AR FI-AR, FI-CA, others
Monitor Credit Exposure Only for simple system- landscape Distributed system landscape
(1xFI, 1xSD) (multiple FI, SD and CRM
systems)
Customer Scoring/Rating Not available Credit Rules Engine
External Credit Only through partner products Any XML based credit
Information (e.g. D&B) information service
Rule based definition of Not available Credit Rules Engine
credit limits
Workflow Only in SD Create Workflow for any Credit
Event
Analysis Customer fact sheet Credit Manager Portal (incl.
Fact
Sheet and BW Content)
Connectivity for non Not available XI Server
SAP-systems
System Architecture:

Integration:

SAP Credit Management (FIN-FSCM-CR) enables to operate a centralized credit

management even in a distributed system landscape while taking account of both
internal and external credit information.

 The business systems connected (for example, Sales and Distribution, Logistics
Execution, Financial Accounting) report the commitment of a business partner to
SAP Credit Management (FIN-FSCM-CR) via XML.
 System-independent XML interfaces enables to connect internal systems such as
SD and Financial Accounting as well as the systems of external credit information
providers (external credit information). These systems report credit-relevant data
to SAP Credit Management on request.

The data reported is consolidated in SAP Credit Management and is available for many
types of credit checks at customer or customer group level. The analysis and results can
be accessed in SAP NetWeaver Business Intelligence or the Credit Manager Portal.
Features:

 Credit limit management

 Implementation of an organization-wide credit policy
 Central management of credit limits in a distributed system landscape
 Credit case
 Central, electronic creation of credit limit applications
 Status and result monitoring of credit limit applications
 Credit rules engine
 Categorization of customers using valuation rules
 Automatic calculation and assignment of customer-specific scores and credit
limits
 Check rule for credit decisions that are relevant to an order (order check)
 Credit information
 Interface for external credit agencies
 Input parameters for scoring formulas
 SAP BW content
 Credit manager portal
 Role-based access to credit management information and analyses

Summary:

 SAP Credit Management is a component of SAP Financial Supply Chain

Management.

 Customers are rated according to their credit risk and their sales volume
potential (scoring, risk class) in order to avoid non-payments, and also to improve
the organization's relationship to particularly appealing customers. The result is a
credit limit, on which the credit decision for the sales order is based
(specification of the payment and delivery conditions).

 SAP Credit Management enables automated scoring, risk class, and credit limit
calculations using formulas; central management of these evaluations;
integration of external credit information; and connection to SAP BW and SAP
NetWeaver Portal.

 SAP Credit Management can be connected as a central system to various

external systems (for example, SAP systems, non-SAP systems, or external credit
agencies) using the SAP NetWeaver technology SAP XI (Exchange Infrastructure).
 2. Credit Master Data

Organizational Elements in SAP Credit Management

 Credit Segment: Credit segment provides the flexibility to assign different credit
limits to a customer. Credit segment can be configured to represent e.g. a
business unit, sales organization or a product category.

 Business Partner: Business Partner is the application for managing all customer
related information centrally. It is an organizational unit for integration of
customer related information from all systems. The FI customer has to be linked
to the business partner. The SAP business partner is used in role UKM000
(Business Partner - credit management) to store data relevant for in SAP Credit
Management.

 The relationship between a business partner and a credit segment is same as the
relationship between a customer and a company code.

 The Business partner would contain a central or general data known as Credit
Profile data and data specific to each credit segment which is known as Credit
Segment Data.
Concept of credit Segment:

SAP Credit Management provides the option of maintaining several credit limits for one
customer using credit segments (one credit limit for each credit segment). The credit
segment corresponds to one or several credit control areas – a credit control area relates
to a company code or sales area, for example, depending on its configuration. This credit
segment is assigned to a main credit segment that can be used to define a total credit
limit on company level for the customer in addition to the individual credit limits on
"Sub-segment level".

In the course of the credit limit check (for example creating an order)

 The credit limit utilization of the customer in the corresponding credit segment
(customer's credit limit in this credit segment minus customer commitments that
are assigned to this credit segment) are checked along with The credit limit
utilization of the customer in the main credit segment (customer credit limit in
the whole company minus commitments of the customer that have accrued in
terms of the whole company).
Credit Segment Data for a Business Partner:

It is the data for checking the creditworthiness of a business partner for an order or
delivery within this credit segment.

When creating an order or delivery for a business partner, the corresponding credit
segment data of the business partner is used to check

 The current credit limit utilization (credit limit – total credit exposure, including
credit insurance, collateral), the manually set credit block (if present) and
 The payment history of the business partner

The credit segment data thereby forms the basis for the order-related credit decision for
this business partner, which includes the release (or not) of the order (or delivery or
non-delivery) and the characteristics of the payment and delivery condition including
any payment terms (credit).

We can also check the payment history of the business partner along with the last
dunned level, the highest open item, the last payment etc. in the business partner
master data.

Summary:

 Credit data is a component of SAP Credit Management and is stored in SAP

Business Partner. It consists of the credit profile data and the credit segment
data.

 The credit profile is used for the central storage of customer data relevant for risk
assessment (scoring, risk class, external rating, credit check rule).

 Credit segments can map various areas of a company (such as sales areas,
countries, company codes). They are used for area-specific administration of
credit limits (and their utilization) and to store information on the payment
behavior of the customer. The corresponding credit segment data is used for
credit checking when the order is created or on delivery within a company area.
 3. Customizing Organizational elements in FSCM –
Credit Management

Create Credit Segment:

Credit Segments are used for dividing our company in different branches. The
corresponding credit segments are used later in the master record of the business
partner.

Credit segments are required for calculating the credit limit and enable us to carry out
detailed checks at business partner level. When we define a credit segment, we also
decide on each currency in which all credit-relevant checks are to be carried out.

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Create
Credit Segments

Define Rating Procedure:

Rating procedures are used to process external credit information of our business
partners. We can use all of the ratings available for a business partner to calculate the
score.

External information providers, government organizations, or internal departments rate

business partners for different business processes. In General external information
providers could be, for example, Dun & Bradstreet, or Moody’s etc. The individual
providers each use their own rating names and procedures.

To compare and mix ratings from different internal and external information providers,
we make the rating procedure uniform by means of a ranking order that we assign the
different ratings from the providers to.
We can determine both External also Internal credit information for a business partner.
These information are used as input parameters for rating the business partner,
determining the credit limits of a business partner and aid in making credit decisions.
They are calculated based on various standard or customized formulae defined using
credit rules engine.

Note: For processing external credit information, SAP Credit Management is completely
integrated with major credit rating agencies and the information can be requested by
using appropriate XML interfaces which is explained in detail later. Internal credit
information can be obtained from ERP system and other components of FSCM like
dispute management. This information is also obtained using an XI interface.

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Define
Rating Procedure

Define Customer Credit Group

It is a category for grouping business partners. It can be freely defined according to the
requirements. This category is used as a selection criterion in reporting and during the
creation of worklists. E.g. Domestic customers, Foreign customers etc.

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Define
Customer Credit Group

Define Formulas

We define the formulas for calculating the score and the credit limit in this activity.

We define various formulae for calculating the score of a business partner. The score of
a business partner is a central level data and based on this score we can calculate the
credit limit of that business partner at the segment level. The credit limit is also
calculated based on the formula which has to be defined in this step.

To define the formulas, we can use the SAP Formula Editor. While creating the formula
itself, it has to be specified whether the formula is for score or credit limit.

In addition to some attributes of the business partner (for example, region, date of
birth), we can use additional fields in the formula editor. These are as follows for the
formulas for calculating the credit limit:

 Credit Segment
 Currency
 Score

We can enhance the functions further to meet our requirements using the BAdI:
Formula Parameters and Functions.

A formula can consist of the following steps that are processed from top to bottom:
  Condition
You define a logical expression whose result can be true or false. Depending on
whether the condition is true or false, the system triggers different steps. If you do
not specify any dependent steps for either of the options, the system continues with
the next step.

 Substitution
The system replaces the value of a specific parameter with another value that you
define as a constant value or using a mathematical formula. Depending on the result
category selected for the formula, a substitution can take place for the score or the
credit limit and additionally for interim results. You use interim results to structure
more complex formulas.

 Exception
The system exits the formula evaluation. There are no further steps, and the
application program continues in accordance with the exception defined.
You can also have the system issue a message with variables that you define as
constant values or using mathematical formulas.

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Define
Formulas
Create Rule for Scoring and Credit Limit Calculation

Once the relevant credit segments, the formulas required for calculating the score and
the credit limit are all defined, we have to define a rule to specify which formula to pick
score and credit limit for our business partner and for the relevant credit segment.

If the ratings from external credit information are to be used, then the relevant external
rating procedures are to be defined and the identification types are defined in the SAP
Business Partner. The identification type refers to the business partner attribute that an
external information provider uses to uniquely identify the business partner

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Create
Rule for Scoring and Credit Limit Calculation
Create Risk Classes:

In this activity we define the required risk classes for SAP Credit Management. We can
define any number of risk classes.

The system can then determine the risk class of a business partner from the partner's
score automatically or we can define it manually. We can also change the risk class
determined automatically in the business partner master data record. In this case, the
manual change overwrites the risk class determined automatically.

Path: FSCM  Credit management  Credit Risk Monitoring  Master Data  Create
Risk Classes
Define Blocking Reasons

We define the various reasons required for a credit assignment block. We can define the
block reasons as required. When we block a business partner, the credit analyst can see
the block reason in the master data record in the screen area Control.

We define various events and the follow on process in the next activity. The events are a
prerequisite for this activity. We have to assign the event for each blocking reason.

Path: FSCM  Credit management  Credit Risk Monitoring  Credit Limit Check 
Define Blocking Reasons

Define Checking Rules

We define the check rules required for the credit checks. A check rule can consist of
several individual checks (check steps). In addition we can define which parameters are
relevant for each check step.

Path: FSCM  Credit management  Credit Risk Monitoring  Credit Limit Check 
Define Checking Rules

Under Each Credit Rule we have to assign one or more credit steps. SAP delivers the
following individual steps:

Step Number Step Explanation

010 Statistical Check of Credit Exposure

020 Check for Maximum Document Value

030 Dynamic Limit Check with Credit Horizon

100 Check for Maximum Dunning Level

110 Check for Age of Oldest Open Item

120 Check of Payment Behavior Index

In addition, we can define and implement our own additional check steps using the
BAdI: Individual Step in Credit Check (UKM_CHECK_STEP).
Define Events and Follow-On Processes

We define the dependencies required between different events that can occur in the
processing of SAP Credit Management and processes of SAP Credit Management that
are to be triggered when these events occur. For example, if a business partner's score
changes, the risk class should also be changed accordingly.

We can also forward the information about events that are to occur to external systems
via an XI interface. The external systems themselves are responsible for any follow-on
processes in their systems.

Path: FSCM  Credit management  Credit Risk Monitoring  Processes  Define

Events and Follow-On Processes

Summary:
Before integrating the SAP Credit Management system with FI-AR or SD, the organization
structure inside SAP credit Management has to be finalized and configured. After
completing the master data configuration in SAP Credit Management we have to
configure the Credit Management system to integrate with FI-Accounts receivable and
SD, so that the exposures and the commitment are updated in SAP credit management.

The commitments posted in FI-AR and SD are updated in SAP Credit management only
through XML interface. The following customization needs to be completed from FSCM-
Credit management to complete the mapping between FI-AR, SD and SAP Credit
management. However XI mapping needs to be done separately.

4. Process Integration

SAP Credit Management supports the integration with financial accounting and sales
and distribution systems:
 Accounts Receivable Accounting (FI-AR) or Contract Accounts Receivable and
Payable (FI-CA)
 Sales and Distribution (SD)

These components provide SAP Credit Management with transaction data. They also use
the credit-relevant check options. The integration with the components specified
enables, for example, the following processes:

 Credit exposure update

Update of the credit exposure of a business partner in SAP Credit Management. The
financial accounting system connected provides the respective current commitment.

 Update of payment behavior summary

The financial accounting system connected provides the relevant data for the payment
behavior summaries for the business partners.

 Credit checks in Sales and Distribution (SD)

When you create or change a sales order or create or change a delivery with an order
reference, SAP Credit Management carries out credit checks according to the check rules
defined.

Integration with Accounts Receivable accounting:

We integrate FI-AR and SAP Credit Management by means of implementations of a
number of Business Add-Ins (BAdIs).

The first step is to Implement and activate the Business Add-In UKM_R3_ACTIVATE. In
the implementation, set the export parameters E_ACTIVE_FLAG and E_ERP2005 to X in
the method SET_ACTIVE.

By activating the above BAdI, the system will no longer perform the R/3 credit
management checks. All the processing related to Credit Management will be
performed through SAP Credit Management only.

Activate SAP Credit Management:

Path: FSCM  Credit management  Integration with Accounts Receivable Accounting

and Sales and Distribution  Integration with Accounts Receivable Accounting  BAdi
Activation of Credit Management

Define Credit Segment:

Define the credit segments that are to be used in Accounts Receivable Accounting (FI-
AR) and (SD).

Assign Credit Segment to Credit Control Area:

The integration between ERP FI or SD and SAP Credit Management at the highest level
happens through this assignment. The Credit Segment defined has to be assigned to
Credit Control Area and through this assignment postings made in FI-AR or SD updates
the corresponding Credit segment in SAP Credit Management.

Path: FSCM → Credit Management → Integration with Accounts Receivable Accounting

and Sales and Distribution → Integration with Accounts Receivable Accounting → Assign
Credit Control Area and Credit Segment
All the exposure posted in Accounting is updated to SAP Credit Management through XI.
During the update of open items to SAP Credit Management, the fields of the outbound
XI interface of FI-AR are determined according to the following rules:

 Business Partner Number = Customer

 Credit Segment = Segment assigned to the credit control area
 Credit Exposure Category = 200

However, we can influence this behavior by implementing the method FILL_FIELDS of

the Business Add-In UKM_FILL. We can change the default assignment to suit our
needs.

For postings in FI-AR, we can perform a credit check after we have entered the amount.
If we want to perform this credit check, we have to change the message type of message
UKM_PI 139. In the standard the credit check is not performed.

Integration with Sales and Distribution:

The following settings are necessary for calling up the credit check when we create or
change an SD order (from one or more SD systems) and to update commitments from SD
in SAP Credit Management. SD and SAP Credit Management are integrated by means of
implementations of Business Add-Ins (BAdIs) in the required customizing nodes in IMG
activities.
The credit check and commitment update are not supported for service orders.

The settings done under integration with FI like Creating Credit Control Area, Activating
Credit Management, Creating Credit Segments and Assigning Credit Control Area to a
Credit Segment are common. In addition to those settings we need to define additional
customizations which are explained below.

Assign Sales Area to Credit Control Area:

In this activity we assign a Sales Area to Credit Control Area. For a combination of Sales
Area, Distribution Channel and Division, we can assign a credit Control Area. Using this
orders posted in SD are updated in SAP Credit Management in the Credit Segment
assigned to the credit control area.

Path: FSCM → Credit Management → Integration with Accounts Receivable Accounting

and Sales and Distribution → Integration with Sales and Distribution → Assign Sales Area
to Credit Control Area

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. We enter the credit groups
when we configure the sales document types for credit management and define the
automatic credit check.

Path: FSCM → Credit Management → Integration with Accounts Receivable Accounting

and Sales and Distribution → Integration with Sales and Distribution → Define Credit
Groups
Assign Sales Documents and Delivery Documents

Credit checks can run at different times during order processing. For delivery creation,
we can additionally specify whether the automatic credit check occurs at the time of
delivery creation and/or goods issue.

In this menu option, we 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, we 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.

We also specify whether an automatic credit Check should happen or a simple credit
check has to happen. If we want a dynamic credit check then we should specify D as the
Credit Check option.

Path: FSCM → Credit Management → Integration with Accounts Receivable Accounting

and Sales and Distribution → Integration with Sales and Distribution → Assign Sales
Documents and Delivery Documents
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, we can define our own credit checks to
correspond to our requirements in the area of Credit Management.

We can determine an automatic credit check for any combination of the following:

 Credit control area

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

Example:
We can define a credit check for a certain credit control area and for all sales orders in
which the customer has risk class 2.
Summary:

Integration with Accounts Receivable or Sales and Distribution systems gets activated by
the implementation of SAP Credit Management through the BAdI UKM_R3_ACTIVATE.
Once the SAP Credit Management is activated, then all Credit checks takes place through
SAP Credit Management and the R/3 Credit Management checks will no longer be
performed.

Next Credit Segments which are to be used in FI-AR or SD are to be defined here and
they have to be assigned to the Credit Control Area. Whenever a document is posted or
order created in FI or SD in this credit control area, then it updates this credit segment
assigned here by default. Credit Limits for a customer are calculated specific for a credit
segment and thus this assignment is an important step in integrating SAP Credit
Management with FI or SD systems.

The Credit Checks performed when a Sales order is created or a delivery is carried out
are synchronous. This means that the when a order is created in SD, an online query is
sent to SAP Credit Management and only after the response is obtained does further
processing takes place in SD. But the commitments and exposures which are posted in
SD and FI are updated in SAP Credit Management asynchronously i.e. they are updated
not online. A separate program has to be sent which can be sent once in a day or
whenever processing is required.

5. Maintaining Business Partner Master Data and Data

Replication

Activating Business Partner role in Credit Management:

The credit master data of our business partners is the basis of SAP Credit Management.
It controls all credit-relevant ratings and analyses. In order to be able to edit the credit
master data of our customers, the business partner role must be active for SAP Credit
Management (UKM000 Credit Mgt Business Part).
Path: Enter transaction BUS1 in the easy access screen.

To check the screen sequences:

Path: Enter transaction BUS6 in the easy access screen.

Define BP Roles

This step is required to add and activate the Business partner role UKM000 so that it the
business partner can be created in this role.

IMG Path: Cross-Application Components  SAP Business Partner → Business Partner →

Basic Settings → Business Partner Roles → Define BP Roles.

Creating Role Category:

Creating Role:

Once the above configuration is done, in the BP master data, we can see the Credit
Management role and also a credit segment area to maintain data related to Credit
segments.
Data Replication and providing Business Partner Data:

The master data of SAP Credit Management is an enhancement of SAP Business Partner.
A master record of SAP Business Partner must exist in the system and client in which SAP
Credit Management is run for each business partner that we wish to monitor.

Integration of Business Partner with SAP Credit Management:

 If SAP Credit Management is installed in a system in which business partner

master records already exist, SAP Credit Management can easily access these
tables. The system creates the credit master data as an enhancement of the
existing business partner master records.

 If SAP Credit Management is in a system in which no business partner master

records exist, for example, a stand-alone system with its own server, then we
have to supply the business partner master records with business partners or
customers from another business system of our landscape (by means of master
data replication). Copies of the master data of SAP Business Partner are then
created in SAP Credit Management.

Master data is copied from FI customers in the same system as SAP credit management
by means of Master Data synchronization and Data distribution.

Master Data Synchronization:

Master data synchronization synchronizes master data objects in an SAP system that are
similar from a business, but not from a technical, point of view, and in this way allows to
integrate different SAP applications seamlessly in our business processes.

We can use master data synchronization to set up integration of the SAP Business
Partner with the customer master. This allows us to integrate SAP applications that make
technical use of the Business Partner in their user interface, and use the customer
master as a technical basis in subsequent business processes.

Synchronization Directions

A synchronization process is always defined as a one-way synchronization between a

source object type and a target object type, meaning that the synchronization is only
ever active in one direction, from the source object type to the target object type. If the
data of an object instance of the source object type is changed, the corresponding data
in the corresponding object instance of the target object type is also changed at the
same time. Both synchronization directions must be activated in the SAP system in order
to allow the undirected synchronization of two master data object types.

Synchronization Scenarios

There are two synchronization scenarios in master data synchronization:

 Synchronization from the master data maintenance

When we create and save new master data, the system carries out initial synchronization
with the master data object types for which synchronization processes have been
activated in the SAP system, and creates the corresponding master data.

Later if we change existing master data that has already been synchronized, the system
locks this master data, and all the corresponding master data of the source object type
and the target object type during maintenance. When we save the changed master
data, the system generally carries out a delta synchronization with the master data
object types for which synchronization processes have been activated in the SAP system,
and changes the corresponding master data. In some cases, changing existing master
data can lead to a delta synchronization having to be carried out.

 Synchronization using the synchronization cockpit

We can use the synchronization cockpit to prepare, perform and check the initial
synchronization of master data objects in an SAP system.

Note: Master data synchronization cannot be used for synchronizing master data across
the systems and neither it can be used to transfer data from external systems.
Synchronization Cockpit:

Using the synchronization cockpit, we can carry out all the steps for master data
synchronization in an SAP system.

These are as follows:

 Customizing synchronization
 Selection, preparation and starting of synchronization runs.
 Monitoring of synchronization runs
 Post-processing of synchronization errors

Customizing synchronization: The synchronization of master data-related Customizing

data between the Customizing tables of the source and target objects reduces the
number of synchronization errors that can occur during a synchronization run. With this
function we can let the system carry out synchronization by means of synchronization
reports. This is mainly used for mapping master data of Business Partner with
Customer/Vendor.

Master Data Maintenance:

Set BP Role category for Customer Integration:

In this IMG activity we can define which BP role categories enable customer integration
in the direction from the business partner to the customer. We can determine how the
system creates a corresponding customer in Financial Accounting when you process a
business partner.

Path: Cross-Application Components  Customer/Vendor integration  BP Setting 

Setting for customer integration  Set BP Role Category for Direction BP to Customer.
Define BP Role for Direction Customer to BP:

Here we assign the BP roles to the corresponding account group of the customer master
record in which the business partner is to be created when processing the customer.
Thus when we create a customer in this account group, a business partner in this role
would be automatically created.

Path: Cross-Application Components  Customer/Vendor integration  BP Setting 

Setting for customer integration  Define BP Role for Direction Customer to BP.

Define Number Assignment for Direction Customer to BP:

We assign the groupings for the business partner to the account groups of the customer
master records to ensure that when we process customers as part of customer
integration the system also updates the business partner at the same time.

The system automatically creates the business partner with the business partner
number that is intended for the relevant account group for the customer/vendor in this
IMG activity on the basis of the BP grouping.

Path: Cross-Application Components  Customer /vendor integration  BP Setting

 setting for customer integration  Field Assignment to customer integration 
Assign Keys  Define Number Assignment for Direction Customer to BP.
Summary:

Business Partner forms the central organizational entity in SAP Credit Management at
which level, we can manage all the commitments, exposure etc. Hence it is required to
link all the transactional data i.e. mainly exposures/commitments from other systems
like FI-AR or from external systems to the Business Partner in SAP Credit Management.

Thus it is required to synchronize the master data so that the required link between
other systems and SAP credit Management can be achieved. The synchronization can
be achieved by creating a business partner for every customer in FI-AR and linking both
the customer and business partner. There are various standard means of achieving the
same like master data maintenance and synchronization cockpit and any method can be
adopted depending the requirement.
 6. XI Choreography in SAP Credit Management

We can use SAP Credit Management and other integrated components in a single system
landscape or a multiple system landscape. We can collect, manage, and analyze credit
information from connected systems and components centrally. This architecture also
enables us to distribute and use the credit information effectively in the systems and
components connected.

Examples of the cross-system/component information flow are:

 Credit exposure update from Accounts Receivable Accounting (FI-AR) to SAP

Credit Management
 Credit check in SAP Credit Management on creation of a sales order in Sales and
Distribution (SD)
 Update of the credit exposure in SAP Credit Management based on data from
Sales and Distribution (SD) and Accounts Receivable Accounting (FI-AR).

The data exchange is processed via XML interfaces (XI), which means that we can
connect both SAP and non-SAP systems.

Application Components necessary:

Component/System Minimum SAP Comments

Release
SAP Credit Management Financial Basis The following SAP notes provide the
(FIN-FSCM-CR) 6.00, latest prerequisite:
Support Package 07  967611
 969190
SAP NetWeaver 2004s Mandatory
Application Server
SAP NetWeaver Exchange 7.0 Mandatory
Infrastructure
Accounts Receivable 4.6C; Plug-In Optional
Accounting (FIAR) 2004.1
Sales and Distribution (SD) 4.6C; Plug-In Optional
2004.1
External Credit External system Optional
Information
Financial Accounting External system Optional
Sales and Distribution External system Optional
XI Choreography:
Important and widely used XI interfaces in SAP Credit Management:

XI Interface Description
SAP A2A-Interface CreditWorthinessQuery_In Credit query
SAP A2A-Interfaces CreditCommitment_In and Credit exposure update
CreditCommitment_Out
SAP A2A-Interface CreditPaymentRecord_In Payment behavior summary
(reduced scope)
SAP A2A-Interface Payment behavior summary
CreditPaymentBehaviourSummaryNotification_In
SAP B2B-Interface CreditAgencyReportQuery_Out External credit information
SAP A2A-Interface Request for data of the credit
CreditManagementAccountByIDQuery_In account
SAP A2A-Interface Change to the data of the credit
CreditManagementAccountChangeNotification_In account
SAP A2A Interface Critical business partners
CreditWorthinessCriticalPartiesQuery_In
SAP A2A-Interface Reporting of events to connected
CreditWorthinessChangeInformation_Out systems
SAP Component-Interface FICARatingReplicate Comparison of FI-CA
creditworthiness with score from
SAP Credit Management

SAP A2A Interface CreditWorthinessQuery_In

The interface CreditWorthinessQuery_In requests information about the credit-

worthiness of business partners. It uses the following message types:

 CreditWorthinessQuery: Determines the structure of the creditworthiness query

of a business partner.
 CreditWorthinessResponse: Determines the structure of the response message
containing the required details about the creditworthiness (for example, score
and credit limit) of a business partner.

The application that wants information on the creditworthiness of a business partner

(for example, Accounts Receivable Accounting or Sales and Distribution) sends a query
to SAP Credit Management, and SAP Credit Management returns the required
information such as the score and recommended credit limit for the business partner.
This information influences, for example, the decision in the requesting application as to
whether or not to have business dealings with this business partner.
Message Interfaces

CreditWorthinessQuery_In (inbound, synchronous)

When an application sends a creditworthiness query, the message interface is the
inbound interface to SAP Credit Management. The query is synchronous. The message
interface uses the message types CreditWorthinessQuery and
CreditWorthinessResponse.

Message Types

CreditWorthinessQuery
This message type uses the data type CreditWorthinessQueryMessage that represents
a message for querying creditworthiness.

CreditWorthinessResponse
This message type uses the data type CreditWorthinessMessage that represents a
response to the creditworthiness query.

Data Types

CreditWorthinessQueryMessage
The figure below shows the data type CreditWorthinessQueryMessage that contains an
entry of the data type CreditWorthinessQuery.
The data type CreditWorthinessQuery contains the following elements:

 CreditSegmentInternalId – Credit segment in SAP Credit Management

GDT: CreditSegmentInternalID
 CheckedAmount – Amount to be checked (such as the order value)
GDT: Amount
 CheckingRuleCode – Encoded display of the rule to be used to determine the
creditworthiness
GDT: CreditWorthinessCheckingRuleCode
 CheckingServityCode – Encoded display of the severity of the check procedure to
be used
GDT: CreditWorthinessCheckingSeverityCode
 CreditAgencyReportRetrievalPermissionIndicator – Indicator to show whether or
not a business partner has granted permission for credit information to be
obtained about him or her
 GDT: CreditAgencyReportRetrievalPermissionIndicator
 DebtorParty – Customer whose creditworthiness is to be determined
GDT (InternalId): PartyInternalID
 CreditorParty – Not used in SAP Credit Management
 SellerParty – Not used in SAP Credit Management
 ProductCategory – Not used in SAP Credit Management

CreditWorthinessMessage

The figure below shows the data type CreditWorthinessMessage that contains an entry
of the data type CreditWorthiness.
The data type CreditWorthiness contains the following elements:
 CreditSegmentInternalId – Credit segment in SAP Credit Management
GDT: CreditSegmentInternalID
 Indicator – Specification of whether there is a creditworthiness for the business
partner for the query parameters specified
GDT: CreditWorthinessIndicator
 CheckingDescription – Description of the flow of a creditworthiness check
GDT: Description
 DebtorPartyBlockedIndicator – Specification of whether the business partner is
blocked in SAP Credit Management
GDT: Indicator
 DebtorPartySpecialAttentionRequiredIndicator – Specification of whether the
business partner should be subject to special attention
GDT: Indicator
 DebtorParty – Customer whose creditworthiness was determined
GDT: PartyInternalID
 CreditorParty – Not used in SAP Credit Management
 SellerParty – Not used in SAP Credit Management
 ProductCategory – Not used in SAP Credit Management
 Rating – Score of a business partner determined by SAP Credit Management and
valid for a specific period
Rating contains the following elements:
Code – Coded display of the score value
GDT: CreditRatingCode
ValidityPeriod – Validity period of the score value
GDT: DateTimePeriod
 RiskClass – Payment default risk determined by SAP Credit Management and
valid for a specific period
RiskClass contains the following elements:
Code – Coded display of the risk class
GDT: CreditRiskClassCode
ValidityPeriod – Validity period of the risk class
GDT: DateTimePeriod
 CreditLimit – Credit valid for a business partner for a specific period
CreditLimit contains the following elements:
Amount – Amount of the credit
GDT: Amount
ValidityPeriod – Validity period of the credit
GDT: DateTimePeriod
  CreditExposure – Current credit exposure of the business partner
CreditExposurecontains the following element:
Amount – Amount of the credit exposure
GDT: Amount
Mapping Objects

Interface Mapping UkmCreditQuery_CreditWorthinessQuery

This interface mapping connects SD systems with release version 4.6C or 4.70 to the
credit check in SAP Credit Management. It is delivered with the XI content of the
software component version FINBASIS_300 from support package 06. It maps the
interface of the RFC module UKM_CREDIT_QUERY to the interface
CreditWorthinessQuery_In.

Message Mapping UkmCreditQuery_CreditWorthinessQuery

The interface mapping with the same name described above uses this message
mapping. The message mapping is also delivered with the XI content of the software
component version FINBASIS_300 from support package 06.

For details on other XI interfaces help.sap.com can be referred or SAP Credit

Management Configuration guide can be used.

Summary:

XI Interfaces an important part in Credit Management Landscape as they carry

information to and from SAP Credit Management system. They form an integral part of
the Credit Management system in place. Irrespective of the landscape used like whether
a single system or a multi system scenario, XI interfaces are mandatory for the data flow
between SAP Credit Management systems.

For every possible update the corresponding XI interface has to be mapped and proper
link between all the systems are to be maintained. Standard interfaces are already
available for all the scenarios. Any external server which support XML interface can be
connected to the SAP Credit Management system through the XI server.