Financial Supply Chain Management

Copyrights © 2012 SAP AG Germany

Copyrights © 2012 SAP AG Germany

FSCM General Overview

Notes on SAP Financial Supply Chain Management (FSCM) General introductory notes

SAP's intention is to provide business benefit through improving working capital. The chief thrust is to increase the

speed of customer payments, and reduce the amount of number of debtors who have a reason not to pay.

The main components are Credit Management, Collections Management, Dispute Management, and Electronic

Invoicing.

Credit Management

It's different from traditional SAP credit management because it aims to become a central function in a distributed

environment. The old system used SD and FI on the same R/3 system. FSCM Credit Management brings in CRM

systems, external logistics systems (both distributed SD and non-SAP systems), and can present the results through a

BI system and a Portal.

Features

Credit limit for the customer (and order limit, risk class)

Credit Rules Engine, which takes information and automates credit scoring, credit decisions and calculations of credit

limits

Credit score, determined from externally and internally-collected information. Both automated and manual updating of

credit scores are possible. Each customer has a credit scoring procedure, and a mass recalculation can be run to re-

evaluate scores.

Note function, for credit controller to record additional information

Document storage, to attach any external items (bank records, credit reports)

Automated credit decisions for most cases allow you to concentrate on the exceptions.

Communication with external rating agencies via XML

Analysis

Credit decision support function, consolidates data from several systems, summarised on a customer credit fact sheet,

which can be accessed through the credit manager cockpit in the Portal.

Credit scoring to identify risk from customers and their debt

Monitoring of customer payments, to identify problems quickly

Concentrate marketing effort on low-risk customer groups.

Dispute Management

This module aims to reduce the time spent handling disputes between companies and their customers. Often, a credit

control clerk can spend 50% of their time dealing with these cases. It also aims to speed up the time to collect the cash

from the customer.

Features

Create a new dispute case from the list of open items, or within a specific transaction (e.g. Process Incoming Payment,

if it's been reduced below the invoice amount).

Assign roles to the dispute case, each role having different tasks. The case notes can hold questions for colleagues, or

comments about the dispute, and add up to the complete case history.

Cases become classified, and managed according to processing status, and the reason for the dispute.

The important documents can be attached to the case, both SAP documents and external ones.

The case may be escalated to the next management level if an action isn't carried out.

The case may hold actions, which can be flagged for follow-up. The case may be escalated to the next management

level if an action isn't carried out.

Electronic Invoicing (Biller Direct)

This module aims to reduce the eliminate inefficient techniques (and the costs) of packaging and mailing paper invoices

to customers. It also provides vendors with online visibility of their invoices on the SAP system.

Copyrights © 2012 SAP AG Germany

It is the web-based invoicing engine of SAP FSCM.

Customers can execute payments for open invoices using direct debit or credit card. These are not standard, delivered

functions, but require configuration work.

Customers can view images of their invoices through the Portal, but only if some programming effort is used to generate

PDF images for storage on the document server. This technique can be used to make available images from non-SAP

invoicing modules.

It can save the work of the AP department in answering vendor queries over invoices, whether they have been blocked,

and when they will be paid.

Customers can be given the ability to create dispute cases on their own invoices, if they have grounds for withholding

payment.

Biller direct has facilities allowing customers (and vendors?) to access the portal, and request user profiles.

It can provide the access via SAP Enterprise Portal, or any other portal using single sign-on tickets. It can also be

integrated into the Supplier Portal. It can be run as a stand-alone application based on J2EE.

Vendors do not need to install any SAP software in order to use this, merely a standard internet browser.

SAP recommend the use of Secure Network Communicator to make the communication between WebAS and ERP

secure.

In some countries (probably the UK) the Data Protection Act requires that you obtain authority from customers to

capture and hold their details (e.g. bank & credit card details) on your computer.

Collections Management

The Collections Management module allows organisations to manage individual AR accounts, in cases where bulk

dunning will not be effective. It's an efficiency tool for AR clerks, and aims to create prioritied work-lists of key customer

accounts for action.

Features

Target "delinquent" accounts for action, offer discounts more intelligently, and retain the best payers.

Automatically selects the customer accounts needing action, and prepare work lists for action. The application is based

on a collection strategy for customers, identifying how the priorities are set up. AR clerks are given information on why

the contact is necessary, and what previous contacts have been made.

The AR clerk may log the customer's promise to pay, or a dispute case (for Dispute Management). If the clerk cannot

make contact, or the customer wants calling back, the clerk enters a "resubmission".

Once a clerk has made contact with the customer, SAP Collections Management removes them from the worklist.

SAP Collections Management monitors whether the customer keeps their promise to pay, and if not, they get put back

on the work list.

Analysis

The AR Supervisor has functions to control and supervise the work of debt collection. The system provides statistics on

how many work list items have been completed (successfully or unsuccessfully), and how many are still open. The

supervisor has the ability to re-assign the work lists over the AR clerks.

Copyrights © 2012 SAP AG Germany

FSCM Terminology

FSCM Terms

Collection Profile: For collecting receivables using sap collection management a collective profile is assigned to every

customer.

Collection Segment: ( The collection segment is assigned to collection profile) It groups company codes of a company

from the view of SAP collection management, so that transaction data( such as: open items, dispute cases, promise to

pay) of a business partner from these company codes can be considered together.

Collection Group: A collection group consist of collection specialist that are to make contact with customer in SAP

collection management. All specialist in a collection group collect open receivables from business partner with the

same collection strategy.

Collection strategy: It controls the priority of a work list item.

Collection segments are assigned to collection profiles by IMG activity (table UDM_PROF_SGMT gets updated) and

collection groups to collection segments (table UDM_SGMT_GR). So when you assign a collection profile to Business

Partner, the segment and collection group gets updated based on the IMG configuration done.

Biller Direct

Biller Direct is an online view of a customer account.

This is aimed at two markets.

One: Clients who have lots of small customers, like utility clients or telecommunication sector clients. This offers the

customer an online view of their account, ability to make payments, update master data and dispute open items.

Two: Clients with large and difficult customers. By providing large and difficult customers with an online view of their

account, they can raise their own disputes, removing the need for the client to do this as well as pull off copy invoices.

Certain customers may make large requests, and rather than ask the clients cash collectors they can do this all

themselves.

Collections Management

Before understanding Collections Management, it is important to understand what is available in the current solution (FI-AR) and the benefits that Collections Management will give you.

5 reasons why your Accounts Receivable team should be using a Collections Work

list within SAP FSCM

The Collections Worklist can only be found within SAP FSCM and is part of the Collections Management module

of SAP FSCM. This is the tool SAP have provided to the Accounts Receivable team to assist them to perform

their daily duties of collecting cash. The Collections Worklist provides a priorities list of customers for the

Accounts Receivable team to contact. The Worklist can be priorities according to client's unique requirements

with the highest ranking customers appearing at the top of the worklist and the lower priority at the bottom of the

worklist.

The real benefits of a Collections Worklist are around a single system and process where there is full visibility of

actions that have occurred whilst contacting a customer. To achieve some of these without SAP FSCM could

only be achieved by either using a third party software provider or my bespoking your current SAP Accounts

Receivables solution to align to your own requirements.

Copyrights © 2012 SAP AG Germany

Below are my top 5 reasons why your SAP Accounts Receivable team should be using the functionality with SAP

FSCM:

1. Uniformity of process:

Within SAP Collections Management there is a clear Organisational structure that enables you to group

customers into different segments and groups. These normally align to legal entities and teams within an

Accounts Receivable team. A Collections Worklist is easy to use and if a member of the Accounts Receivables

team was on holiday or off sick a different team member could pick up another Worklist without needing a formal

handover.

2. Prioritization of Accounts:

One of main benefits of the prioritized Worklist is that the team member does not have to work out which

customers to contact on a specific day, it is done for them. This will stop low risk customers being contacted, and

enforce more effort being driven towards higher risk customers. The true benefit of this is that the prioritization is

fully customisable allowing a client to make its own rules up. This is a massive benefit when comparing it to a

standard Aged debt report in SAP Accounts Receivable which can only be sorted by Name of Customer, or

amount of outstanding debt.

3. Performance Management:

It is one thing providing your Accounts Receivable team a new tool to help collect cash but to see the true worth

of the change of process and solution you need to report on the benefit. With SAP Collections Management you

have the ability to record the number of customers contacted by an Accounts Receivable team member over a

period of time. You can then use this data to compare that team member against their peers. This will allow the

Accounts Receivable Manager to track the performance of the team members and make informed decisions

based on those findings.

4. Ability to record and report on notes made:

One of the biggest gripes regarding the existing SAP Accounts Receivable solution related to the notes that a

team member would make. Some used to print of reams of Aged Debt, and make hand written notes regarding

the customer contact. This is OK for the team member, but it does not help the Manager or a replacement who is

thinking about contacting a customer. By having the ability within the Collections Worklist to record, and therefore

report on the notes made by the Accounts Receivable team member provides a single reference point, which can

be easily accessed by any authorized user.

5. Integration to Dispute and Credit Management with SAP FSCM:

Collections Management has been built so it easily integrated with the other modules of SAP FSCM. From the

Collections Worklist, a user can raise, change and display customer Disputes that may have been raised. On the

front screen of the Worklist there is a specific column to detail the value of outstanding debt currently under

"Dispute". This is used to inform the team member that whilst a customer might have $300,000 of outstanding

debt, if they have say $50,000 in dispute, then the amount to collect will be $250,000. Please note standard

Accounts Receivable has not notion at all regarding customer disputes, so this is a massive step forward.

Further to the integration with SAP Dispute Management, is the integration with SAP Credit Management within

SAP FSCM. Within SAP FSCM Credit Management is the ability to calculate a "credit score" against a customer.

This in turn can influence the "risk class" of the customer. What makes SAP FSCM Credit Management a better

proposition that its standard relation in core SAP Accounts Receivables is the benefit of using actual SAP data to

"score" a customer. The traditional method as standard was to either use offline methods, or third party scoring.

The Collections Worklist can be prioritized by a number of different criteria, including the value of customer

disputes and the risk class that is derived from SAP FSCM Credit Management.

Copyrights © 2012 SAP AG Germany

Collections Management is a sub-module of FSCM

The aim of the tool is to record actions made with the customer and to enable the user who is collecting the cash to do

so in a proactive format. The use of work lists enables the user to have their day planned for them, by pre-defined rules

set against all of the customers.

This should lead to the correct customer being called at the correct time and remove duplicate calls.

If a certain customer always pays late this could be flagged up, and all customers who pay on time would be seen as a

lower risk and only appear on the work-list if their payment did not turn up.

The concept of a "Promise to Pay" can be used to help the cash team work out how much cash is due in, and also track

where these promises are broken. The system can be designed to fit all business processes, and there are plenty of

BAPI's that can be used to make sure the work lists are being generated correctly.

Lastly the collections team will have access to what has been disputed and even create disputes directly through

collections management. This allows certain rules to be written to influence what should be expected to be collected

depending on the status of the dispute.

With SAP Collections Management, you can proactively manage overdue receivables and prioritize collections efforts

for maximum success. The software uses a collections work list with an overview of each past-due account, including

open invoices, dispute cases, and contact history, ensuring that collections agents have all the information they need

when contacting a customer. In addition, agents can easily document the results of each customer contact and create

promises to pay. Working with SAP Collections Management, you can achieve higher collection success rates, thus

accelerating cash flows, lowering DSO, and minimizing the risk of bad debt write-offs.

The components of SAP Collections Management support you in active receivables management. Using collections

strategies, you can evaluate and prioritize customers from receivables management view. Customers that fulfil the rules

defined in a strategy are distributed to the work lists of the collection specialists. The collection specialists then contact

the customers in their order of priority in order to collect receivables.

To prepare the customer contact, you can use various key figures for the customer in the work list. You can also display

an overview of the current status of the open invoices of a customer account as well as the last payments, the customer

contacts, and open resubmissions. If a customer gives a promise to pay, you can enter this in the system and follow its

status. You can also define that a customer is to reappear on the work list on a certain date. When you return to the

work list, you can document the complete customer contact in the system.

Collection Management can be divided into four phases.

1) Selection of Customer (All customer should be business partners then only they can be assigned in collection

management) - one of the key steps is to create all customers as collections management business partners.

For more information on this please refer to the following

article.http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/b001aec0-b12d-2d10-3faa-b416e6de0270

2) Prioritization of Customer based on Collection Strategies.

3) Preparation of Customer Contacts

4) Processing of receivables.

Tcodes in Collection Management:

1) UDM_SPECIALIST - My Worklist

2) UDM_SUPERVISOR - All Worklists

3) UDM_BP - Business Partner Master Data - to create and maintain business partners.

4)UDM_STRATEGY - Strategies

5)UDM_GROUP - Groups

6)UDM_GROUP2SGMT - Assign Groups to Segments

7)UDM_GENWL - Creation of Worklists

8)UDM_RSM_DELETE - Deletion of Resubmissions

9)UDM_BP_PROF - Assignment of Profiles

10)UDM_BP_GRP - Change to Segment Data

11)UDM_BP_SPEC - Assignment of Collection Specialists

12)FDM_COLL_SEND01 - Distribution of Data to Collections Management

13)FDM_JUDGE - Evaluation of Promise to Pay

Copyrights © 2012 SAP AG Germany

14)FDM_P2P_CONFIRM - Confirmation of Promise to Pay

15)FDM_COLL01 - Edit Receivables (Old)

Terms:

Collection Profile: For collecting receivables using sap collection management a collective profile is assigned to every

customer.

Collection Segment: (The collection segment is assigned to collection profile) It groups company codes of a company

from the view of SAP collection management, so that transaction data( such as: open items, dispute cases, promise to

pay) of a business partner from these company codes can be considered together.

Collection Group: A collection group consist of collection specialist that are to make contact with customer in SAP

collection management.

All specialists in a collection group collect open receivables from business partner with the same collection strategy.

Collection strategy: It controls the priority of a work list item.

Collection segments are assigned to collection profiles by IMG activity (table UDM_PROF_SGMT gets updated)

and collection groups to collection segments (table UDM_SGMT_GRP) So when you assign a collection profile to

Business Partner, the segment and collection group gets updated based on the IMG configuration done.

You can use SAP Collections Management as a one-system or as a multiple-system scenario.

In a one-system scenario, Collections Management is in the same system as Accounts Receivable Accounting.

In a multiple-system scenario, you run Collections Management in a separate system. This communicates with the

system of the Accounts Receivable Accounting connected

by means of Application Link Enabling (ALE).

Dependent on the release of Accounts Receivable Accounting, you can either select between a one-system scenario

and a multiple-system scenario or you

can only use SAP Collections Management in a multiple-system scenario.

If you connect more than one accounting system to the Collections Management system, then you have to indicate the

company codes of these accounting

systems in Collections Management, and also enter them as a filter for the BAPI AccessProcessReceivables for the

object Collection Data.

Credit Management

FSCM Credit Management is not to be confused with the original Credit Management.

A quick overview of credit management within FSCM

It’s time to implement SAP FSCM Credit Management

Standard Credit Management has been around for a long long time. It is a stable solution that is widely used and

provides a good tool for most clients that use it. The point people are missing is that the SAP FSCM solution

takes Credit and Risk Management to another level. The benefits are so significant that I believe the product is a

must have.

The main benefits can be broken down into three areas.

Enabling you to make better decisions

Full integration of the process

Use of internal data for credit analysis

To fully understand the business benefits of SAP FSCM Credit Management, it is important to review how

standard SAP Credit Management is used and the associated processes.

Copyrights © 2012 SAP AG Germany

Common usage of SAP Credit Management

A common customer will load external data from credit rating companies into their Credit Masters. This will

enable them to categorise the customer into a Risk Category. After this there will then be some manual work to

derive a credit limit based. This process needs to occur at set intervals to ensure the customer has the correct

Risk Category.

Aside to this, there are ad-hoc processes where a credit limit is reviewed, and the external credit rating company

will re-classify the customer. Within SAP it is not easy to identify the number of times the customer went above its

agreed credit limit, how many times the Credit Limit was changed and whom and when this was requested.

Enabling you to make better decisions: This should be the key objective for a SAP FSCM Credit Management

implementation. Within SAP FSCM you have the ability to use actual SAP data to set credit limits for customers

or to group your customer into a risk category.

Example: You may find that your external credit rating company has a good score, as the customer pays its other

suppliers in 35 days. In isolation this would be used to provide a good credit rating for the customer and a good

credit limit. However if you analysed your SAP data and saw that the same customer was paying you on say 65

days, you would be less inclined to give them a good credit rating, you would give them a poor score, and would

be hesitant to provide them with a good credit limit. Comparing actual payment terms against the terms supplied

from external credit ratings could help you improve the relationship with the customer. You could share this

information with the Collections team and the sales team to re-negotiate the agreed payment terms and try and

reduce their average payment days down to align with that of your competitors. Remember, high levels of bad

debt are really just an historic trend. No one knows what is round the corner and so implementing an enhanced

solution with more accurate information allows you to make better decisions for your business.

Full integration of process: The traditional SAP Credit Management solution requires a high degree of manual

processing. A key benefit within SAP FSCM Credit Management is the ability to request a credit limit change

from within SAP FSCM. This is a simple case that records the request for a new Credit Limit and is easy to

approve. Further to this the process can be integrated to propose Credit limits based on both internal and

external data. This removes the manual offline calculations and provides a consistent approach. Data from

external credit agencies can be automatically uploaded into SAP, and interfaces can be built. The manual steps

of combining many external credit agency scores into a single score is also removed within the new functionality.

Use of internal data for credit analysis: This is the most commonly used benefit for SAP FSCM Credit

Management. This is the most noticeable difference between the two solutions and the one that grabs the

headlines and rightly so. The use of internal SAP data is a major step forward for both credit rating and credit limit

proposals. A customer’s credit rating could change dramatically within SAP FSCM for late payments, high levels

of credit exposure and high dunning levels, something is missed by external Credit rating agencies.

Summary

You can measure the benefit of reducing the manual effort of creating new credit limits and reviewing changes,

however you cant see the full benefit around future bad debt. Comparing your current bad debt for a fiscal year

only indicates how you performed against a previous year. This cannot serve as an indication as to the future

trends of bad debt.

Being able to quickly identify when a customer changes its payment behaviour, or repeatedly asks for a Credit

Limit increase is something that you can track within SAP before the customer turns into a bad debt. It is also a

recommended approach to analysis the customers that became a bad debt, to see if you can spot any trends and

Copyrights © 2012 SAP AG Germany

build warnings against these within your process. By changing your processes and using actual data will enable

you to make better decisions and avoid potential bad debts.

The new Credit Management has a more global view to it, it works on a different Org structure and can use internal and

external ratings to rate customers and provide a credit score.

The main difference here, is that internal credit scores can be generated, again, this is very flexible and this can be

used to work out the amount of credit a customer should be given, and can also work with external systems as well.

The combination of this should ensure that the amount of credit granted to customers follows the strict policies of ALL

clients.

The implementation of FSCM Credit Management requires XI (PI). - there is a useful blog on the subject of the PI

configuration steps –

FSCM: Configuration Scenario Sap Netweaver PI 7.1

SAP Credit Management (FSCM) enables you to assign a certain credit limit to each customer. For example,

when an invoice is posted, the system checks if the amount exceeds this limit. Differents scenarios are provided:

FI-AR (Accounts Receivable)

FI-AR and SD (Sales and Distribution)

...

This blog gives you an overview of FI-AR and SD scenario: you need to configure a specific interface on the SAP

NetWeaver PI 7.1.

SAP provides standard packages for SAP NetWeaver PI:

SAP APPL

FINBASIS

SAP ABA

SAP BASIS

First, create a business system on SLD (System Landscape Directory).

Copyrights © 2012 SAP AG Germany

Now you can import the standard packages previously downloaded from Sap MarketPlace with Enterprise

Services Builder tool.

Through the integration builder you must create a scenario:

e.g. named "Credit_Management"

For this scenario, you must create two communication channels that allow data transfer between SD and FI-

AR. Both channels point to an RFC destination of type “HTTP Connections to ABAP System” created

by transaction SM59 in SAP NetWeaver PI

Copyrights © 2012 SAP AG Germany

--> Note: the user that is used by RFC Destination must have role for the use of FSCM on ECC 6, otherwise you might have

problems with the update of the financial data of the business partner (for example: “Error during update of credit exposure

information – UKM_BP 001)

After you have configured properly the two channels, various interfaces can be created to suit your needs:

Copyrights © 2012 SAP AG Germany

-->Note: I implemented also this BADI:

UKM_FILL

UKM_R3_ACTIVATE

UKM_VECTOR_PUSH

All the interface informations can be found on the official documentation “Sap Credit Management –

Configuration Guide”.

Copyrights © 2012 SAP AG Germany

The following Blog (Article) covers how FSCM Credit Management is linked to XI so data from SAP Finance can be

used by the FSCM sub-module.

SAP FSCM - Credit Management Implementation using XI

Introduction to FSCM:

Financial Supply Chain Management (FSCM) is an integrated approach to provide better visibility and control

over ALL cash-related processes.

Better predictability of cash flow

Reduction of working capital

Reduction of operating expenses

End-to-end integration of business processes

Components of SAP FSCM

1. SAP Credit Management, Controlling credit risk via real-time credit allocation and ongoing monitoring i.e. online credit

rating check for fast credit decision

2. SAP Biller Direct, Display of bill and payment history and account balances

3. SAP Collections Management, Comprise company specific rules for collecting receivables and Used to select and prioritize

customer accounts for the collection

4. SAP Dispute Management, Cross-department dispute resolution, All information is centrally stored and structured

(electronic record)

5. SAP In-House Cash, Management of internal bank accounts for all subsidiaries

Purpose of Blog

In this blog, you can able to see how to configure XI settings for SAP FSCM-Credit Management to generate

Credit Limit Utilization, Payment Behavior summary and Credit Exposure in dual box scenario (i.e. SAP R/3 is in

one box and SAP FSCM is in another box).

Landscape

Pre-Requisites

1. On the ECC systems, you should have the checked all the necessary FSCM related settings done properly.

2. On XI system, The Integration server and System landscape directory should be configured properly.

3. Check all the three systems are connected properly through the RFC connections.

Steps to be performed

Setting up SPRO settings for Financial Supply Chain Management.

Setting up R/3 related Proxy settings to connect SAP XI.

Setting up XI related proxy settings to connect SAP FSCM.

Interface Design, Development and Configuration in XI.

1.) Setting up SPRO settings for Financial Supply Chain Management.

The settings should be carried out by our Functional team (FI).

2.) Setting up Proxy related settings in R/3 systems.

Go through this blog for activating the ABAP Client proxies.

How do you activate ABAP Proxies?

Apart from this we have to maintain and activate the following http services related to XI in R/3.

Copyrights © 2012 SAP AG Germany

For activating the services go to the T-Code SICF

3.) Setting up XI related proxy settings

3.1) Maintain the RFC connections to R/3 systems using T-Code SM59 in XI system.

Once the connection is maintained, test the connection..

3.2) Maintain the integration engine configuration using the T-Code SXMB_ADM

Configure the role of business system as INTEGRATION SERVER

Copyrights © 2012 SAP AG Germany

3.3) Maintain the following parameters for the Integration engine configuration.

Once the configuration is done check the Integration engine configuration…

3.4) Run the T-Code SLDCHECK

System Landscape Directory setup is correctly configured then the SLDCHECK should be successful.

3.5) Maintain and activate the HTTP services related in XI system using T-Code SICF.

Copyrights © 2012 SAP AG Germany

3.6) Create and maintain the technical & business system for R/3 systems in XI.

4) Interface Design, Development and Configuration in XI

4.1) Integration Repository

Need to import and maintain the following software components in the Integration Repository.

FINBASIS

SAP ABA

SAP BASIS

we can download the content from https://websmp206.sap-ag.de/support & goto entry by application group ->SAP

Content -> ESR Content(XI Content).

Once the XI contents are downloaded, ask your BASIS team to move the files into following

path/sapmnt/XID/global/xi/repository_server/import

4.2) Integration Directory

Copyrights © 2012 SAP AG Germany

Need to assign the BUSINESS SYSTEM for R/3 system which is already maintained in the SYSTEM

LANDSCAPE DIRECTORY.

Create and maintain the receiver communication channel.

Create and maintain the collaboration profiles and collaboration agreements for corresponding interface objects.

Now we can start configuring the Credit Management Interfaces as per the requirement.

Dispute Management

Dispute Management is a sub module of FSCM.

Dispute Management uses the case management process in SAP.

A Dispute Case is created and then can be work-flowed through a business for resolution.

Links can be made to 3rd party information, business rules can be applied so certain dispute types are automatically

credit'ed, or moved to certain users for resolution.

The core reporting occurs in BI, however it integrates very well with Collections Management and Biller Direct.

The aim of the module is to record the dispute in a single system to allow all business users to have access to the

same information and work together to resolve the dispute as quickly as possible to improve cash flow, and reduce the

DSO.

Please review the following wiki for information regarding the ES view for Dispute Management available in

Enhancement Package 4

Copyrights © 2012 SAP AG Germany

Dispute Management

The Dispute Management ES bundle service-enables the dispute management capabilities of SAP ERP.

Simply stated, the Dispute Management ES bundle provides Enterprise

Services designed to help SAP clients better manage invoice-related

disputes with customers when one or more processes must be invoked in

order to address the underlying claim. It accomplishes this by service

enabling Dispute Case functionality - the primary business object covered

by this bundle - held within SAP Dispute Management.

The Dispute Management ES bundle enables searching for, displaying,

creating, and changing of dispute cases. Dispute cases are created when

a customer pays less than the original invoice amount for a variety of

reasons, including dissatisfaction with a job. A Dispute Case is a record

that contains all the information relevant to a disputed invoice and is the

central business object tying together all the information and activities

necessary to process and resolve disputes.

Basically, a dispute case is a virtual file that can provide every employee

involved with resolving the dispute direct access to all of the necessary

information without having to search through numerous systems or files

manually. Employees can enter information and comments as electronic

notes, creating an accurate record of how a particular dispute was handled

and resolved.

Dispute Management(click to enlarge)

Importantly, this ES bundle also facilitates real-time (synchronous) and asynchronous integration of SAP Dispute

Management with other SAP and non-SAP applications, though, as with all enterprise service implementations, some

work is involved to write code that invokes the services (the composite application or other type of service consumer).

This bundle also facilitates integration with customer interaction centers (areas that provide enhanced customer service

by offering multiple contact options and efficient methods to respond to customer queries), customer fact sheet

applications, and customer-facing portals, where a customer can create a dispute case themselves. The net result is an

integrated, 360-degree view of all customer disputes and related claims and tickets across the enterprise.

In all, the Dispute Management ES bundle leverages enterprise SOA by providing communication with SAP ERP, SAP

CRM, SAP Quality Management, as well as non-SAP applications through the use of enterprise services.

Copyrights © 2012 SAP AG Germany

Audience

Industries

The Dispute Management ES bundle is targeted at all industries with FI-AR backend systems,

especially those where CRM-like applications are used. This bundle is also targeted at SAP

customers who are already using SAP Dispute Management and want to integrate it with

other SAP and non-SAP applications.

Roles

Managers and clerks.

For details on Service Operations, Business Objects and Process

Components, please check the ES Workplace.

How to Use This ES Bundle

Prior to the creation of this ES bundle, there was no automated and integrated way to allow

users from various departments, such as call centers and quality management, to create

dispute cases to document information about invoice disputes.

Table of Contents

Audience

For details on Service

Operations, Business

Objects and Process

Components, please

check the ES

Workplace.

How to Use This ES

Bundle

Use Cases

o Use Case 1: Dispute

Management

Integration with CRM -

Creating a Dispute

Case

o Use Case 2: Dispute

Management

Integration with CRM -

Changing a Dispute

Case

o Use Case 3:

Interaction Center

Trouble Tickets

o Use Case 4: Including

Disputes on a

Customer Fact Sheet

o Use Case 5: Allowing

Quality Managers to

Create Dispute Cases

o Use Case 6: Enabling

Call Center Agents to

Create Dispute Cases

Informed by Quality

Issue Notifications

o Use Case 7: Handling

Dispute Cases

through a Customer-

Facing Portal

System Requirements

Related ES Bundles

Links

o SDN and SAP Links

The Dispute Management ES bundle provides an automated method for companies to better manage disputes and to

integrate handling of disputes with a number of other systems. As a result, employees who create dispute cases have

direct access to all of the necessary information without having to manually search through a number of records and

files. It is all contained in an easily accessible format within the dispute case.

Further, each dispute case includes a reason code, which delineates the nature of the complaint and specifies the

various business processes involved. A processing status notice can also be logged, which with the reason codes will

activate follow-up actions such as notifying relevant employees and/or internal processes, triggering sending an email to

the customer, as well as triggering actions in SAP ERP financials or logistics applications, for example.

The result is more efficient and cost-effective handling of disputes, with the following benefits:

Copyrights © 2012 SAP AG Germany

Cost Savings

Reduced manual work, lowered integration costs with SAP and non-SAP systems, and reduced number of open or

disputed invoices (because of increased speed in handling dispute cases)

Improved Efficiency

Higher degree of automation and optimized cross departmental communications speed dispute clarification and

resolution, more effective communications between applications such as CRM and quality management.

Integrating with CRM

Armed with composite applications designed to call the services in this bundle, call center agents can quickly and easily

create dispute cases and forward them to SAP ERP for further processing. Call center agents are also able to quickly

and easily find dispute cases related to specific customers and get all the information they need about the status and

findings of a dispute case.

Integrating with Quality Management

Quality managers are able to take Quality Issue Notifications, created in SAP Quality Management, and, when

necessary, quickly and easily create dispute cases. As with the CRM integration, these dispute cases are then

forwarded to ERP for further handling. The reverse can also be true in that a dispute case created by a customer

service representative with a relationship to a quality issue can be made visible to a quality manager. In this way,

duplicate dispute cases are prevented while necessary information reaches all affected units of the company.

Furthermore, by connecting disputes with quality issues, the financial impact of quality issues can be assessed.

Customer Facing Portal

The Dispute Management ES bundle enables integration with web applications so that a customer can check the status

of a dispute or file a new dispute online.

Use Cases

The following sections explore seven use cases for the Dispute Management ES bundle. Each is intended to provide a

concrete example of the types of functions the bundle supports and shows how different outcomes can be achieved by

using the enterprise services in different combinations.

While these use cases demonstrate a few of the ways the ES bundle can be used, they are designed to highlight the

flexibility and reusability of the business objects and enterprise service operations so as to provide a clearer

understanding of how you can deploy them in your own environment.

This wiki is also the space for readers to share knowledge and collaborate with others who are implementing the

Dispute Management ES bundle.

Use Case 1: Dispute Management Integration with CRM - Creating a Dispute Case

Note: This use case presumes that the CRM system has been modified to provide options that invoke enterprise

services in this bundle.

In this scenario, a call center agent for a construction company receives a call from a customer asserting that the

company's contractor only performed 80 percent of the service, so the customer will only pay 80 percent of the invoice.

The call center agent understands that this represents an invoice-related dispute and selects an option in a CRM

system to open a dispute case.

After all of the necessary information is entered, the agent saves it, and the CRM system invokes the Check Trade

Receivables Payables Dispute Case Creation enterprise service. This service operation verifies that all the required

information to create a dispute case has been entered. If there are any errors or omissions, the application displays an

error message.

Upon correcting the errors, the agent saves the information, which invokes the Check Trade Receivables Payables

Dispute Creation enterprise service again.

Since the information is complete and correct, the CRM system then invokes the Create Trade Receivables Payables

Dispute Case enterprise service. This asynchronous service creates a dispute case in SAP ERP.

Once a dispute case is created in SAP Dispute Management, notices are automatically sent to relevant individuals and

organizational units.

Copyrights © 2012 SAP AG Germany

Once a resolution is reached, the dispute case is automatically updated to reflect these changes. If a payment is

required from the customer, once it is received and posted the system, it can be mapped to the correct dispute case,

which can be automatically updated.

The following table summarizes these steps and associated enterprise services:

Step Enterprise Service Invoked

Step 1: The call center agent displays the customer information in CRM (no enterprise service operation is invoked

during this step)

Step 2: The agent determines that the complaint constitutes an invoice-related

dispute and opens a dispute case in CRM.

(no enterprise service operation is invoked

during this step)

Step 3: The agent enters the necessary information to create a dispute case and

saves.

(no enterprise service operation is invoked

during this step)

Step 4: The application checks for errors and displays an error message if any are

found.

Check Trade Receivables Payables Dispute

Case Creation

Step 5: The agent corrects any errors and saves the information in the dispute case

again.

Check Trade Receivables Payables Dispute

Case Creation

Step 6: The application creates the dispute case and sends it to SAP ERP Create Trade Receivables Payables Dispute

Case

Step 7: The dispute case is forwarded to the necessary individuals and offices (no enterprise service operation is invoked

during this step)

Use Case 2: Dispute Management Integration with CRM - Changing a Dispute Case

The customer from use case 1 calls back to add to the complaint, asserting that the work the contractor did was of low

quality and portions of which have been done incorrectly. The building inspector has asked for modifications, causing

the customer to reduce his payment to the company to $7,000.

The call center agent looks up the customer in the CRM system, which searches for any relevant dispute cases for this

customer (by invoking Find Trade Receivables Payables Dispute Case by Elements). The call center agent clicks on

the dispute case number, which invokes Read Trade Receivables Payables Dispute Case. The agent can then enter

whatever changes need to be made along with the reasons for the dispute given by the customer and any other relevant

information.

When the agent finishes entering the changes and saves the dispute case, the application invokes Check Trade

Receivables Payables Dispute Case Update followed by Change Trade Receivables Payables Dispute Case to

send the changes to SAP ERP.

Copyrights © 2012 SAP AG Germany

The following table summarizes these steps and the associated enterprise services:

Step Enterprise Service Invoked

Step 1: The call center agent receives a call and displays customer information in the

CRM system.

(no enterprise service operation is

invoked during this step)

Step 2: CRM searches for relevant dispute cases and displays a list Find Trade Receivables Payables Dispute

Case by Elements

Step 3: The call center agent sees the dispute case the customer called about and

clicks on it.

Read Trade Receivables Payables Dispute

Case

Step 4: The agent makes changes and provides updated information for the dispute

case and tries to save the new information.

(no enterprise service operation is

invoked during this step)

Step 5: The application validates the data in the dispute case. Check Trade Receivables Payables

Dispute Case Update

Step 6: The changes are saved to SAP ERP. Change Trade Receivables Payables

Dispute Case

Use Case 3: Interaction Center Trouble Tickets

A customer of HDTV Inc. has just purchased a new widescreen television and had the company install it on a wall in her

home. However, the television appears to have some electronic problems that have cause the advertised features to not

work at all or improperly. The customer contacts the call center for HDTV Inc. and explains her problem to the call

center agent. In response, the agent creates and assigns a trouble ticket to the customer complaint. The customer and

trouble ticket are then passed on to a technical support representative who then helps the customer troubleshoot the

problem.

Often, these kinds of problems can be resolved during the initial customer call, but unfortunately in this case the issue

cannot be resolved because the television lacks the functionality to compress the audio range - a feature that helps

bring the volume between the loudest sounds and whispered dialogue into a closer range.

To compensate for this lack of functionality, the customer is offered and accepts a credit memo. The technical support

person changes the status of the ticket. The composite application has been programmed to recognize that trouble

tickets with this status should generate a dispute case. The composite application transfers all the information from the

trouble ticket to the dispute case and invokes Check Trade Receivables Payables Dispute Case Creation, which

validates that the necessary information has been entered. The composite then invokes the Create Trade Receivables

Payables Dispute Case enterprise service to create the dispute case and send it to SAP ERP for further processing.

Should the customer contact the call center a couple of weeks later to check on the status of the credit memo, the call

center agent can look up the dispute case by invoking the Find Trade Receivables Payables Dispute Case Basic

Data by Elements enterprise service. The agent selects the relevant dispute case from the search results, which

invokes the Read Trade Receivables Payables Dispute Case enterprise service.

Copyrights © 2012 SAP AG Germany

The agent is then able to provide the customer with the status of the credit memo and any other relevant information.

The following table summarizes these steps and the associated enterprise services:

Step Enterprise Service Invoked

Step 1: The call center agent receives the complaint and creates a ticket. (no enterprise service operation is invoked during

this step)

Step 2: The ticket and call are forwarded to a technical support

representative to troubleshoot the problem.

(no enterprise service operation is invoked during

this step

Step 3: To resolve the issue, the representative requests a credit memo. (no enterprise service operation is invoked during

this step)

Step 4: The trouble ticket information is used to create a dispute case. (no enterprise service operation is invoked during

this step)

Step 5: The composite application verifies the information used to create the

dispute case

Check Trade Receivables Payables Dispute Case

Creation

Step 6: The composite application then creates the dispute case and

forwards it to SAP ERP.

Create Trade Receivables payables Dispute Case

Step 7: At a later time, the customer calls to check the status of the credit

memo.

(no enterprise service operation is invoked during

this step)

Step 8: The agent searches for the dispute case. Find Trade Receivables Payables Dispute Case

Basic Data by Elements

Step 9: The agent selects the correct dispute case from the search results. Read Trade Receivables Payables Dispute Case

Step 10: The agent provides the customer with the requested information. (no enterprise service operation is invoked during

this step)

Use Case 4: Including Disputes on a Customer Fact Sheet

In order to be effective, customer fact sheets should provide a 360-degree view of a customer by including the status of

the customer, open orders, and any types of complaints or disputes associated with the customer.

To include customer disputes and related dispute cases in a customer fact sheet, the composite application creating the

customer fact sheet calls the Find Trade Receivables Payables Dispute Case Basic Data by Elements enterprise

service. This service searches for all dispute cases related to given customer (and perhaps which fall within a given

timeframe).

The composite application then invokes the Read Trade Receivables Payables Dispute Case enterprise service to

read the details of a dispute case and display them on the customer fact sheet.

Further, the services in this ES bundle could be integrated with services from the Customer Fact Sheet ES bundle or

could support a customer fact sheet within another environment such as Microsoft Outlook.

The following table summarizes these steps and associated enterprise services:

Copyrights © 2012 SAP AG Germany

Step Enterprise Service Invoked

Step 1: The composite application creating the customer fact sheet searches for

relevant dispute cases for a certain customer.

Find Trade Receivables Payables Dispute Case

Basic Data by Elements

Step 2: The composite application displays the dispute cases and related details

on the customer fact sheet.

Read Trade Receivables Payables Dispute Case

Use Case 5: Allowing Quality Managers to Create Dispute Cases

If a customer complains about the quality of a product - whether it is a single television as described in use case 3 or a

retailer complaining about an entire shipment of televisions - it is important to track this information in the company's

quality management system. This is important for a number of reasons, but primarily to help make corrections to the

underlying quality issues. It is also important to track this information in Dispute Management in case the customer

disputes the invoice for goods that fail to meet quality standards.

The goal of this use case is to provide visibility between SAP Quality Management and SAP Dispute Management. In

other words, a quality manager should be able to see if a customer has opened a dispute case. A Quality Issue

Notification, a business object in the Integration of Quality Management Systems ES bundle, contains information

related to the quality of a product.

Quality Issue Notifications of certain types could be set up to create dispute cases automatically on behalf of the

customer. In essence, for defective goods, the company says to its customers, we know this is defective; we won't

charge you for it.

If the Quality Issue Notification creation process has been set up in this way, behind the scenes, creating a Quality

Issue Notification would trigger a string of service operations. First, the application would invoke Find Quality Issue

Notification Product by Elements enterprise service operation. After finding the product details, the composite then

looks for affected sales orders by invokingFind Sales Order Basic Data by Elements. The composite then

invokes Read Sales Order Basic Data to obtain information relevant to creating the dispute case. It then creates a

dispute case with a predefined description that indicates why it was created and which Quality Issue Notification

triggered its creation.

The following table summarizes these steps and the associated enterprise services:

Step Enterprise Service Invoked

Step 1: A quality related complaint is received and a Quality Issue

Notification is created in SAP Quality Management.

(no enterprise service operation is invoked during this step)

Step 2: The type of the Quality Issue Notification in question

triggers creation of dispute cases for all involved customers.

(no enterprise service operation is invoked during this step)

Step 3: The composite application searches for affected products. Find Quality Issue Notification Product by Elements

Step 4: The composite app searches for sales orders containing

these products.

Find Sales Order Basic Data by Elements

Step 5: The composite app derives information from the sales

orders to create the dispute cases.

Read Sales Order_V3

Copyrights © 2012 SAP AG Germany

Step 6: The composite app creates a dispute case. Check Trade Receivables Payables Dispute Case

Creation; Create Trade Receivables Payables Dispute Case

Use Case 6: Enabling Call Center Agents to Create Dispute Cases Informed by Quality Issue

Notifications

Call center agents need access to quality information in order to have a fuller picture regarding a dispute. Realizing that

the product the customer has called to complain about already has received a Quality Issue Notification may help the

agent to ameliorate the customer's concerns.

A composite aimed at call center agents could combine information from SAP Dispute Management with information

from SAP Quality Management. It could further draw information from SAP CRM andSAP ERP.

The agent searches for a customer, which invokes Find Customer Address Basic Data by Name and Address. The

rep then selects the customer from the list of results, which invokes Read Customer. Using the customer ID, the

composite searches for order history by invoking Find Sales Order Basic Data by Elements and then searches for

any relevant dispute cases by invokingFind Trade Receivables Payables Dispute Case Basic Data by Elements. To

provide further details, the composite then uses the Material IDs from recent sales orders to invoke Find Quality Issue

Notification by Elements, searching for quality issues related to products ordered in the last six months.

Before even beginning to speak with the customer, the call center agent has an accurate picture of any quality issues

related to the products the customer has ordered.

If required, the agent can then create a dispute case on the customer's behalf by entering necessary details, which

invokes Check Trade Receivables Payables Dispute Case Creation. If all the details were entered properly, the

composite invokes Create Trade Receivables Payables Dispute Case.

The following table summarizes these steps and the associated enterprise services:

Step Enterprise Service Invoked

Step 1: A call center agent receives a call from the customer and opens a composite

application.

(no enterprise service operation is invoked

during this step)

Step 2: The agent searches for the customer's information. Find Customer Address Basic Data by

Name and Address

Step 3: The agent selects the customer from the search results. Read Customer

Step 4: The composite application uses the customer ID number to search for sales

orders

Find Sales Order Basic Data by Elements

Step 5: The composite application searches for any dispute cases related to this

customer.

Find Trade Receivables Payables Dispute

Case Basic Data by Elements

Step 6: The composite application searches for quality issue notifications related to

products this customer has purchased.

Find Quality Issue Notification by

Elements

Step 7: The composite application displays all the information found, giving the

agent a more complete picture of this customer before proceeding.

(no enterprise service operation is invoked

during this step)

Step 8: If needed, the call center agent enters data needed to create a dispute case. Check Trade Receivables Payables Dispute

Copyrights © 2012 SAP AG Germany

Case Creation

Step 9: If correct, the composite application creates a dispute case and sends it to

SAP ERP.

Create Trade Receivables Payables

Dispute Case

Use Case 7: Handling Dispute Cases through a Customer-Facing Portal

Companies see the wisdom of allowing customers to submit more and more information online themselves rather than

having them telephone a call center agent. This approach can save time and money.

The company in this use case already has a customer-facing portal and decides to incorporate dispute case

functionality.

When a customer pays their bill on the site (which might use, for example, the services from the Electronic Bill

Presentment and Payment ES bundle), if they pay less than the invoice amount, they are presented with a pull-down

menu where they specify a reason for this low payment. If the reason relates to product quality, for example, they are

then given an option to create a dispute case.

The customer enters all details into the web form and selects an option to save it. This invokes the Check Trade

Receivables Dispute Case Creation enterprise service operation. If any details are missing, the customer fills them in.

If all details are provided, the web application invokes Create Trade Receivables Payables Dispute Case.

Creating this dispute case returns an identifier for the dispute case. The customer can then come back later to check on

the status of the dispute case, which invokes the Create Trade Receivables Payables Dispute Case enterprise

service operation.

The following table summarizes these steps and the associated enterprise services:

Step Enterprise Service Invoked

Step 1: A customer logs into the company's web portal and pays her bill. (no enterprise service operation from this ES

bundle is invoked during this step)

Step 2: The customer pays less than the invoice amount. (no enterprise service operation is invoked

during this step)

Step 3: The web application asks the customer to select a reason for the

underpayment.

(no enterprise service operation is invoked

during this step)

Step 4: If the customer enters a reason code that should trigger a dispute case, the

web application presents the customer with an appropriate option.

(no enterprise service operation is invoked

during this step)

Step 5: The customer selects the option to create a dispute case and then saves

the information.

Check Trade Receivables Payables Dispute

Case Creation

Step 6: If all details are correct, the dispute case is created. Create Trade Receivables Payables Dispute

Case

Step 7: The web application displays the identifier for this use case, as well as

other details.

Read Trade Receivables Payables Dispute

Case

Step 8: Later the customer comes back to review the status of the case. The (no enterprise service operation is invoked

Copyrights © 2012 SAP AG Germany

composite lists outstanding invoices as well as open dispute cases. during this step)

Step 9: The customer selects the dispute case to review. Read Trade Receivables Payables Dispute

Case

System Requirements

SAP ERP 6.0

SAP enhancement package 4 for SAP ERP 6.0

Related ES Bundles

Customer Fact Sheet

Integration of Quality Management Systems

Links

SDN and SAP Links

SOA Homepage on SDN

Dispute Management page on the ERP Financials Wiki

Dispute Management page on the Shared Services wiki (nice diagrams of how dispute management fits into the overall

receivables process both on that page and on its parent page, Monitoring & Collection of Receivables)

Source: http://wiki.sdn.sap.com/wiki/display/ESpackages/Dispute+Management

Workflow is a key part of controlling the dispute management process. Disputes will be created and then passed out to

different business users for approval or more information. The key to this process is ensuring that workflow is used at

the correct time in the process –

When to workflow with SAP FSCM Having worked on a few implementations of SAP FSCM Dispute Management it is clear that there is no simple

standard solution when deciding what decisions in the dispute cycle should use workflow. The benefits of

workflow are clear – "you are pro-active rather than re-active to a dispute”.

However as the saying goes “you can take a horse to water, but you can’t make it drink”; you can send e-mails to

processors or approvers but you cannot make them open the dispute and action it. Further to this, the reporting

within ECC is non existent, so if you want to report on disputes, you will need to activate some BI reports.

Workflow or BI reports?

Now BI reports can be sent to business users to notify them of disputes they need view and action, and in a way

this is doing the same type of job as the workflow – notifying the business user they need to action the dispute.

With a typical SAP FSCM implementation, the reporting requirements will come right at the end of the project,

they maybe defined in the scoping and Blueprint, but the true look at feel to them will only come late in

realisation. Where clients want formal control around their processes workflow is usually recommended as an

option, and with mature SAP ERP clients, they will have some experience of this is other business processes.

Within scoping and blueprinting, the formal dispute cycle is debated and agreed, and the process will normally

include workflow where formal controls are required within the process. Sometimes the business decisions that

are made early on within the implementation will be done without the knowledge of what could be achieved via BI

reporting and so workflows get designed and agreed to mitigate the risk of lack of control around the approval

and sign off processes of a dispute.

Dispute phases within the cycle

The dispute cycle, can be made very complicated, with many new system statuses added, new fields included to

record information that is deemed critical. However all dispute cycles can be broken down into a number of basic

phases.

1. Creation and logging

2. Approval or rejection of dispute

Copyrights © 2012 SAP AG Germany

3. Resolution of dispute - credit note creation

4. Closure of dispute

When should workflow be used?

Workflow is not normally used to create and log a dispute. There are a number of different ways to create

disputes within SAP FSCM, some are automated from receipt of payment, and others could be as a result of

customer contact made within SAP Collections Management. The key area for workflow is the approval phase. A

normal process would have a dispute being sent to an “approver”. This could be derived from the customer

number or the reason code or manually entered. The approvers “task” is to review the details in the dispute and

approve or reject. If they have sufficient authority the resolution phase could start, or if they don’t a new approver

maybe required to authorise a high value credit note. The resolution phase, is normally either raising a credit note

and attaching that to the dispute, or contacting the customer to inform them that the dispute has been resolved

and no credit is due, (this could be the case where a Purchase Order Number is missing on a customer invoice).

The business users required in the resolution phase will normally be frequent users such as credit collections

clerks. Finally the closure of the dispute, is normally an automated process when the dispute has a value of zero,

this normally occurs when a credit is raised and assigned to the dispute, or the customer pays in full the invoice

that was in dispute.

Summary

The key area to focus on utilising workflow is the approval phase of the dispute. By creating good reporting and

sensible dispute statuses the other phases should be achievable by either automated processes or frequent

business users reviewing reports to identify the disputes that need further processing. Further to this, some

clients like to provide the frequent dispute users a worklist similar to the Collections Worklist, to identify the

disputes that they need to process

In-House Cash - Splitting Functionality

Purpose

The purpose of this page is to clarify the use of the splitting functionality in the In-House Cash functionality.

Overview

The splitting functionality in the In-House Cash is to be used in case you’d wish to pay the invoices using the individual

payment functionality in F110 and would also like to continue with individual payment when creating the payment

requests, therefore creating one payment request per payment process.

Splitting

When you set this indicator, in the case of an external payment, a separate payment request is sent to the paying FI

system for each invoice. This means that you can forward invoice information, for example, invoice number and item

text, to the payee.

This setting should be used, for example, in case you'd wish to have one payment request per ICH payment created.

This would allow more information on the detail of each invoice.

With this functionality, you’d be able to populate PAYRQ-XBLNR (Reference Document Number field) without the use of

user-exit 002.

How to set the splitting functionality ON through SPRO:

Finance Supply Chain Management -> In-House Cash -> Account Management -> Payment Processes in In-House

Cash -> Outgoing Payment Orders -> Set Up Creation of Payment Requests for Inbound IDoc in FI

Copyrights © 2012 SAP AG Germany

When you access the setup, select the appropriate Clearing Partner and go to Processing Parameters.

Example of Use

Scenario:

1) Run F110;

2) Run IHC0 to post the IHC payment order and trigger creation of payment request;

3) View Payment request via F8BT;

4) View table PAYRQ - reference field (XBLNR);

5) Run F111 to create outbound IDOC to send to bank.

Expected result

In the scenario above, the reference field XBLNR will only come from the invoice paid in F110 if the splitting functionality

has been used. If it hasn't been used, you’ll not be able to view the reference document number in F8BT or in the

payment request table PAYRQ.

Settings for Amount Limit Check in IHC

Purpose

The purpose of this page is to explain the settings needed to activate the amount limit check in IHC.

Overview

This page will guide users on which settings should be made to activate the limit check for ICH payment orders.

Step 1: User Authorization

For IHC_ACTION, FORCE and SUPER activities should not be active. This is the authorization role for the user for

whom you have to perform the amount limit check.

Copyrights © 2012 SAP AG Germany

Step 2: Transaction Type

The transaction type for the creation of the payment items should have the 'limit check' flag active.

Copyrights © 2012 SAP AG Germany

Step 3: Amount-Dependent Authorizations

The Amount-Dependent Authorization for payment items and payment orders should be set, which is under IHC

customizing.

Step 4: BTE 10024

BTE 10024 should be activated.

Copyrights © 2012 SAP AG Germany

Related Notes

SAP Note 1493695 - Restrict the transaction amount beyond the allowed limit

SAP Note 1303418 - BTE 10024 does not work for direct debits

SAP Note 1163193 - List of all BADI/BTE/Exits used in IHC

SAP Note 843452 - RUERP2004: Workflow and limit-functionality

SAP Note 791282 - IHC: Workflow for IHC payment orders

Note: SAP Notes are available only at SAP Service Market which requires Official User ID.