Payment Engine from SAP 7.0
October 2014
EnglishEnglish
Payment Engine for Deposit Management
(L90)
SAP SE
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany / Building Block Configuration Guide

© SAP SE Page 2 of 4

SAP Best Practices Payment Engine for Deposit Management (L90): Configuration Guide

Copyright

© 2014 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://global.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.


Icons

Icon / Meaning
/ Caution
/ Example
/ Note
/ Recommendation
/ Syntax

Typographic Conventions

Type Style / Description
Example text / Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.
Cross-references to other documentation.
Example text / Emphasized words or phrases in body text, titles of graphics and tables.
EXAMPLE TEXT / Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.
Example text / Screen output. This includes file and directory names and their paths, messages, source code, names of variables and parameters as well as names of installation, upgrade and database tools.
EXAMPLE TEXT / Keys on the keyboard, for example, function keys (such as F2) or the ENTER key.
Example text / Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
<Example text> / Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.


Contents

1 Purpose 5

2 Preparation 5

2.1 Prerequisites 5

3 Configuration 5

3.1 Payment Order Settings 6

3.1.1 Defining Payment Order Types 6

3.1.2 Maintaining Enrichment & Validation Check Set Rules 7

3.2 AM Proxy 9

3.2.1 Maintaining Transfer of Posting Date 9

3.3 SWIFT Format Converter 10

3.3.1 Changing Hierarchy Derivation for SWIFT Transaction Types 10

3.4 SEPA Format Converter 12

3.4.1 Determining Payment Order Type 12

3.4.2 Determining PE Transaction Type (SEPA Format Converter) 14

3.4.3 Determining Payment Order Priority (SEPA Format Converter) 15

3.4.4 Determining the Authorization Flag for Payment Orders 16

3.5 File Handler 17

3.5.1 Maintaining Converter 17

3.5.2 Maintaining Default Values for Format Converters 18

3.5.3 Determining PE Transaction Type 18

3.6 XML Converter 20

3.6.1 Defining Converter Implementation for Format Converter 20

3.7 Functional Monitoring 20

3.7.1 Maintaining Functional Monitoring Statuses 20

3.8 Mater Data 22

3.8.1 Creating Current Account 22

3.8.2 Changing Clearing Agreement 23

© SAP SE Page 26 of 26

SAP Best Practices Payment Engine for Deposit Management (L90): Configuration Guide

Payment Engine for Deposit Management

1  Purpose

The purpose of this document is to describe the general configuration steps required to manually set up the configuration within the system landscape that has already been installed using the corresponding installation or configuration guides for installation.

If you do not want to configure manually and prefer automated installation using BC Sets and other tools, refer to the Quick Guide of your SAP rapid-deployment solution that is attached to the SAP Note.

This document supplements the existing Customizing documentation in the Implementation Guide (IMG) and provides additional information where required.

In general, to be able to start configuring the attributes related to the loan life cycles, some general settings for Banking Services must be made.

2  Preparation

This building block is built for Payment Engine from SAP 7.0

2.1  Prerequisites

Before starting the installation, complete the following activities:

·  Read the Quick Guide document delivered with the specific SAP RDS package.

·  Ensure that you meet the recommended prerequisites.

·  Install the prerequisite building blocks.

-  For more information, see the document Prerequisites_Matrix_<pc>_<pv>_EN_XX. xls.

The placeholder [pc] depends on the RDS Packages you use, for example RDS_FS_LOANS refers to the SAP Loans Management rapid-deployment solution, the placeholder [pv ] depends on the product version, for example BNK80 refers to Banking services from SAP 8.0, EN refers to the language like EN for English language and [xx] depends on the country version for example XX for Cross Country, in full for example Prerequisites_Matrix_RDS_FS_LOANS_BNK80_EN_XX.xls.

-  This document can be found in the Step-by-Step Guide on Deploy ® Implement Options ®Manual Activation ® Content Library ® Prerequisites Matrix.

3  Configuration

The following section describes the complete settings for this building block. These settings can be divided into three main groups:

1.  Prerequisite settings that have to be checked and which were delivered by SAP (as part of the standard delivery):

The term Check refers to these prerequisite settings.

Specify all prerequisites necessary for the configuration of this building block (even if this means describing a complete table). Prerequisite settings are those settings that direct or influence the business process. Do not describe settings that are for documentation purposes only and that do not influence the process, such as generic code lists for currencies or countries. These settings are not described as prerequisites.

2.  Settings defined by the customer (in the customer namespace and customer-specific):

The system uses automation to request individual customer settings during the personalization process. These settings can be made initially or can be reused from existing SAPERP layers and are indicated in the text by your value.

If you need to explain the customer value, choose one of the following options:

·  If you have a short explanation, enter it directly in the table.

·  If you need a longer explanation, add an asterisk * after the customer value (<your value>*) and explain the value in the Comment paragraph.

3.  Additional settings that need to be made, which are covered either by automation or by manual configuration (in the customer namespace):

The term Create refers to these additional settings in the text.

Personalization

In this configuration guide, some fields are marked with (*) – Personalized field.

If the solution is implemented manually using the delivered configuration guides, the fields marked for personalization have to be taken into consideration.

During the configuration, you have to adjust the values provided for these fields in line with the values relevant for your implementation (for example, the currency in the configuration guides is marked as personalized field. Always replace the specified currency (EUR) with the currency relevant for your RDS).

For more details on personalization, see sections 7.2.1 and 7.2.3.5.2 in the Quick Guide. The overview table in the Quick Guide lists all the fields/values that are personalized along with a brief explanation.

3.1  Payment Order Settings

3.1.1  Defining Payment Order Types

Use

A payment order type identifies the product of an incoming or outgoing transaction. It is used to control the detailed process of a payment order within Payment Engine.

Procedure

1.  Access the transaction using the following navigation path:

Transaction code / SPRO
IMG menu / Payment Engine ® Payment Order ® Define Payment Order Types

2.  Choose the New Entries pushbutton and create the following settings:

Field name / Entry Value /
Clearing Area / RDS000
Order Type / 100103
PO Type Desc. / SCT Inc. Order
Long Desc. / SEPA SCT Order (incoming)
PO Category / 1001
PO No. Range / 01
CLR No. Range / 01
ORP No. Range / 01
RCP No. Range / 01
TOV No. Range / 01
Auth. Timeout / 00:00:00
PI Emb. Timeout / 00:00:00
Enrich. & Valid. Grp / EV_STD
Func. Monitor. Grp / FM_STD

3.  Choose Save.

Steps for Creating Multiple Entities for Independent Testing

If several independent entities need to be configured, the configuration step described above must be performed x more times (up to 20) with the following settings:

Clearing Area / Clearing Area Name (*) /
RDS001 / Clearing Area RDS 001
RDS002 / Clearing Area RDS 002
RDS003 / Clearing Area RDS 003
RDS004 / Clearing Area RDS 004
RDS005 / Clearing Area RDS 005
RDS006 / Clearing Area RDS 006
RDS007 / Clearing Area RDS 007
RDS008 / Clearing Area RDS 008
RDS009 / Clearing Area RDS 009
RDS010 / Clearing Area RDS 010
RDS011 / Clearing Area RDS 011
RDS012 / Clearing Area RDS 012
RDS013 / Clearing Area RDS 013
RDS014 / Clearing Area RDS 014
RDS015 / Clearing Area RDS 015
RDS016 / Clearing Area RDS 016
RDS017 / Clearing Area RDS 017
RDS018 / Clearing Area RDS 018
RDS019 / Clearing Area RDS 019
RDS020 / Clearing Area RDS 020

(*) Personalized field

3.1.2  Maintaining Enrichment & Validation Check Set Rules

Use

Here the check setsare defined determining which different checks are applied to payment orders and payment items during processing in the Payment Engine.

Procedure

4.  Access the transaction using the following navigation path:

Transaction code / SPRO
IMG menu / Payment Engine ® Payment Order ® Payment Order Enrichment & Validation ® Maintain Enrichment & Validation Check Sets

5.  Choose Assign E&V Check Set for Payment Order under Dialog Structure.

6.  On the Change View “Assign E&V Check Set for Payment Order”: Overview screen, choose the New Entries pushbutton.

7.  On the New Entries: Overview of Added Entries screen, create the following settings:

User Action / Clearing Area (*) / E&V Group / E&V Set Type / Execution Time / Channel / Format / Check Set ID /
Create / RDS000 / EV_STD / 1
1
1
4
4
4 / E
S
X
E
S
X / /SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT / /1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101 / 21
21
21
4
4
4

8.  Choose Save to save your entries.

9.  Choose Assign E&V Check Set for Payment Item under Dialog Structure.

10.  On the Change View “Assign E&V Check Set for Payment Item”: Overview screen, choose the New Entries pushbutton.

11.  On the New Entries: Overview of Added Entries screen, create the following settings:

User Action / Clearing Area (*) / Transaction Type Group for E&V / E&V Set Type / Execu-tion Time / Int. Route / Cha-nnel / For-mat / Inter-nal / Check Set ID /
Create / RDS000 / EV_SEPA
EV_SEPA
EV_SEPA
EV_SEPA
EV_SEPA
EV_SEPA
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD
EV_STD / 2
2
2
2
2
2
1
1
1
2
2
2
2
2
2
2
2
2 / E
E
S
S
X
X
E
S
X
E
E
E
S
S
S
X
X
X / X
X
X
X
X
X
X
X
X / /SEPA
/SEPA
/SEPA
/SEPA
/SEPA
/SEPA
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT
/SWIFT / /XML
/XML
/XML
/XML
/XML
/XML
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101
/1SW101 / N
Y
N
Y
N
Y
Y
Y
Y
N
Y
Y
N
Y
Y
N
Y
Y / 23
23
23
23
23
23
02
02
02
03
03
03
03
03
03
03
03
03

(*) Personalized field

12.  Choose Save to save your entries.

Steps for Creating Multiple Entities for Independent Testing

If several independent entities need to be configured, the configuration step described above must be performed x more times (up to 20) with the following settings:

Clearing Area / Clearing Area Name (*) /
RDS001 / Clearing Area RDS 001
RDS002 / Clearing Area RDS 002
RDS003 / Clearing Area RDS 003
RDS004 / Clearing Area RDS 004
RDS005 / Clearing Area RDS 005
RDS006 / Clearing Area RDS 006
RDS007 / Clearing Area RDS 007
RDS008 / Clearing Area RDS 008
RDS009 / Clearing Area RDS 009
RDS010 / Clearing Area RDS 010
RDS011 / Clearing Area RDS 011
RDS012 / Clearing Area RDS 012
RDS013 / Clearing Area RDS 013
RDS014 / Clearing Area RDS 014
RDS015 / Clearing Area RDS 015
RDS016 / Clearing Area RDS 016
RDS017 / Clearing Area RDS 017
RDS018 / Clearing Area RDS 018
RDS019 / Clearing Area RDS 019
RDS020 / Clearing Area RDS 020

(*) Personalized field